SECURITY & VULNERABILITY DISCLOSURE
Security policy & vulnerability disclosure.
Bidda operates a coordinated vulnerability disclosure program across a registry of 10,090 cryptographically-verified compliance nodes spanning 39 regulated sectors. If you have found a security issue, we want to hear from you and we will work with you to fix it.
To report a security vulnerability in Bidda, email [email protected]. We acknowledge reports within 2 business days and triage within 5.
Coordinated disclosure
RFC 9116 contact published
TLS 1.3
Enforced at the edge
Stateless by design
No PII stored, no model training on your data
Tamper-evident
Git Merkle audit chain over every node
2 business days
Acknowledgement target for reports
GDPR Art. 28
Advance notice of sub-processor changes
SECURITY CONTACTS
[email protected]
VULNERABILITY REPORTS
GENERAL & ESCALATION
RFC 9116: /.WELL-KNOWN/SECURITY.TXT
RESPONSE TARGETS
Acknowledge
within 2 business days
Triage
within 5 business days
Remediate
prioritised by severity
Disclosure
coordinated, 30-day minimum window
COORDINATED DISCLOSURE POLICY
Reporting a vulnerability
01
Email [email protected] (preferred) or [email protected]. Please include: a clear description of the issue, reproduction steps, the affected URL or endpoint, your assessment of impact, and any proof-of-concept that does not endanger user data. If you need to share sensitive details, say so in your first message and we will arrange a secure channel. We acknowledge reports within 2 business days and aim to triage within 5. If you do not get an acknowledgement, escalate to [email protected]. We also publish RFC 9116 contact info at /.well-known/security.txt.
Scope
02
In scope: the Bidda website (bidda.com), MCP server (bidda.com/mcp), /scan endpoint, /api/v1/* discovery and vault APIs, the Cloudflare Worker payment gateway, and any sub-domain we publish at *.bidda.com. Out of scope: third-party services we depend on (Cloudflare, Skyfire, Formspree, Paystack, self-hosted runners). For issues in those, please report directly to the relevant vendor. We are happy to forward valid reports to them.
Safe harbour for researchers
03
Please act in good faith. Avoid privacy violations (do not access or download more data than necessary to demonstrate the issue). Avoid service disruption (no denial-of-service testing without coordination). Do not exfiltrate other users' data. Give us a reasonable window (30 days minimum) to remediate before public disclosure. Stay within the in-scope assets listed above. We will not pursue legal action against researchers who follow these guidelines.
Recognition: Friends of Bidda
04
We do not currently run a paid bug bounty. We do publicly recognise researchers who report valid issues in good faith. With your permission, you will be listed in the "Friends of Bidda" section below, with your name (or handle), your organisation if any, and a link to a URL of your choice (personal site, employer, research lab, GitHub, social profile). The listing stays as long as Bidda exists. Recognition is at our discretion and proportional to the impact of the finding. A formal paid bounty programme is on the roadmap as we enter the enterprise tier.
PLATFORM SECURITY CONTROLS
Data privacy and AI commitment
05
We do not train any AI models on your queries or API payloads. The service is stateless: we do not store your query content, and we do not share it. Requests to the L402 API and MCP server remain private, which keeps the platform inside strict enterprise data boundaries.
Cryptographic audit trail
06
Every compliance node is cryptographically hashed and anchored in a tamper-evident Git Merkle chain, giving verifiable evidence of what a regulation said at a specific point in time and an independently verifiable, tamper-evident audit trail. TLS 1.3 is enforced at the edge. No customer payment card details touch Bidda infrastructure.
Data handling
07
Most traffic hits only the free discovery API and the rate-limited /scan endpoint. We store IP addresses for rate limiting (30 days, then purged) and transaction hashes for replay-attack prevention (permanent audit log, no PII). Contact form submissions are processed through Formspree as the form of record. See /privacy for the full data-handling statement.
Sub-processors
08
A current list of third-party sub-processors that may handle infrastructure or data is published in our Privacy Policy (section 08 at /privacy). We notify enterprise customers in advance of material sub-processor changes, as required by GDPR Article 28.
Independent verification and signing-key rotation
09
Bidda signed records use Ed25519 signatures that anyone can verify independently, offline, with no Bidda account. A browser verifier is published, the full method is published as an open specification, and command-line checkers for Node and Python are provided. We rotate the signing key periodically as good security practice. Every key we have ever used stays published, each identified by a key id, so a record signed by a rotated-out key remains verifiable for as long as the holder keeps it. Rotating the signing key changes only which key signs new records. It does not affect records already issued, and it is unrelated to customer API keys and subscriptions.
Cryptographic posture and post-quantum readiness
10
Our full cryptographic posture is published at /cryptographic-posture, with a plain-text mirror at /cryptographic-posture.txt and a Markdown copy at /.well-known/bidda-cryptographic-posture.md. It states which primitives we rely on at each layer, which of them a quantum computer affects, and what happens to already-issued records when they are replaced. Content integrity and the tamper-evident log are hash-based and are not broken by quantum computers. Record signatures are Ed25519 and are the layer on a stated migration path towards a hybrid signature. Transport uses hybrid post-quantum key agreement where the client offers it, and the posture page carries the command to verify that against our live endpoint. We do not describe Bidda as a quantum-safe platform.
FRIENDS OF BIDDA: HALL OF THANKS
Researchers who have reported valid issues in good faith are credited here, with a link to a URL of their choice. The list is empty for now, so be the first.
To be added: report a valid issue to [email protected] and tell us how you would like to be credited (display name, optional organisation, and a URL of your choice).
© 2026 BIDDA INTELLIGENCE (PTY) LTD · CIPC 2026/363776/07 · CAPE TOWN, SOUTH AFRICA
POLICY ID: BIDDA_SECURITY_2026_06_03_V1.2