Controls crosswalk — ASVS 5.0.0 · MASVS 2.1 · CRA Annex I

Generated document. For each control this tree runs, the requirements it bears on and how far it reaches. Every figure below is derived from tools/conformance-map.json by tools/gen-conformance-docs.mjs; a hand edit here is a claim nobody reviewed and reds the docs-sync step.

What this document does not claim

A mapping is not a verification, and this document claims no level. A verification level attaches to a verification of an application performed by an assessor against that application; a template cannot hold one and a generator cannot confer one. This map states which live control in the tree bears on each requirement, how much of it that control reaches, and what is left — so an assessor starts from an honest ledger and a consumer never mistakes a template for a verification. It never says the generated application is ASVS Level 1, 2 or 3, MASVS-verified, or CRA-conformant, and tools/check-conformance-map.mjs reds any sentence in the register that does.

The CRA rows carry a shelf life. CRA conformity is a manufacturer’s legal act — Annex I obligations, a conformity assessment, a declaration, CE marking — that no code tree performs, and no harmonised standard for the CRA had been cited in the Official Journal as of 2026-08-16 — the register records: “none cited in the Official Journal as of the verified date; ETSI’s CRA ENs were in approval — re-verify per the calendar row conformance-cra-hens-citation”. The Annex I rows are mapped against the regulation’s text directly and must be re-read when a harmonised standard is cited.

Module rows are conditional. 8 row(s) rest on an opt-in module (module set in the register) and are graded on the assumption that the module is enabled; on a tree without it the row is CONDITIONAL, judged for liveness only where the module’s docs/modules/<name>/README.md marker exists, and its control may not run here at all.

Organisation-boundary rows are enumerated, never graded up. 39 row(s) name something only the operating organisation can meet (policies, processes, notifications, contracts); the register may not grade them covered or partial, and this document lists them so nobody mistakes the tree’s silence for the operator’s compliance.

Grades are conservative by rule. Absence of a surface is never coverage; where two grades are defensible the lower is taken; covered may not rest on documentation alone; and not-covered is not a failure the gate reds on — it is the honest statement of what would be needed.

Standing

392 mapped requirements: 11 covered, 149 partial, 105 not-covered, 127 not-applicable — ASVS 5.0.0 (345), MASVS 2.1 (24), CRA Annex I (23). The gate prints this exact partition (node tools/check-conformance-map.mjs) and scripts/check-claims.mjs holds the README to it, so the published figure and the register cannot drift apart.

Standard	Rows	covered	partial	not-covered	not-applicable
ASVS 5.0.0	345	10	116	94	125
MASVS 2.1	24	1	13	8	2
CRA Annex I	23	0	20	3	0

ASVS rows by the requirement’s OWN level (never a claimed one): L1 70, L2 183, L3 92. Boundary: harness 33, consumer 125, shared 195, organisation 39.

Chain-step controls

Every step of VALIDATE_STEPS and STOP_HOOK_STEPS (tools/harness.config.mjs), in chain order. A step is either listed here with the requirements it bears on, or listed under Unmapped chain steps with the reason no requirement is its subject — never neither, never both (tools/check-conformance-map.mjs closes it).

gate-integrity

• CRA Annex I: CRA-I.2.f (partial)

secrets

• ASVS 5.0.0: 13.3.1 (partial)

types

• ASVS 5.0.0: 15.3.5 (partial)

lint

• ASVS 5.0.0: 6.8.2 (partial), 7.2.1 (covered), 9.1.1 (partial), 11.1.3 (partial), 11.2.1 (partial), 11.3.4 (partial), 11.5.1 (partial), 13.4.6 (partial), 15.3.3 (partial), 15.4.1 (partial), 16.5.3 (partial)
• MASVS 2.1: MASVS-STORAGE-2 (partial)

resilience

• ASVS 5.0.0: 13.1.1 (partial), 13.1.3 (partial), 13.2.6 (partial), 16.5.2 (partial)
• CRA Annex I: CRA-I.2.i (partial)

observability

