Chapter 11: Vulnerability Disclosure & Security Updates

11.0 Summary

• MUST: Provide public vulnerability submission channels (e.g., security.txt & support email).
• SHOULD: Provide encrypted submission mechanisms (e.g., PGP key) for safe detail submission.
• SHOULD: Define clear response & remediation cadence (SLA/Target timelines) and communicate via Status Page when necessary.
• MUST: Treat vulnerabilities potentially affecting Zero-Knowledge commitments (XSS, supply chain injection, log fragment leakage) as highest priority.
• MUST: Implement versioned evolution (cryptoVersion) and define compatibility, migration & deprecation strategies.

11.1 Vulnerability Submission Channels & Contact

11.2 Response Timelines & Communication Principles

Timelines depend on team scale and complexity, but the project SHOULD provide predictable target cadence and communicate promptly if targets are missed. Recommended targets (adjustable based on reality and published in /security or security.txt):

• First Response: E.g., Acknowledge receipt and assign tracking ID within 48 hours.
• Initial Assessment: E.g., Complete severity grading and impact scope assessment within 7 days.
• Fix Release: Progress based on severity; P0/P1 prioritized for rapid fix and release.

SHOULD: Maintain necessary communication during processing (e.g., reproduced/not reproduced, need more info, estimated fix window) and avoid publicly disclosing exploitable details.

11.3 Disclosure Process

1. Receipt: Record report info, reproduction steps, impact, and researcher contact; assign owner and tracking.
2. Verification: Reproduce in isolated environment; assess impact scope, exploitability, and affected components (Frontend/Backend/Edge/Storage).
3. Remediation: Implement patch, add test/regression cases, add protection rules if necessary (WAF/Rate Limit/Policy Tightening).
4. Release: Canary release and monitor key metrics; full release after confirming no regression or new risks.
5. Announcement: Publicly explain impact, fix content, and required user actions (if any) without expanding attack surface.

For critical vulnerabilities or high user impact events, SHOULD publish event updates or post-mortems via /status aligned with Chapter 10 IR process.

11.4 Vulnerabilities Affecting Zero-Knowledge Boundaries

The core of Zero-Knowledge commitment is: Server cannot access CEK, download/decryption environment is isolated as much as possible without third-party scripts. Therefore, the following categories MUST be treated as highest priority:

• XSS / Injection: Ability to execute arbitrary scripts on download/decryption pages, reading fragments or memory key material.
• Supply Chain Injection: Dependency poisoning, build artifact replacement, CDN/Edge injection leading to script tampering.
• Log/Monitoring Leakage: URL fragment, CEK, token, or plaintext accidentally logged and accessible.
• Incorrect Resource Loading Policy: Download/decryption pages importing third-party scripts, CSP relaxation expanding execution surface.

Disposal should include: Immediate containment (offline risky code/tighten policy/ban vector), rapid fix release, retrospective impact analysis, and clear statement in announcement on "whether key material or plaintext was potentially exposed."

11.5 Security Updates & Regression Verification

• MUST: Establish regression cases for security-related changes (Auth, Access Control, CSP, Log Filtering, Encryption Flows).
• SHOULD: Perform automated checks on critical pages (Download/Decryption) to ensure no third-party scripts and header policies match expectations.
• SHOULD: Perform external verifiable item re-testing (e.g., TLS/Security Header scans) after fix release.
• SHOULD: Clearly document compatibility changes introduced by fixes (e.g., old links/old manifest) in documentation.

Consistent with Chapter 12: Third-party scans verify some Web baselines but cannot directly prove full Zero-Knowledge/E2EE implementation details; thus regression verification should cover both protocol implementation and visible baselines.

11.6 Protocol & Cryptography Versioning (cryptoVersion)

FileBolt's encryption and protocol implementation MUST support versioning to facilitate algorithm upgrades, fix implementation defects, and introduce stronger isolation. Recommended to use explicit fields (e.g., cryptoVersion) bound in manifest/metadata.

• Explicit Version: Every transfer/manifest MUST declare its cryptoVersion to determine algorithms, parameters, and encoding rules.
• No Implicit Inference: Client MUST decide parsing and decryption logic based on explicit manifest fields, not guessing or fallback heuristics.
• Fail Closed: MUST fail closed upon encountering unknown versions or inconsistent parameters, never downgrading to insecure modes.

11.7 Compatibility, Migration & Deprecation

11.8 Related Claim IDs (Reserved)

This chapter covers "Vulnerability Disclosure Channels, Workflows, Versioning & Deprecation." Corresponding Claim IDs will be added to the Appendix: Master List of Claim IDs as the sole authoritative source.