CISA Secure by Design Pledge: Bidda Public Attestation ====================================================== JS-free text mirror for AI crawlers. Canonical page: https://bidda.com/cisa/secure-by-design Last updated: 2026-08-04 ← BIDDA × CISA PROGRAM 2 OF 3 · DRAFT Secure by Design Pledge Bidda has signed the CISA Secure by Design Pledge. Its attestation meets 6 of the 7 goals today, with the remaining 1 goal (issuing CVEs) committed as a planned next step. CISA's Secure by Design Pledge is a voluntary public commitment by software manufacturers to seven security-first goals. Bidda's attestation below maps each goal to the controls and evidence already in production today. Signing is a commitment to work toward the goals rather than a CISA certification, so this page is the published evidence behind that commitment. 6/7 GOALS MEETING BAR 1/7 PLANNED COMMITMENT STATUS DISCLOSURE Bidda has signed the pledge via CISA's intake form on cisa.gov/securebydesign/pledge, and CISA has acknowledged the submission. Signing is a voluntary commitment to work toward the seven goals; it is not a CISA certification, audit or endorsement of Bidda. This page is the public evidence behind that commitment and is refreshed as progress is made against each goal. The seven goals 01 Multi-factor authentication CISA's ask: Measurable increase in MFA usage across the product, with MFA on by default for new deployments where feasible. MEETS BIDDA POSTURE Bidda issues no passwords. Account access is passwordless via magic link (single-use, time-limited token sent to the registered email address). Vault unlocks use bearer credentials (Skyfire JWT or USDC L402 macaroon) which are themselves cryptographic. EVIDENCE ▸ /account uses email magic-link only, with no password storage anywhere in the system. ▸ Vault payments use L402 (Lightning/HTTP 402) with USDC macaroons or Skyfire bearer tokens. No long-lived shared secrets. ▸ The edge gateway code contains no password validation logic, because there are no passwords in the system to validate. 02 Default passwords CISA's ask: Reduce the prevalence of default passwords shipped with the product. MEETS BIDDA POSTURE Not applicable in the conventional sense. Bidda ships no shipped artefacts with default credentials. The SDK (bidda-shield), MCP server, and discovery APIs use either no credentials at all (free tier) or a user-provisioned key (vault tier). No defaults exist to phase out. EVIDENCE ▸ Discovery API: no auth. ▸ Vault tier: customer-provisioned Skyfire token or USDC payment. No default key ever issued. ▸ bidda-shield 0.3.0 (PyPI): no embedded credentials in the package. 03 Reducing entire classes of vulnerability CISA's ask: Demonstrable progress in eliminating a class of vulnerability (e.g. SQL injection, memory-safety bugs). MEETS BIDDA POSTURE The payment gateway and API surface run on a managed serverless edge platform that uses isolated runtimes. The runtime model eliminates entire classes of memory-safety bugs that affect native-code services. Database access throughout the platform code uses parameterised statements only, and the request path is dominated by static content rather than user-driven query construction. EVIDENCE ▸ The managed isolate-based runtime makes buffer-overflow and use-after-free vulnerability classes structurally unreachable. ▸ Production reads are dominated by a static, version-controlled content tree and an edge key-value store. ▸ The audit database uses parameterised statements throughout, with schema files held in source control alongside the platform code. 04 Security patches CISA's ask: A demonstrable patch cadence with measurable time-to-patch. MEETS BIDDA POSTURE Bidda operates its own independent source-control and continuous-integration platform on independent hardware that the team controls directly. This independence means a patch can move from triage to production without waiting on any third-party scheduling, queue or quota. Security-class patches are prioritised and ship promptly after disclosure, and high-impact issues take priority over feature work. EVIDENCE ▸ Workflow definitions live in source control alongside the platform code and are executed by Bidda-controlled runners. ▸ Changelog at /changelog publishes all material releases, including security-relevant fixes. ▸ A weekly integrity watcher rebuilds the audit manifest that anchors the public health endpoint. ▸ Acknowledgement service level published for incoming vulnerability reports (see /security). 05 Vulnerability disclosure policy CISA's ask: A published VDP with safe-harbour terms for good-faith researchers. MEETS BIDDA POSTURE Bidda publishes a full coordinated vulnerability disclosure policy at /security, with an RFC 9116 contact at /.well-known/security.txt, explicit scope, explicit safe harbour for researchers acting in good faith, and a public "Friends of Bidda" recognition hall in lieu of a paid bounty programme (which is on the roadmap). EVIDENCE ▸ /security, where the full policy with reporting steps, scope, safe harbour and an acknowledgement service level is published. ▸ /.well-known/security.txt, which carries the RFC 9116 security contact and is refreshed on the schedule required by the standard. ▸ Researcher recognition: Friends of Bidda hall on /security. 06 CVEs CISA's ask: Commitment to issue CVEs for security-impacting vulnerabilities in your own products. PLANNED BIDDA POSTURE Bidda commits to filing a CVE for any in-product vulnerability that affects integrity, confidentiality, or availability of the platform. The first CVE will be the public attestation of that commitment. EVIDENCE ▸ Public commitment: CVEs filed via MITRE CNA process for any qualifying issue. ▸ Scope: bidda.com, bidda-shield (PyPI), bidda MCP server. 07 Evidence of intrusions CISA's ask: Customers can detect intrusion attempts against their use of your product. MEETS BIDDA POSTURE Bidda runs a per-call audit log in an edge-native relational store, scoped per customer key and surfaced on /account. Vault unlocks, subscription events and account-recovery actions are logged with timestamp, IP family and user-agent. A weekly source-integrity watcher publishes a tamper-evident health summary at /api/v1/registry-health.json that any defender can verify independently of Bidda. EVIDENCE ▸ Per-call audit log, scoped per customer key and surfaced on /account. ▸ Weekly source-integrity watcher whose results are published at /api/v1/registry-health.json. ▸ Git Merkle audit chain: every node commit is signed into an immutable version-control history, and /verify exposes the lookup. ▸ TLS 1.3 is enforced at the edge, with connection metadata captured in the edge platform access logs. HOW THIS PAGE IS MAINTAINED A living attestation, not a one-time signature Each goal on this page is reviewed and either: ▸ MEETS reaffirmed with the same or improved evidence; ▸ PARTIAL rebaselined with progress notes (what improved, what is still outstanding); ▸ PLANNED resolved into MEETS once the corresponding capability ships, or honestly downgraded if it becomes blocked. The /changelog page is the audit trail. Every release that touches a goal references the goal number in its changelog entry. ← BACK TO CISA HUB /SECURITY · VDP /CHANGELOG