• ASVS 5.0.0: 14.2.3 (partial), 16.2.3 (partial)

expo-policy

• ASVS 5.0.0: 7.4.2 (partial), 12.2.1 (partial)
• MASVS 2.1: MASVS-NETWORK-1 (covered), MASVS-PRIVACY-1 (partial), MASVS-PRIVACY-3 (partial)
• CRA Annex I: CRA-I.2.e (partial), CRA-II.7 (partial)

version-sync

• ASVS 5.0.0: 3.7.1 (partial), 15.1.4 (partial)
• MASVS 2.1: MASVS-CODE-3 (partial)

schema-rls

• ASVS 5.0.0: 7.5.3 (partial), 8.2.2 (covered), 8.3.1 (covered), 8.3.3 (partial), 10.3.2 (partial), 10.3.3 (covered), 13.2.1 (partial), 13.2.2 (partial)

tenancy

• ASVS 5.0.0: 8.1.1 (partial), 8.1.3 (partial), 8.3.2 (partial), 8.4.1 (covered), 8.4.2 (partial), 11.7.2 (partial), 14.2.4 (partial), 16.2.1 (partial), 16.4.2 (partial)
• CRA Annex I: CRA-I.2.g (partial), CRA-I.2.l (partial)

auth-posture

• ASVS 5.0.0: 6.1.3 (partial), 6.2.5 (partial), 6.3.4 (partial), 6.3.7 (partial), 7.2.2 (covered), 7.2.4 (partial), 9.2.1 (partial), 10.1.1 (partial), 10.4.1 (partial), 10.4.5 (partial), 14.2.1 (partial), 14.3.3 (partial)
• MASVS 2.1: MASVS-AUTH-1 (partial), MASVS-PLATFORM-1 (partial)
• CRA Annex I: CRA-I.2.b (partial)

data-flow

• ASVS 5.0.0: 14.1.1 (partial), 14.2.7 (partial)
• MASVS 2.1: MASVS-PRIVACY-4 (partial)
• CRA Annex I: CRA-I.2.m (partial)

db-limits

• ASVS 5.0.0: 2.1.3 (partial), 2.3.2 (partial), 2.3.4 (partial), 4.3.1 (partial), 15.4.2 (partial), 15.4.3 (partial), 15.4.4 (partial)

contracts

• ASVS 5.0.0: 1.3.3 (partial), 2.1.1 (partial), 2.2.1 (partial), 2.2.2 (partial), 4.2.5 (partial)
• MASVS 2.1: MASVS-CODE-4 (partial)

query-shapes

• ASVS 5.0.0: 1.2.4 (partial)

rate-limits

• ASVS 5.0.0: 2.4.1 (partial), 6.1.1 (partial), 6.3.1 (partial), 15.1.3 (partial), 15.2.2 (partial)
• CRA Annex I: CRA-I.2.h (partial)

dead-code

• ASVS 5.0.0: 15.2.3 (partial)

architecture

• MASVS 2.1: MASVS-STORAGE-1 (partial)

route-manifest

• ASVS 5.0.0: 13.4.5 (partial)
• CRA Annex I: CRA-I.2.j (partial)

security-headers

• ASVS 5.0.0: 1.3.2 (partial), 3.2.1 (partial), 3.4.1 (covered), 3.4.3 (partial), 3.4.4 (partial), 3.4.5 (covered), 3.4.6 (partial), 3.4.7 (partial), 3.4.8 (covered), 3.5.7 (partial), 3.5.8 (covered), 4.1.1 (partial), 13.2.4 (partial), 14.2.2 (partial), 14.2.5 (partial), 14.3.2 (partial)
• CRA Annex I: CRA-I.2.k (partial), CRA-II.5 (partial), CRA-II.6 (partial)

validate

• CRA Annex I: CRA-I.1 (partial)

rls-isolation

• ASVS 5.0.0: 6.3.3 (partial), 6.8.4 (partial), 10.3.4 (partial), 16.3.1 (partial)
• MASVS 2.1: MASVS-AUTH-3 (partial)
• CRA Annex I: CRA-I.2.d (partial)

