Security & Vulnerability Disclosure Policy

ChefSphere welcomes reports of potential security vulnerabilities in our products from researchers, customers, and the general public. This Security & Vulnerability Disclosure Policy ("VDP") describes how to tell us, what we will do in return, and the protections we offer to researchers who act in good faith. It aligns with ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), with the Cyber Resilience Act (Regulation (EU) 2024/2847) handling expectations under Art. 13 and the reporting expectations of Art. 14 — which apply from 11 September 2026 (24-hour early-warning notification to ENISA and national CSIRTs of actively-exploited vulnerabilities; 72-hour incident notification) with full applicability on 11 December 2027 — with NIS2 (Directive (EU) 2022/2555), and with the expectations of Apple App Store Review Guideline 5.1.1(vi) and the Google Play Developer Program Policies for apps handling user data.

1. Scope

1.1 In-scope

• Production websites under chefsphere.app and its subdomains.
• Production mobile applications distributed on the Apple App Store and Google Play under the bundle identifier app.chefsphere.chefsphere.
• Production public APIs documented under /api/v1.
• Production infrastructure under our operational control where a vulnerability directly affects user data or platform integrity.
• Authentication, authorisation, session management, password reset, account recovery, payment flows (Stripe integrations on our side only — not Stripe itself), marketplace listings, AI Chef endpoints, live-streaming controls, notification gateways, account-deletion flows.

1.2 Out-of-scope

• Third-party services operated by our processors (Stripe, Shippo, Cloudflare, Apple App Store, Google Play, Agora, OpenAI, DeepSeek, AWS, Supabase, observability providers). Report those to the relevant vendor directly.
• Physical-security findings concerning our offices or our employees' personal devices.
• Social-engineering of ChefSphere staff.
• Findings that require physical access to an unlocked device.
• Known, accepted risks documented in our ISMS (for example the absence of DNSSEC on a domain where we have a documented rationale).
• Vulnerabilities in code repositories or tooling that are not exposed to production users.
• Denial-of-service attacks, volumetric stress tests, brute-force credential stuffing, or any test that affects real users.

1.3 Test accounts and staging

Please use test accounts you create yourself and do not interact with accounts you do not own. If your finding requires a specific environment, email us at [email protected] and we can provide access to a staging tenant.

2. How to report

Send your report to [email protected]. A PGP public key is available on request; we recommend encrypting reports that contain proof-of-concept exploits or personal data.

A useful report includes:

• A clear title and a short summary of the issue.
• The affected surface (URL, API path, mobile-app screen, package name).
• A step-by-step reproduction with minimal traffic.
• The observed impact and your suggested severity (we use the CVSS 3.1 scoring framework).
• Credentials or test accounts you created for the test.
• Timeline constraints you are working to (for example a planned public disclosure date).

Please do not file vulnerability reports through the public [email protected] inbox, GitHub issues, or social media — those channels lack the controls needed to keep the vulnerability confidential while we triage.

3. Safe-harbor commitment

If you report a vulnerability in good faith under this VDP, ChefSphere commits to the following safe-harbor protections:

• We will not pursue civil or criminal action against you for testing and reporting conducted in compliance with this VDP, under Estonian law, under the EU Cybersecurity Act, under the Computer Fraud and Abuse Act where it could apply to US-based researchers, or under comparable national rules.
• We will not file DMCA or anti-circumvention claims where your research necessarily required circumventing a technical measure of our Service, provided you made a genuine effort to minimise the circumvention and destroyed any copies taken for the research.
• We will not suspend or ban your ChefSphere account solely for the research activity, provided the research was within the limits of this VDP.
• If a third party threatens you with action because of a report submitted to us in good faith, we will make reasonable efforts to explain our VDP to that third party.

