/secure-architecture-maturity

name: secure-architecture-maturity
description: >-
  Assess an architecture's control completeness against OWASP ASVS and an
  organization's security-practice maturity against OWASP SAMM. Use when a design
  review needs to state *how much* verification is enough (ASVS level) and whether
  secure-architecture practice is repeatable or one-off (SAMM maturity) — not just
  a single design's threats and controls.

Goal

Two answers `security-design-review` doesn't give on its own: which **ASVS** verification level this system must satisfy, and how mature the organization's **SAMM** practice is at producing/verifying designs like it — so the review lands on a defensible bar, not a vibe.

What to assess

1. **ASVS level (system-specific)** — OWASP ASVS 5.0 defines three verification levels by asset criticality:

• **L1** — opportunistic; low-risk, low-sensitivity apps; baseline hygiene only.
• **L2** — standard; most business apps handling sensitive data (the default

target for anything with auth, PII, or payments).

• **L3** — high-value/high-assurance; safety-critical, high-value transactions,

regulated data at scale, or systems where compromise is catastrophic. Pick the level from data sensitivity, user base, and blast radius — not from what's convenient to build. For requirement-level detail once the level is picked, use `security-knowledge:asvs-reference`; this skill only decides *which level applies* and *whether the architecture as designed can plausibly satisfy it*. 2. **SAMM maturity (organization-specific)** — OWASP SAMM v2 (formerly OpenSAMM, sometimes referenced as OSAMM) scores practice maturity 0–3 across five business functions: **Governance, Design, Implementation, Verification, Operations**. For architecture work, **Design** (threat assessment, security requirements, secure architecture) and **Verification** (architecture assessment, requirements-driven testing) are the relevant functions — score whether this review is a repeatable practice or a one-off favor.

Steps

1. Classify the asset: data sensitivity, user population, financial/safety impact, regulatory exposure → target **ASVS level** (L1/L2/L3). 2. Walk the architecture against that level's chapters (auth, session, access control, input handling, cryptography, data protection, communications, API/web service — see `security-knowledge:asvs-reference`); list what's satisfied, what's gap, what's unverifiable from the design alone. 3. Separately, score current **SAMM** maturity (0–3) for the Design and Verification functions at minimum — is threat modeling/design review routine and gated, or did it happen only because someone asked this time? Add Governance/Implementation/ Operations if in scope. 4. For each SAMM function below target, state the concrete next-level action (e.g. "Design 1→2: require a documented security requirements step before build starts on any L2+ system," not "improve design maturity").

Output

Two artifacts:

• **ASVS gap table** — chapter · requirement area · status (met/gap/unverifiable) ·

target level.

• **SAMM maturity scorecard** — business function · current level (0–3) · target

level · next-maturity action. Feed both into `security-design-review`'s recommendations and rank with `threat-modeling:risk-rank`.

Notes

Don't conflate the two: **ASVS** measures whether *this system's controls* are complete enough for its criticality; **SAMM** measures whether *the organization's process* that produced (and will re-verify) those controls is repeatable. A system can pass an ASVS L2 check today and still sit inside a SAMM Design-maturity-0 org — that's a real finding, not noise, because it predicts whether the next system built this way will also need a rescue review.