unit

• ASVS 5.0.0: 3.3.1 (partial), 3.3.2 (partial), 3.3.5 (partial), 3.5.1 (partial), 3.5.3 (partial), 8.2.1 (partial), 11.2.2 (partial), 11.2.5 (partial), 11.3.2 (partial), 11.3.3 (partial), 11.6.2 (partial), 12.3.1 (partial), 16.2.4 (partial), 16.2.5 (partial), 16.4.1 (partial), 16.5.1 (partial)
• MASVS 2.1: MASVS-CODE-2 (partial)

mobile-unit

• ASVS 5.0.0: 6.3.8 (partial), 6.5.6 (partial)

reviewer-verdicts

• ASVS 5.0.0: 15.3.1 (partial)
• CRA Annex I: CRA-II.3 (partial)

Unmapped chain steps

Steps that run on every validate and are named as no row’s control, each with its recorded reason.

• format — Source formatting (biome) has no subject in ASVS, MASVS or CRA Annex I — it is the harness’s own consistency floor, not an application security requirement.
• wiring — Hook/settings/lockfile wiring is the harness’s self-integrity check — that ITS enforcement is installed — and no requirement in the three standards asks an application to prove its development harness is wired.
• suppressions — The inline-suppression census governs how the enforcement layer may be silenced; it is a control ON the controls, and none of the standards enumerates it as an application requirement.
• provenance — Citation discipline on decision sites is a development-process control; CRA Annex I Part II asks for vulnerability handling and documentation, not for cited authorities on decision lines, and ASVS/MASVS do not ask for it at all.
• boundaries — Package-layering and export-wall closure is architectural hygiene (verticals ⊥ verticals, the reversibility wall); ASVS 5.0 dropped its architecture chapter and no remaining row demands module boundaries.
• native-deps — The reviewed native-module allowlist is Expo build hygiene; MASVS-CODE speaks to third-party components generally and is mapped through the dependency lanes, not through this allowlist.
• prompts — Prompt-file hash locking governs LLM prompt provenance — no row in the three standards addresses it.
• licenses — Licence compliance is a legal obligation outside all three security standards.
• types-drift — Freshness of the generated Supabase type mirror is a correctness control with no security-requirement subject.
• migrations — Append-only migration discipline and the DML/ADR markers are change-management hygiene; the schema controls that DO map (RLS, grants, audit) are claimed by schema-rls and tenancy, and claiming this step too would count one artefact twice.
• parity — Web/mobile feature parity has no security-requirement subject.
• build — That the tree compiles is a precondition of every other control, not a requirement any standard states.
• web-compile — That the web app compiles is a precondition of every other control, as for build. Its one security-bearing refusal, a Client Component importing a server-only module, backstops the server/client boundary whose named controls are the lint rules, the depcruise layering and the web-build lane's client-bundle purity scan, so it is not claimed as a row's evidence beside them.
• styleguide — Design-token discipline has no security-requirement subject.
• perf-budget — Bundle and interaction budgets have no security-requirement subject; the effect-cleanup leak scan is availability hygiene, not a standard’s row.
• e2e — The e2e step asserts spec PRESENCE for routes; the security-bearing e2e specs themselves are claimed by the web-e2e lane rows.
• docs-sync — docs-sync is the step that RUNS the two conformance registers and the documentation-drift closures; it is the judge of this map, so it may not be named as evidence inside it.
• diff-coverage — Per-file coverage floors are a test-quality control with no security-requirement subject; ASVS 5.0 carries no testing chapter.
• duplication — Token-clone detection has no security-requirement subject.
• i18n — The catalog-key rule and the Intl ban have no security-requirement subject.
• test-quality — Assertion-free/focused/disabled test detection is a test-quality control with no security-requirement subject.
• mobile-perf — Maestro-flow and startup-budget closure has no security-requirement subject.

Workflow-lane controls

CI jobs (and, for module rows, a module’s own workflow job) named as a control. A lane may be conditional — path-filtered, schedule-gated or event-gated — and the row’s note says which; the crosswalk lists what the lane bears on, not that it ran on a given commit.

