← BIDDA × CISA
PROGRAM 2 OF 3 · DRAFT
Secure by Design Pledge
Bidda's attestation meets 6 of the 7 CISA Secure by Design Pledge 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. This page is the public draft that will be referenced when the pledge is formally signed.
6/7
GOALS MEETING BAR
1/7
PLANNED COMMITMENT
STATUS DISCLOSURE
This is a draft attestation. The pledge itself is signed via CISA's intake form on cisa.gov/securebydesign/pledge. This page is the public evidence Bidda references when submitting, and it 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