The catalog

Every dimension the CAI measures.

The standard is composed of 124 dimensions across 10 lenses. Each is a definition — what it measures and how it's evaluated — pinned to a rubric version. This catalog is the standard's vocabulary; the spec documents how each folds into the score.

Showing only the Security lens. Show all 124 dimensions →

Security · 18 dimensions

ID	Dimension	What it measures	Why it matters	Evaluator
`D28`	Secrets (history)	Whether any secrets were ever committed — scanned across the full git history, not just now.	When this is weak, secrets were committed somewhere in the project's history, so even if removed today they remain readable to anyone who can clone the repository.	tool
`D29`	Static Analysis (SAST)	Real static-analysis (SAST) findings — likely security bugs in the code, any language.	When this is weak, automated static analysis finds likely security bugs in the code, meaning real, exploitable weaknesses are present in the delivery.	tool
`D30`	Dependency Vulnerabilities	Whether any dependencies have known published vulnerabilities (CVEs), direct or transitive.	When this is weak, dependencies carry known published vulnerabilities (CVEs), so the delivery ships with publicly documented weaknesses an attacker can look up and exploit.	tool
`D31`	IaC & Container Security	Whether Dockerfiles / Terraform / Kubernetes config follow security best practices.	When this is weak, the Docker, Terraform or Kubernetes configuration does not follow security best practices, so the infrastructure itself is misconfigured and exposed.	tool
`D32`	Data Compliance (PII/GDPR)	Likely personal-data (PII / GDPR) handling concerns — logging or storing data without safeguards.	When this is weak, the code likely handles personal data without proper safeguards — logging or storing it unprotected — exposing you to GDPR and privacy risk.	tool
`D33`	JS/npm Dependency Vulnerabilities	Whether JavaScript/npm dependencies have known published vulnerabilities (CVEs) — the npm ecosystem's biggest risk.	When this is weak, JavaScript/npm dependencies carry known published vulnerabilities (CVEs) — the npm ecosystem's biggest risk — so the frontend ships with documented, exploitable weaknesses.	tool
`D36`	Supply-chain Provenance & Signing	Whether the build pipeline provides supply-chain integrity — generated provenance/attestation, signed artifacts (cosign/sigstore), an SBOM, and pinned build actions. Presence of the configuration, not a runtime guarantee.	When this is weak, the build pipeline lacks supply-chain integrity — no provenance, signing or SBOM, or unpinned actions — so a consumer can't verify how the artifact was built or whether it was tampered with.	tool
`D37`	Vulnerability-disclosure Policy	Whether the repository publishes a coordinated-vulnerability-disclosure policy (SECURITY.md or security.txt) with a reporting contact, so finders know how to report a vulnerability. Presence of a policy file with a contact, not whether the policy is adequate or honoured.	When this is weak, there is no published vulnerability-disclosure policy (no SECURITY.md or security.txt with a reporting contact), so a researcher who finds a flaw has no documented way to report it to you.	tool
`D38`	OSV Dependency Vulnerabilities	Whether dependencies have known published vulnerabilities (CVEs) per the OSV database — npm and other lockfile ecosystems, parsed natively. Complements D33 (npm via trivy) and D30 (.NET via dotnet).		tool
`C1`	Data Protectionmeta	Whether sensitive data is encrypted at rest and in transit and keys are vaulted.	When this is weak, sensitive data is not consistently encrypted at rest and in transit with keys properly vaulted, so that data is more exposed if the system is breached.	tool
`C2`	Access Controlsmeta	Whether access is authorized by default — [Authorize]/policies or imperative guard methods (throw-on-violation) called from handlers.	When this is weak, access is not authorised by default — endpoints lack proper role and policy enforcement — so data or actions may be reachable by people who should not have them.	tool
`C3`	Audit Trailmeta	Whether changes to sensitive data are recorded (who, what, when) for compliance + incident response.	When this is weak, changes to sensitive data are not recorded, so you cannot tell who changed what and when — undermining compliance and incident response.	tool
`C4`	Data Retentionmeta	Whether data has a defined lifetime — retention periods, TTLs, cleanup jobs (storage limitation).	When this is weak, data has no defined lifetime — no retention periods or cleanup — so personal and other data accumulates indefinitely, contrary to storage-limitation requirements.	tool
`C5`	Data-Subject Rightsmeta	Whether GDPR data-subject requests are supported in code — erasure, export/portability, consent.	When this is weak, GDPR data-subject requests are not supported in code — no erasure, export or consent handling — so meeting a lawful request becomes a manual, risky scramble.	tool
`LA1`	Personal-Data Handling (GDPR)meta	LLM-confirmed personal-data handling surface — fields that are genuine personal data about a real person (not fiction/test/config), surfaced for the GDPR Art. 25/32 self-assessment. Advisory.	When this is weak, the code handles personal data the team hasn't yet confirmed is minimised, retention-limited and protected — a GDPR Art. 25/32 exposure flagged by AI for a human to review.	LLM · advisory
`LA3`	Vulnerability-Disclosure Policymeta	LLM-judged whether a SECURITY.md / security.txt is a real coordinated vulnerability-disclosure policy (contact + how to report + handling), not just a stub. Advisory.	When this is weak, there is no real coordinated vulnerability-disclosure policy (a security contact and a reporting process), so a researcher who finds a flaw has no safe way to report it (CRA/ISO), as judged by AI.	LLM · advisory
`LA4`	Dev/Test/Prod Separationmeta	LLM-judged whether configuration separates development/test/production (distinct per-environment settings) rather than commingling them. Advisory.	When this is weak, development, test and production may share configuration and secrets rather than being separated, raising the risk that a test setting or credential reaches production (ISO A.8.31), as judged by AI.	LLM · advisory
`S1`	Web-Security Posturemeta	Transport security, security headers, secure cookies, input validation, middleware order and crypto hygiene (presence, not runtime).	When this is weak, the web application lacks basic protections — transport security, security headers, secure cookies, input validation — leaving it open to common web attacks.	tool