Reviews and compliance
CapacityLens keeps a set of dated, evidence-based security documents alongside the code, instead of a one-off claim of "secure by design". They are written for security reviewers, auditors and technical evaluators, not for a first read of the product — start at the Security overview if that is what you need. Each artifact below is reproduced as-is on its own page; this page just explains what each one is and when to reach for it.
OWASP ASVS 5.0.0 ledger
Dated 2026-08-18 for alpha4. Every one of the 345 requirements in the OWASP Application Security Verification Standard 5.0.0 (covering Levels 1 to 3), assessed as Pass, Partial, Gap or Not Applicable, with the repository evidence behind each one. Read this when you need to check a specific control by ASVS requirement id, or want the complete picture rather than a summary.
OpenSSF Baseline self-assessment
Dated 2026-09-09. Answers every control in OpenSSF Baseline Levels 1–3 with repository evidence, including explicit unmet controls instead of treating configured tools as proof of enforcement. Read this when completing or checking the project's public OpenSSF badge entry.
Security review — 2026-08-18
The alpha4 reassessment covers the complete current source and the security-relevant delta since July. It records the fixed session-idle, strict-OIDC SSRF and provider-token findings, refreshes the threat model and inventories, and reconciles all 345 ASVS controls with current CI and ZAP evidence.
Security review — 2026-07-14
A point-in-time source-code review against the ASVS ledger above, plus the OWASP Top 10 and API Security Top 10. It explains the review's scope and method, lists findings and how they were treated, and states plainly what is a code guarantee, what is an inherited library guarantee, and what is left to the self-hosting operator. Read this for the narrative version of the ASVS ledger — what was found, fixed and accepted, and why.
Threat model
Dated 2026-08-18. States CapacityLens's security objectives in plain terms, lists the assets and trust boundaries being protected, names the realistic attackers (a malicious teammate, a credential-stuffing bot, a compromised identity provider, a careless operator, and more), and maps each abuse case to the controls and tests that address it. Ends with the risks that are consciously accepted rather than fixed. Read this to understand why a control exists, not just that it does.
Control inventories
Dated 2026-08-18. The reference tables behind the threat model and ASVS ledger: every entry point and untrusted input, every class of sensitive data and how long it is kept, the full cryptographic inventory (what algorithm protects what, and its key lifecycle), service and rate limits, and the audit/security event log. Read this when you need the specific technical detail — for example, exactly what algorithm hashes a password, or exactly how long a session token lives.
Mutation-test review — 2026-07-15
The first review of CapacityLens's mutation-testing results (a technique that deliberately introduces small bugs into the code to check whether the test suite catches them) read for security meaning rather than raw score. It found and fixed one real defence-in-depth defect in tenant-data validation, and records which parts of the codebase the mutation score does — and does not — cover.
Mutation-test review — 2026-07-18
A follow-up review after a test-scope correction (two React hooks had been wrongly included in the mutation run). Confirms the corrected 92.37% score, with tenant isolation, private-name handling and password-reset failure mapping all still at 100%. Read the two mutation reviews together for the current state of that evidence and what it does not claim to cover.
What's next
Report a vulnerability through the process in the security policy, or go back to the Security overview for the plain-language summary.