Bidda Security Policy and Vulnerability Disclosure ================================================== JS-free text mirror for AI crawlers. Canonical page: https://bidda.com/security Last updated: 2026-08-04 SECURITY & VULNERABILITY DISCLOSURE Security policy & vulnerability disclosure. Bidda operates a coordinated vulnerability disclosure program across a registry of 10,099 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 security@bidda.com. 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 security@bidda.com VULNERABILITY REPORTS info@bidda.com 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 security@bidda.com (preferred) or info@bidda.com. 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 info@bidda.com. 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 security@bidda.com 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