web-e2e

• ASVS 5.0.0: 7.4.1 (partial), 7.4.4 (partial)

patch-window

• ASVS 5.0.0: 15.1.1 (partial), 15.2.1 (partial)
• CRA Annex I: CRA-II.2 (partial)

sbom-inventory

• ASVS 5.0.0: 15.1.2 (partial)
• CRA Annex I: CRA-II.1 (partial)

scan-pr

• CRA Annex I: CRA-I.2.a (partial)

publish

• CRA Annex I: CRA-I.2.c (partial)

Write-guard rule controls

Agent-time rules from .claude/hooks/lib/guard-rules.mjs named as a control: they refuse the WRITE, before any gate runs, and are live on every Edit/Write/Bash tool call. Their can-fail proofs are registered under the HOOK that runs them (tests/canary/injections.json hookRules).

dangerously-set-inner-html (pretool-write-guard.mjs)

• ASVS 5.0.0: 1.1.2 (partial), 1.2.1 (partial), 3.2.2 (partial)

weak-crypto-algorithm (pretool-write-guard.mjs)

• ASVS 5.0.0: 11.2.3 (partial), 11.3.1 (partial), 11.4.1 (partial), 11.4.3 (partial)
• MASVS 2.1: MASVS-CRYPTO-1 (partial)

read-env-file (pretool-bash-guard.mjs)

• ASVS 5.0.0: 13.3.2 (partial)

hardcoded-key-material (pretool-write-guard.mjs)

• MASVS 2.1: MASVS-CRYPTO-2 (partial)

Module-conditional rows

Rows that rest on an opt-in module. On a tree without the module the row is CONDITIONAL and its control is not judged for liveness.

• 11.2.2 (ASVS 5.0.0, partial) — module e2ee, control unit
• 11.2.5 (ASVS 5.0.0, partial) — module e2ee, control unit
• 11.3.2 (ASVS 5.0.0, partial) — module e2ee, control unit
• 11.3.3 (ASVS 5.0.0, partial) — module e2ee, control unit
• 11.3.4 (ASVS 5.0.0, partial) — module e2ee, control lint
• 11.6.2 (ASVS 5.0.0, partial) — module e2ee, control unit
• CRA-I.2.c (CRA Annex I, partial) — module eas-update, control publish
• CRA-I.2.e (CRA Annex I, partial) — module e2ee, control expo-policy

Organisation-boundary rows

Requirements only the operating organisation can meet. Enumerated so the tree’s silence is never read as the operator’s compliance; graded not-covered or not-applicable by rule.

• ASVS 5.0.0: 3.5.4 (not-applicable), 3.7.4 (not-applicable), 4.2.1 (not-applicable), 5.4.3 (not-applicable), 6.4.4 (not-applicable), 6.4.6 (not-covered), 7.4.5 (not-covered), 9.2.4 (not-applicable), 10.4.2 (not-applicable), 10.4.3 (not-applicable), 10.4.4 (not-covered), 10.4.6 (not-applicable), 10.4.7 (not-applicable), 10.4.10 (not-applicable), 10.4.11 (not-applicable), 10.4.12 (not-applicable), 10.4.13 (not-applicable), 10.4.14 (not-applicable), 10.4.15 (not-applicable), 10.4.16 (not-applicable), 10.7.1 (not-applicable), 10.7.2 (not-applicable), 10.7.3 (not-applicable), 11.1.1 (not-covered), 11.1.2 (not-covered), 11.1.4 (not-covered), 11.7.1 (not-applicable), 12.1.1 (not-applicable), 12.1.2 (not-applicable), 12.1.4 (not-applicable), 12.1.5 (not-applicable), 12.2.2 (not-applicable), 13.2.3 (not-covered), 13.3.4 (not-covered), 13.4.4 (not-applicable), 16.4.3 (not-applicable)
• CRA Annex I: CRA-I.2 (not-covered), CRA-II.4 (not-covered), CRA-II.8 (not-covered)