Safe harbor does not cover: research that accessed, altered, or deleted data that was not yours; research that degraded the Service for real users; research conducted on out-of-scope systems; research that knowingly violated other laws (for example a foreign country's computer-misuse statute); or research that was intended to extort us.

4. Response SLA

We track every report with a dedicated ticket in our internal ISMS.

Step	SLA (business days)
Acknowledge receipt	2
Initial triage and severity assessment	5
Remediation target — Critical (CVSS ≥ 9.0)	7 calendar days
Remediation target — High (CVSS 7.0–8.9)	30 calendar days
Remediation target — Medium (CVSS 4.0–6.9)	90 calendar days
Remediation target — Low (CVSS < 4.0)	180 calendar days
Closure notice to researcher	within 5 business days of fix

We will update you proactively if a deadline slips. If you have not heard from us within the acknowledge-receipt SLA above, please resend and copy [email protected].

5. Coordinated disclosure

We operate a coordinated-disclosure model. Our default disclosure window is 90 calendar days from first acknowledgement; we are open to a shorter window where the risk is acute or to an extension where remediation requires coordination with a third party. Any extension is documented in the ticket and shared with the reporter.

Where a vulnerability qualifies for a CVE and we are the CNA of record, we coordinate the CVE assignment. Otherwise we work with the researcher's chosen CNA or with the CVE Program.

We credit reporters in the release notes and in the optional public Hall of Thanks, unless the reporter prefers to remain anonymous. We ask reporters to wait until the fix has shipped and users have had a reasonable update window before publicly describing the finding.

6. Bounty

We do not currently operate a cash bounty programme. Qualifying reports receive public credit in the Hall of Thanks, ChefSphere-branded swag on request, and our genuine gratitude. If we launch a paid bounty in the future, it will be announced here with its own scope, scoring, and payout rules.

7. How we secure the Service

This VDP sits on top of the technical and organisational security measures described in the Privacy Policy §8. In summary:

• Transport security: TLS 1.3 preferred; TLS 1.2 minimum on all public endpoints. HSTS with includeSubDomains and preload on the web.
• Authentication: bcrypt for password hashes, rotating refresh tokens with Redis-backed blacklist, per-user mutex for concurrent refresh, optional time-based one-time-password 2FA.
• Authorisation: role-based access control, principle of least privilege on staff access, audit logging of every privileged action.
• Encryption at rest: sensitive columns (precise location, marketplace IBANs, verification references) are encrypted using envelope encryption.
• Database security: Postgres with SCRAM-SHA-256 authentication, TLS in-cluster, automated backups with point-in-time recovery, quarterly restore drills.
• Network: zero-trust between services, signed internal mTLS, Cloudflare WAF and rate limiting on every public edge, DDoS absorption capacity at the edge.
• Secrets management: no secret is stored in source control; secrets are issued by a dedicated secret manager with short-lived credentials.
• Supply chain: we track dependencies with a software bill of materials (SBOM), scan for known vulnerabilities on every build, and pin production images. ChefSphere will register as a CVE Numbering Authority (CNA) in advance of 11 December 2027 so that any vulnerability that must be disclosed under CRA Art. 14 can be assigned a CVE identifier by ChefSphere itself rather than depending on a third-party CNA.
• Monitoring: structured logs shipped to a SIEM, anomaly detection on login patterns, alerting on privileged-operation deltas, on-call rotation.
• Incident response: documented runbook aligned with Art. 33 GDPR (72-hour breach notification to the Estonian Data Protection Inspectorate where the breach is likely to result in a risk to data subjects), with internal severity-1 within 15 minutes of detection.
• Business continuity: cross-region replication for databases, tested disaster-recovery drills, recovery point objective ≤ 15 minutes for production databases.
• Audit posture: internal ISMS aligned with ISO/IEC 27001:2022, on track to external certification; quarterly internal reviews; annual third-party penetration test.

8. How we handle a confirmed vulnerability

1. Confirmation — we reproduce the issue and assign a severity.
2. Containment — where a fix requires time, we add compensating controls (WAF rule, feature flag, rate cap, partial disable) to limit exploitation during remediation.
3. Root-cause fix — we fix the vulnerability in the code path, not by patching symptoms. If a class of issue is found (for example an unsafe helper), we remediate the whole class.
4. Regression test — every fix is accompanied by a test that pins the failing behaviour.
5. Customer notice — if the issue affected user data, we notify the affected users and the Estonian Data Protection Inspectorate within the Art. 33 GDPR window.
6. Post-mortem — every Critical and High issue is reviewed in a written post-mortem that identifies systemic improvements.

9. .well-known/security.txt

We publish a machine-readable contact file at https://chefsphere.app/.well-known/security.txt containing the primary contact, this policy's URL, our preferred language, the expiry date, and a PGP fingerprint.

10. Scope of this policy vs. paid research contracts

This VDP governs unsolicited research. If you have a signed agreement with ChefSphere that covers security research (for example a third-party audit engagement), that agreement prevails over this VDP for the engagement it covers.

11. Changes

We update this VDP when our scope, our response SLA, or applicable law changes materially. The effective date and version at the top of this page control.

12. Contact summary

• Security reports: [email protected]
• Legal escalations: [email protected]
• DPO (for privacy-sensitive findings): [email protected]
• Postal address: ChefSphere OÜ, c/o E-Residency Hub OÜ, Ahtri tn 12, 10151 Tallinn, Harju maakond, Estonia, Attn: Security.