# Security Requirements Catalog — v2.0 (Multi-Platform)

---

## 0. Manual

### 0.1 Applicability profiles

Every requirement carries an **Applies** tag. Build the requirement set for a product by composing profiles:

| Tag | Scope |
|-----|-------|
| ALL | Every product type (platform-agnostic) |
| WEB | Browser-delivered frontend (web app / SPA) |
| API | Server-side services, APIs, backends (incl. microservices) |
| MOB | Mobile applications (Android / iOS) |
| VEH | Vehicle ecosystem: ECU / TCU / gateway / digital-key & companion backend |
| IOT | Consumer IoT / embedded devices + associated services |
| AI | Features embedding LLM / GenAI models or agents |

### 0.2 Assurance levels

Requirements default to **L2** unless tagged otherwise in the Applies column.

| Level | Meaning | Mapping |
|-------|---------|---------|
| L1 | Baseline — every production system | ASVS L1; MAS-L1 |
| L2 | Standard — systems handling sensitive data (default target) | ASVS L2; MAS-L2 |
| L3 | High assurance — safety-critical / high-value-target systems | ASVS L3; MAS-L2 + MAS-R; ISO/SAE 21434 high CAL |

Mobile resilience and privacy requirements additionally carry the MASTG testing-profile tags **[MAS-R]** / **[MAS-P]**.

---

## Reference key

- **ASVS** — OWASP Application Security Verification Standard **5.0.0** (May 2025), cited as `chapter.section` (chapter-level where 5.0.x renumbering risk exists). 17 chapters: V1 Encoding & Sanitization · V2 Validation & Business Logic · V3 Web Frontend Security · V4 API & Web Service · V5 File Handling · V6 Authentication · V7 Session Management · V8 Authorization · V9 Self-contained Tokens · V10 OAuth/OIDC · V11 Cryptography · V12 Secure Communication · V13 Configuration · V14 Data Protection · V15 Secure Coding & Architecture · V16 Logging & Error Handling · V17 WebRTC.
- **MASVS** — OWASP Mobile ASVS **2.1.0** (Jan 2024): 8 control groups / 24 controls (STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, PRIVACY). Verified via **MASTG** tests and **MASWE** weaknesses; testing profiles MAS-L1 / MAS-L2 / MAS-R / MAS-P.
- **ISO 21434** — ISO/SAE 21434:2021 *Road vehicles — Cybersecurity engineering* (clause-cited: Cl.5–7 org/project/distributed, Cl.8 continual activities, Cl.9 concept, Cl.10 development, Cl.11 validation, Cl.13 ops & incident response, Cl.14 end of support, Cl.15 TARA). Related: ISO/SAE PAS 8475 (CAL & Targeted Attack Feasibility), ISO/PAS 5112:2022 (audit guidelines).
- **R155 / R156** — UN Regulation No. 155 (CSMS + Annex 5 threat/mitigation catalog) / No. 156 (SUMS). Mandatory for all new vehicles in UNECE markets incl. EU since 07/2024. China analogues: GB 44495-2024 / GB 44496-2024 (new type approvals from 01/2026).
- **ISO 24089** — ISO 24089:2023 *Software update engineering* (engineering companion to R156).
- **CCC DK** — Car Connectivity Consortium Digital Key: Release 3 (V3.1.4) and Release 4 (V4.1.0, 2025 — NFC + BLE + UWB, cross-version interop). DK applet security target per Common Criteria PP-0119 (EAL4+).
- **EN 303 645** — ETSI EN 303 645 **V3.1.3** (2024-09), consumer IoT baseline (provisions 5.1–5.13 + data protection provisions); conformance assessment via ETSI TS 103 701.
- **API Top 10** — OWASP API Security Top 10 (2023), cited as `API#:2023`.
- **LLM Top 10** — OWASP Top 10 for LLM Applications **v2025**, cited as `LLM#:2025`.
- **NIST SSDF** — SP 800-218 v1.1; **SP 800-218A** (SSDF community profile for generative AI).
- **CWE** — MITRE CWE.
- Horizontal regulation to track: EU Cyber Resilience Act (Reg. (EU) 2024/2847, main obligations from 12/2027); Vietnam personal-data scope: Luật 91/2025 + Nghị định 356/2025.

---

# PART A — Cross-cutting requirements

## SEC-ARCH — Architecture, Threat Modeling & Secure Design

**Use for:** establishing system architecture, defining trust boundaries, and threat modeling — at the start of any design activity.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-ARCH-01 | Maintain a documented threat model (STRIDE per element); for vehicle/IoT scope additionally a TARA per ISO 21434 Cl.15 — covering every trust boundary; refresh it when the architecture changes. | ALL | ASVS - 15.2; ISO 21434 - Cl.9, Cl.15 | High-impact assets need an evidence base for assurance (and, for VEH, type approval). | Review gate: every identified threat has a mitigation and a test. |
| SEC-ARCH-02 | Record every security-relevant design decision as an ADR, with the residual risk explicitly accepted by a named owner. | ALL | ASVS - 15.1; ISO 21434 - Cl.9 | A bounded offline window (or similar) is a deliberate risk acceptance, not an implicit default. | ADR completeness review; each accepted risk has an owner. |
| SEC-ARCH-03 | Partition the system by trust zone (e.g. client app, server, gateway, device/vehicle) with explicit, authenticated crossings. | ALL | ASVS - 15.2; R155 - Annex 5 | Prevents implicit trust assumptions between zones. | Each boundary crossing requires authentication in design + test. |
| SEC-ARCH-04 | Default every security-control failure to a safe, no-access state (fail secure). | ALL | ASVS - 15.3 | A dependency outage must never silently grant access. | Fault injection: dependency down → access denied. |

## SEC-AUTHN — Authentication & Identity

**Use for:** designing identity, login, and token issuance — for any function that establishes who the caller is or performs a state-changing action.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-AUTHN-01 | Require an authenticated principal (OIDC via the platform IdP) on every state-changing operation; no anonymous path to any mutation endpoint. | ALL | ASVS - 6.3, 6.8, 10.5 | State-changing operations must never be reachable unauthenticated. | Negative test: unauthenticated request → 401. |
| SEC-AUTHN-02 | Use sender-constrained access tokens (proof-of-possession, e.g. DPoP / mTLS-bound) so a stolen bearer token alone cannot be replayed. | API | ASVS - 6.7, 9.1; CWE-294 | Closes token-theft → silent privileged action; upgrades plain bearer tokens. | Replay a captured token from another client → rejected. |
| SEC-AUTHN-03 | Bind credential issuance (e.g. a shared digital key) to a valid owner attestation; reject issuance not backed by proof the requester owns the asset. | VEH MOB | CCC DK; ASVS - 8.2; ISO 21434 - Cl.10 | Defeats "issue a credential for an asset you don't own" at the crypto layer, not just an authz check. | Issue without owner attestation → rejected. |
| SEC-AUTHN-04 | Re-validate the credential-to-device binding on device change; do not let a credential silently migrate to an unattested device. | VEH MOB | CCC DK; ASVS - 6.4 | Constrains device-switch continuity so a stolen/cloned device can't inherit a credential. | Use credential from an unbound device → rejected. |
| SEC-AUTHN-05 | Offer and enforce MFA (phishing-resistant where feasible, e.g. passkeys/WebAuthn) for accounts handling sensitive data; require step-up re-authentication for sensitive operations (payments, credential sharing, destructive actions). | ALL | ASVS - 6; MASVS-AUTH-3 | Password-only accounts are the dominant takeover path; step-up bounds blast radius of a hijacked session. | MFA enrollment/enforcement test; sensitive op without step-up → denied. |
| SEC-AUTHN-06 | Store user passwords only as salted, memory-hard hashes (Argon2id preferred; scrypt/bcrypt/PBKDF2 per current OWASP guidance); throttle and monitor verification attempts. | API | ASVS - 6; CWE-916 | A database leak must not yield reusable credentials. | Config review of hash params; brute-force attempt rate-limited + alerted. |

## SEC-OAUTH — OAuth 2.x / OIDC Flows

**Use for:** any delegated authorization or federated login integration (new dedicated chapter in ASVS 5.0).

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-OAUTH-01 | Use authorization code flow with PKCE for all public clients (mobile apps, SPAs); never implicit grant or resource-owner password credentials. | WEB MOB API | ASVS - 10; RFC 7636 | Code interception and credential-relay classes are eliminated by construction. | Flow review; attempt code exchange without verifier → rejected. |
| SEC-OAUTH-02 | Enforce exact-match redirect URI allow-lists; validate `state` (CSRF) and `nonce` (replay) and the issuer on every response (mix-up defense). | API WEB | ASVS - 10 | Open redirectors and mix-up attacks convert a benign IdP round-trip into token theft. | Redirect to unregistered URI / tampered state → rejected. |
| SEC-OAUTH-03 | Issue least-privilege scopes and audience-restricted tokens per resource server; rotate refresh tokens with reuse detection (revoke family on replay). | API | ASVS - 9, 10 | Over-scoped or replayable refresh tokens make one leak equal full compromise. | Replayed rotated refresh token → whole token family revoked. |

## SEC-SESS — Session & Token Management

**Use for:** designing session/token handling and lifetimes — wherever self-contained tokens (JWT) authorize requests.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-SESS-01 | Integrity-protect and audience-restrict self-contained tokens with short TTLs; validate signature, `iss`, `aud`, and `exp` on every call. | ALL | ASVS - 9.1, 9.2, 7.2 | Prevents token reuse across services and forged claims. | Tampered / expired / wrong-audience token → rejected. |
| SEC-SESS-02 | Propagate token revocation / blocklist within the defined SLA so a compromised session can be terminated server-side. | API | ASVS - 7.4 | A user must be able to terminate all sessions after a compromise. | Revoked session can no longer call the API. |
| SEC-SESS-03 | Invalidate all relevant sessions and refresh tokens on logout, password change, or privilege change; re-authenticate before security-sensitive account changes. | ALL | ASVS - 7 | Session fixation and "zombie session" persistence survive credential rotation otherwise. | Password change → all other sessions terminated. |

## SEC-AUTHZ — Authorization / Access Control (IDOR / BOLA)

**Use for:** designing any function that reads or modifies a per-user or per-object resource.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-AUTHZ-01 | Authorize every object access (by ID) at the operation level on a trusted server layer; never trust a client-supplied owner identity. | API | ASVS - 8.2, 8.3; API1:2023; CWE-639, CWE-862 | Direct fix for IDOR/BOLA on object-by-ID endpoints. | User B accessing user A's object → denied. |
| SEC-AUTHZ-02 | Make "not found" and "exists but not owned" indistinguishable — return the same `404` to a non-owner — to prevent resource enumeration. | API | ASVS - 8.4; CWE-204, CWE-203 | Removes the oracle where a `403` vs `404` discloses an object's existence. | Non-owner of an existing object → 404, identical to non-existent. |
| SEC-AUTHZ-03 | Enforce usage restrictions (e.g. spend limit, speed cap, geofence, time window) server-side as authorization constraints, not advisory hints relayed downstream. | API VEH | ASVS - 8.2, 2.3 | Server-authoritative constraints can't be stripped client-side. | Attempt to bypass/tamper a restriction → rejected. |
| SEC-AUTHZ-04 | Enforce cross-tenant isolation at the data layer (row-level) in addition to the service layer. | API | ASVS - 8.3, 14.2 | Defense in depth: an app-layer bug alone can't expose another tenant's data. | Query cannot return foreign-owner rows. |

## SEC-VAL — Input Validation, Encoding & Business Logic

**Use for:** designing any function that accepts external input or persists data.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-VAL-01 | Validate all inputs against a positive (allow-list) schema — type, range, and format — before processing. | ALL | ASVS - 2.2, 1.2; MASVS-CODE-4 | Reject malformed identifiers, time windows, and out-of-range parameters early. | Malformed / out-of-range input → 400. |
| SEC-VAL-02 | Use parameterized queries exclusively; never build SQL (or NoSQL/LDAP/OS commands) by string concatenation. | API | ASVS - 1.2; CWE-89 | The data layer handles user-influenced fields. | Injection payload in a field is inert. |
| SEC-VAL-03 | Allow-list request binding to block mass-assignment of server-controlled fields (status, owner ID, generated IDs, timestamps). | API | ASVS - 2.3; API3:2023; CWE-915 | Clients must not set privileged state or spoof ownership via the payload. | Extra/forbidden fields are ignored. |
| SEC-VAL-04 | Enforce business-logic invariants (bounded validity, end > start, no duplicate active grant) server-side and atomically. | API | ASVS - 2.3 | Hardens validity/duplicate checks against TOCTOU races. | Concurrent duplicate requests → only one succeeds. |
| SEC-VAL-05 | Allow-list any server-side fetch of user-influenced URLs/resources (SSRF defense): scheme/host allow-list, block internal ranges and cloud metadata endpoints, no credential forwarding, don't return raw fetched content. | API | API7:2023; CWE-918 | Server-side fetches are a pivot into internal networks and cloud control planes. | Payloads targeting `169.254.169.254` / internal hosts → blocked. |
| SEC-VAL-06 | Never deserialize untrusted data with native object deserialization; prefer data-only formats (JSON) with schema validation and integrity protection on serialized payloads. | API | ASVS - 1; CWE-502 | Native deserialization of attacker data is remote code execution by another name. | Gadget-chain payload → rejected before instantiation. |

## SEC-FE — Web Frontend Security

**Use for:** any browser-delivered UI (new dedicated chapter in ASVS 5.0).

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-FE-01 | Apply context-aware output encoding wherever untrusted data reaches HTML/JS/CSS/URL contexts (framework auto-escaping on); sanitize rich text only with a maintained sanitizer. | WEB | ASVS - 1, 3; CWE-79 | XSS remains the highest-frequency web frontend class; encoding at the sink is the durable fix. | Stored + reflected + DOM XSS payload suite is inert. |
| SEC-FE-02 | Enforce a restrictive Content-Security-Policy (nonce/hash-based; no `unsafe-inline`/`unsafe-eval`) plus hardening headers: `X-Content-Type-Options`, `Referrer-Policy`, and `frame-ancestors` (clickjacking). | WEB | ASVS - 3 | Defense in depth: a single missed encoding bug should not be exploitable. | Header scan; inline script injection blocked by CSP. |
| SEC-FE-03 | Set session cookies `Secure; HttpOnly; SameSite` (host-only, `__Host-` prefix where possible) and pair with anti-CSRF tokens for state-changing requests. | WEB | ASVS - 3; CWE-352 | Cookie theft via script and cross-site request forgery are closed at the transport/browser layer. | CSRF PoC without token → rejected; cookie flags verified. |
| SEC-FE-04 | Configure CORS with an explicit origin allow-list; never reflect arbitrary `Origin` values, and never combine wildcards with credentials. | WEB API | ASVS - 3; API8:2023 | Misconfigured CORS silently converts same-origin protections into cross-origin data exposure. | Cross-origin request from unlisted origin → no credentialed response. |

## SEC-FILE — File Handling

**Use for:** any upload, download, or filesystem-path feature (dedicated chapter in ASVS 5.0).

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-FILE-01 | Validate uploads by allow-listed extension + content-type + magic bytes, enforce size limits, re-encode images, and store outside the webroot under server-generated names. | WEB API | ASVS - 5; CWE-434 | Unrestricted upload is a direct webshell / stored-payload vector. | Polyglot/webshell upload → rejected or neutralized. |
| SEC-FILE-02 | Never build filesystem paths from user input; canonicalize and validate against an allow-listed base directory before any read/write. | API | ASVS - 5; CWE-22 | Path traversal turns a download endpoint into arbitrary file read. | `../` and encoded-traversal payloads → rejected. |
| SEC-FILE-03 | Serve user-supplied content from a separate origin/CDN with forced `Content-Disposition` and correct content types. | WEB API | ASVS - 5, 3 | Prevents stored XSS and content-sniffing attacks via hosted files. | Uploaded HTML/SVG never executes in the app origin. |

## SEC-CRYPTO — Cryptography & Key-Material Lifecycle

**Use for:** designing key-material handling, data-at-rest protection, or any cryptographic function.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-CRYPTO-01 | Generate and store cryptographic key **material** in a hardware-backed trust anchor appropriate to the platform (SE / TEE / StrongBox / Secure Enclave / HSM / TPM / SHE); the management plane operates on **references and attestations** only — never plaintext key material. | ALL | CCC DK; ASVS - 11.6; ISO 21434 - Cl.10 | Separates the management plane (records) from key material — the core control for credential systems. | Design review: no raw key material in server scope; plaintext key material → rejected. |
| SEC-CRYPTO-02 | Maintain a cryptographic inventory (algorithm, key, purpose); use only approved algorithms (e.g. AES-256-GCM at rest, TLS 1.3 suites, ECDSA/EdDSA). | ALL | ASVS - 11.1, 11.2, 11.3 | No ad-hoc crypto; auditable for assurance and type approval. | Inventory completeness review; no disallowed algorithms in use. |
| SEC-CRYPTO-03 | Encrypt sensitive/PII data at rest using envelope encryption with KMS/HSM-managed keys; rotate data keys and never store them beside ciphertext. | API | ASVS - 11.3, 14.2 | Establishes a key hierarchy rather than a flat "encrypted column". | Ciphertext at rest; key-rotation runbook exercised. |
| SEC-CRYPTO-04 | Source all randomness for IDs/nonces/tokens from a CSPRNG; identifiers used as security references must be unpredictable. | ALL | ASVS - 11.5; CWE-330 | Object IDs appearing in URLs must not be guessable/enumerable. | ID entropy / non-sequential check. |
| SEC-CRYPTO-05 | Design for crypto-agility: algorithms and key sizes replaceable via configuration backed by the inventory (SEC-CRYPTO-02); maintain a post-quantum migration plan for long-lived signatures and data. | ALL [L3] | ASVS - 11 | ASVS 5.0 elevates agility/PQC readiness; long-lived vehicle/IoT fleets outlive today's algorithms. | Tabletop: swap an algorithm without code redesign. |

## SEC-COMM — Communication Security

**Use for:** designing network connections — client↔server, service↔service, or server↔device/vehicle.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-COMM-01 | Use TLS 1.3 with HSTS for all external client↔server traffic; reject downgrade and cleartext. | ALL | ASVS - 12.1, 12.2; MASVS-NETWORK-1 | Baseline transport protection for the public surface. | TLS scan; cleartext/downgrade attempt fails. |
| SEC-COMM-02 | Mutually authenticate service-to-service traffic (mTLS) inside the trust mesh. | API | ASVS - 12.3; ISO 21434 - Cl.10 | One-way TLS to the client is insufficient between internal services. | Peer without a valid client cert → rejected. |
| SEC-COMM-03 | Integrity- and authenticity-protect commands to the vehicle/device end-to-end (signed), independent of transport TLS. | VEH IOT | CCC DK; R155 - Annex 5; ISO 21434 - Cl.10 | TLS terminates at the gateway; the endpoint must verify the command itself. | Tampered command rejected by the trust anchor. |
| SEC-COMM-04 | Automate certificate lifecycle (issuance, rotation, expiry monitoring) for public and internal PKI; no long-lived unmanaged certs. | API | ASVS - 12 | Expired or forgotten certs cause outages and drive risky "disable verification" workarounds. | Expiry alerting test; rotation exercised without downtime. |

## SEC-DATA — Data Protection & Privacy

**Use for:** designing functions that store, move, or expose personal/sensitive data.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-DATA-01 | Classify and tag all PII fields; transmit only de-identified payloads to downstream endpoints (e.g. the device/vehicle receives no direct user identifiers). | ALL | ASVS - 14.1, 14.2 | Minimizes PII exposure across trust boundaries. | Downstream/device payload contains no PII. |
| SEC-DATA-02 | Minimize and retain data per a defined policy with a lawful basis; purge on schedule (long audit retention must be justified, not indefinite). | ALL | ASVS - 14.2 | Retention must be defensible under applicable privacy regulation (e.g. GDPR; VN Luật 91/2025 + NĐ 356/2025). | Retention/purge job test. |
| SEC-DATA-03 | Record and enforce consent / lawful-basis state when processing a third party's PII (e.g. a share-recipient's notification email). | ALL | ASVS - 14.2 | Issuing a shared credential processes another person's PII. | Consent-state presence and enforcement check. |
| SEC-DATA-04 | Provide working data-subject flows: export and deletion of user data across backend **and** device-held copies. | ALL | ASVS - 14; EN 303 645 - 5.11; MASVS-PRIVACY-4 | Rights requests fail in practice when device/edge copies are forgotten. | Deletion request removes backend + device data within SLA. |

## SEC-LOG — Security Logging, Audit & Non-Repudiation

**Use for:** designing audit, logging, and any feature whose actions must be attributable (non-repudiation).

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-LOG-01 | Log all security-relevant events (auth, grant, revoke, authz failure, validation failure) with actor, action, object, outcome, and a trusted timestamp. | ALL | ASVS - 16.2, 16.3 | A complete security-event set, not just business actions. | Each event type produces a log entry. |
| SEC-LOG-02 | Make the audit log tamper-evident via cryptographic hash-chaining (each entry binds the prior entry's hash), in addition to DB-level append-only enforcement. | ALL [L3] | ASVS - 16.4; CWE-117, CWE-778 | DB-level revoke of UPDATE/DELETE doesn't stop a privileged insider; a legal-weight log needs an integrity proof. | Altering any entry breaks chain verification. |
| SEC-LOG-03 | Exclude secrets and unmasked PII from logs; mask or tokenize sensitive fields before write. | ALL | ASVS - 16.4, 13.4; CWE-532 | Prevents logs from becoming a PII/secret sink. | Log scrubbing: no PII/secret in output. |
| SEC-LOG-04 | Back all audit timestamps with a trusted, monotonic time source so ordering and freshness cannot be forged. | ALL | ASVS - 16.3 | Non-repudiation depends on trustworthy time. | Time-source integrity check. |
| SEC-LOG-05 | Ship security events to central monitoring with alerting on high-risk patterns (auth anomalies, authz-failure spikes, failed revocations); for vehicle scope this feeds the continual monitoring obligation. | ALL | ASVS - 16; ISO 21434 - Cl.8; R155 - 7.2.2 | Logs nobody watches are evidence, not defense; R155 requires detection & response capability. | Injected attack pattern raises an alert within SLA. |

## SEC-API — API Security & Anti-Automation

**Use for:** designing the public API surface and its abuse resistance.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-API-01 | Enforce rate limiting / anti-automation per principal and per IP, with stricter limits on sensitive mutations. | API | ASVS - 2.4, 4.1; API4:2023 | Stops brute-force, enumeration, and mutation flooding. | Rate limit triggers `429`. |
| SEC-API-02 | Validate HTTP message structure; reject oversized/malformed requests and enforce content-type and schema. | API | ASVS - 4.2 | Hardens the request ingress. | Malformed/oversized body → 400/413. |
| SEC-API-03 | Return generic error responses to clients; never leak stack traces, internal IDs, or system details. | API | ASVS - 16.5, 13.4; CWE-209 | Pairs with SEC-AUTHZ-02 to remove information-disclosure oracles. | Induced error returns a sanitized body. |
| SEC-API-04 | Maintain a complete API inventory (hosts, versions, environments); retire or disable undocumented, debug, and deprecated endpoints; keep schemas documented. | API | API9:2023; ASVS - 13 | Shadow and zombie APIs are the endpoints nobody patches or authorizes. | Discovery scan finds no undocumented live endpoints. |

## SEC-CONFIG — Configuration & Hardening

**Use for:** production configuration, environment separation, and platform hardening.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-CONFIG-01 | Ship hardened production configuration: debug features off, default accounts removed, verbose errors off, sample/admin content removed, admin surfaces network-isolated. | ALL | ASVS - 13; API8:2023; CWE-489 | Misconfiguration is the most commonly exploited "vulnerability" that isn't a code bug. | Config baseline scan; debug endpoints unreachable in prod. |
| SEC-CONFIG-02 | Track runtime components against EOL and patch SLAs by severity; pin versions (complements SEC-SUPPLY-01 scanning). | ALL | ASVS - 13; MASVS-CODE-3; NIST SSDF | Known-vulnerable components are the cheapest attack path. | EOL report clean; patch-SLA breach alerts. |
| SEC-CONFIG-03 | Separate environments and identities: no unmasked production data in lower environments; per-service least-privilege identities; no shared admin credentials. | API | ASVS - 13, 14 | Lower environments are softer targets holding the same data otherwise. | Lower-env data audit; IAM review per service. |

## SEC-SUPPLY — Supply Chain, Build & Secrets

**Use for:** designing build/CI-CD pipelines, infrastructure, dependency management, and update delivery.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-SUPPLY-01 | Run SAST, dependency/SCA, secret scanning, and IaC scanning as merge-blocking pipeline gates. | ALL | ASVS - 15.2; NIST SSDF | Makes the build security-gated, not advisory. | A failing scan blocks merge. |
| SEC-SUPPLY-02 | Build artifacts/images from pinned digests, sign them, and attach an SBOM; deploy only signed artifacts. | API VEH IOT | NIST SSDF; R156 | Supply-chain integrity for artifacts that ultimately drive endpoint commands. | Signature + SBOM verified at deploy. |
| SEC-SUPPLY-03 | Store secrets in a managed secret store (none in code, env files, or images) and rotate on a defined schedule. | ALL | ASVS - 13.3; CWE-798 | Closes hardcoded-credential risk. | Secret scan clean; rotation runbook exercised. |
| SEC-SUPPLY-04 | Deliver updates to the endpoint/vehicle (config / revocation) through a documented, integrity-checked update process. | VEH IOT | R156; ISO 24089; CCC DK | A revocation is a safety-relevant update to a remote component. | Update-integrity verification test. |
| SEC-SUPPLY-05 | Operate a vulnerability disclosure policy with an intake channel, triage SLAs, and coordinated disclosure; continuously monitor upstream advisories for shipped components. | ALL | EN 303 645 - 5.2; ISO 21434 - Cl.8; NIST SSDF | External researchers and upstream CVEs are a detection capability only if a working process receives them. | VDP published; test report acknowledged + triaged within SLA. |

---

# PART B — Mobile Applications (MASVS 2.1)

## SEC-MOB — Mobile App Security

**Use for:** any Android/iOS application. Server-side behavior of the same product is covered by Part A (API profile). Refs are MASVS 2.1.0 control IDs; verification via corresponding MASTG tests.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-MOB-01 | Store sensitive data only in platform-protected storage (Android Keystore/StrongBox-backed encryption, iOS Keychain/Data Protection); nothing sensitive in plaintext SharedPreferences, plists, SQLite, or external storage. | MOB | MASVS-STORAGE-1 | Device loss/compromise must not expose credentials or user data at rest. | MASTG storage tests: filesystem dump on rooted/jailbroken device yields no plaintext secrets. |
| SEC-MOB-02 | Prevent sensitive-data leakage via side channels: logs, crash/analytics SDKs, OS backups (`allowBackup`/exclusions), clipboard, keyboard cache, and app-switcher snapshots. | MOB | MASVS-STORAGE-2, MASVS-PLATFORM-3; CWE-532 | Data leaks most often through channels developers didn't design. | MASTG leakage tests: logcat/Console, backup extraction, snapshot inspection clean. |
| SEC-MOB-03 | Use platform crypto APIs with keys generated and used inside the hardware keystore; no keys hardcoded in code, resources, or config; bind step-up keys to biometric/user presence where required. | MOB | MASVS-CRYPTO-1, MASVS-CRYPTO-2 | Extractable or hardcoded keys void every control built on them. | Static analysis for embedded keys; key attestation checked server-side. |
| SEC-MOB-04 | Implement local (biometric/PIN) authentication via platform APIs gated on keystore-backed keys — never a client-side boolean — with rate-limited fallbacks. | MOB | MASVS-AUTH-2, MASVS-AUTH-3 | A hooked `onAuthSucceeded` bypasses UI-only biometric checks. | Instrumentation bypass attempt (Frida) fails to unlock protected key. |
| SEC-MOB-05 | Secure all traffic per platform best practice and pin certificates/public keys for endpoints under developer control, with an updatable pin set and pin-failure telemetry. | MOB [MAS-L2] | MASVS-NETWORK-1, MASVS-NETWORK-2 | Pinning defeats rogue/compromised CAs and casual MITM interception. | MITM proxy with system-trusted cert → connection refused. |
| SEC-MOB-06 | Minimize and permission-guard exported components; validate all IPC inputs, deep links / App Links / Universal Links (no open-redirect into auth flows); use immutable PendingIntents. | MOB | MASVS-PLATFORM-1; CWE-926 | Exported surfaces are the mobile equivalent of unauthenticated endpoints. | drozer/manifest review; malicious intent/deeplink PoCs rejected. |
| SEC-MOB-07 | Harden WebViews: JavaScript off unless required, JS bridges allow-listed and origin-checked, file/content access disabled, only trusted origins loadable. | MOB | MASVS-PLATFORM-2 | A permissive WebView imports the entire web threat model into the app. | Bridge invocation from untrusted origin fails. |
| SEC-MOB-08 | Enforce a minimum OS version and an app-update mechanism capable of forcing upgrades for security fixes. | MOB | MASVS-CODE-1, MASVS-CODE-2 | Fleets stuck on vulnerable versions negate shipped fixes. | Outdated client blocked/prompted per policy. |
| SEC-MOB-09 | Detect and respond to compromised platforms: root/jailbreak, emulators, and integrity failures — using server-verified attestation (Play Integrity / App Attest) for high-value actions. | MOB [MAS-R] | MASVS-RESILIENCE-1 | Client-only checks are strippable; server-side attestation moves the decision off-device. | Rooted device / failed attestation → sensitive action denied. |
| SEC-MOB-10 | Apply anti-tampering and anti-analysis for security-relevant logic: repackaging detection, debugger/hooking detection (Frida & co.), and obfuscation of protected code paths. | MOB [MAS-R] | MASVS-RESILIENCE-2, -3, -4 | Raises attacker cost for cloning, credential harvesting, and control bypass. | Instrumented/ repackaged build triggers defensive response. |
| SEC-MOB-11 | Minimize permissions, sensors, and identifiers (no stable hardware/user IDs for tracking); keep store privacy declarations consistent with observed traffic; provide user data control. | MOB [MAS-P] | MASVS-PRIVACY-1..4 | Privacy violations are findable by traffic analysis and are regulatory findings, not just ethics. | Traffic capture matches declared collection; tracking-ID scan clean. |

---

# PART C — Vehicle / Automotive

## SEC-VEH-GOV — Automotive Cybersecurity Governance (CSMS)

**Use for:** any product in a vehicle type-approval chain (OEM or supplier) — process-level obligations.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-VEH-GOV-01 | Operate a Cybersecurity Management System covering the full lifecycle; maintain a per-project cybersecurity plan and cybersecurity case as the evidence chain for type approval. | VEH | R155 - 7.2; ISO 21434 - Cl.5, Cl.6 | Without a certified CSMS and case, the vehicle type cannot be approved in UNECE markets. | CSMS audit (ISO/PAS 5112); cybersecurity case complete per milestone. |
| SEC-VEH-GOV-02 | Govern distributed development: assess supplier cybersecurity capability and bind responsibilities in a Cybersecurity Interface Agreement (CIA/CIAD) per component. | VEH | ISO 21434 - Cl.7; R155 - 7.2 | Most vehicle software is supplied; ungoverned interfaces are ungoverned risk. | Every supplied component has a signed interface agreement + evidence handover. |
| SEC-VEH-GOV-03 | Run continual cybersecurity activities: field monitoring, vulnerability analysis and management with triage SLAs, and an incident response capability through operations. | VEH | ISO 21434 - Cl.8, Cl.13; R155 - 7.2.2 | Type approval assumes detection and response for the fleet, not just secure design. | Injected field finding flows monitoring → triage → response within SLA. |
| SEC-VEH-GOV-04 | Define and communicate end of cybersecurity support and a decommissioning procedure (credential/key retirement, data removal). | VEH | ISO 21434 - Cl.14 | Fleets outlive support windows; undefined EoS silently becomes unpatched exposure. | EoS policy published; decommissioning runbook exercised. |

## SEC-VEH-NET — In-Vehicle Platform & Network Security

**Use for:** ECU/TCU/gateway design and in-vehicle communication (technical mitigations per R155 Annex 5).

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-VEH-NET-01 | Anchor each ECU in a hardware root of trust: secure/verified boot chain and key storage in HSM/SHE; only authentic firmware executes. | VEH | ISO 21434 - Cl.10; R155 - Annex 5 | Everything above boot inherits its integrity. | Modified bootloader/firmware image refuses to boot. |
| SEC-VEH-NET-02 | Authenticate and integrity-protect safety-relevant in-vehicle messages (e.g. AUTOSAR SecOC MACs with freshness) so bus access ≠ command authority. | VEH | R155 - Annex 5; ISO 21434 - Cl.10 | CAN-level spoofing/replay is the canonical vehicle attack once any node is compromised. | Injected/replayed frame on the bus is rejected by receivers. |
| SEC-VEH-NET-03 | Segment vehicle domains through a security gateway: filter diagnostics from drive domains; firewall all external interfaces (TCU, Wi-Fi, BT, USB, V2X). | VEH | R155 - Annex 5 | The infotainment/telematics blast radius must not reach powertrain/chassis. | Pentest: pivot from external interface to drive domain fails. |
| SEC-VEH-NET-04 | Protect diagnostic and debug access: UDS security access/authentication (0x27/0x29) with rate limiting, and disable or lock JTAG/SWD/UART in production units. | VEH | R155 - Annex 5; ISO 21434 - Cl.10 | Diagnostic services are privileged remote control if left open. | Seed-key brute force throttled; production board debug ports dead. |
| SEC-VEH-NET-05 | Harden ECU software: memory protection, minimal services, no hardcoded credentials, signed configuration/calibration data. | VEH | R155 - Annex 5; CWE-798 | Annex 5 mitigations assume baseline endpoint hardening. | Firmware analysis: no embedded creds; unsigned calibration rejected. |

## SEC-VEH-OTA — Software Update (SUMS / OTA)

**Use for:** any over-the-air or workshop software update path (regulatory pair: R156 + ISO 24089).

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-VEH-OTA-01 | Operate a Software Update Management System: track software configurations per vehicle type (RXSWIN), and assess safety/compliance impact before releasing an update. | VEH | R156; ISO 24089 | Updates change the approved configuration; unmanaged updates void type approval. | RXSWIN/config records match fleet state; release gate includes impact assessment. |
| SEC-VEH-OTA-02 | Sign update packages end-to-end and verify on-vehicle before installation; enforce anti-rollback to prevent downgrade to vulnerable versions. | VEH | R156; ISO 24089; ISO 21434 - Cl.10 | The update channel is the highest-value persistent-compromise vector in a fleet. | Tampered or downgraded package rejected by the target ECU. |
| SEC-VEH-OTA-03 | Make updates fail-safe: guarantee a safe vehicle state on interruption/failure, verify post-install integrity, and inform the user of update state per regulation. | VEH | R156; ISO 24089 | A bricked or half-updated ECU is a safety event, not just an availability event. | Power-loss-mid-update test recovers to a safe, known version. |

## SEC-VEHICLE — Endpoint / Vehicle Command & Credential Integrity

**Use for:** designing functions that issue commands or credentials to a remote endpoint/vehicle that may be intermittently connected. *(Carried from v1 unchanged.)*

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-VEHICLE-01 | Include a freshness factor (nonce / monotonic counter / signed timestamp) in every command to the endpoint; the endpoint rejects replays. | VEH | R155 - Annex 5; CCC DK; ISO 21434 - Cl.15 | Prevents replay of captured grant/unlock/revoke commands. | Replayed command rejected. |
| SEC-VEHICLE-02 | Bound offline credential validity to the shortest feasible TTL; route safety-critical revocations through an expedited path and fail secure when the trust anchor is unreachable past TTL. | VEH | ISO 21434 - Cl.9; R155 - Annex 5 | Turns an offline-tolerance window into a bounded, risk-accepted, fail-secure control. | Revoked credential denied after TTL offline. |
| SEC-VEHICLE-03 | Use distance-bounding (e.g. UWB secure ranging) for passive-entry / proximity flows to mitigate relay attacks. | VEH | CCC DK (R3/R4); R155 - Annex 5 | Relay attack is the signature threat for proximity credentials. | Relay scenario mitigated by ranging (design + test). |
| SEC-VEHICLE-04 | Invalidate a revoked credential at the endpoint's trust anchor (not merely a server DB status flag), with confirmation of effective revocation. | VEH | CCC DK; ISO 21434 - Cl.10 | A "revoked" DB row is meaningless if the endpoint still honors the credential. | Post-revoke: endpoint denies access + confirmation logged. |

---

# PART D — Consumer IoT / Embedded (ETSI EN 303 645)

## SEC-IOT — IoT Device Baseline

**Use for:** consumer IoT / embedded devices and their associated services. Cross-cutting mappings: VDP → SEC-SUPPLY-05 (prov. 5.2), transport security → SEC-COMM (5.5), personal data & deletion → SEC-DATA (5.8, 5.11).

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-IOT-01 | No universal default passwords: per-device unique credentials or user-set at initialization; secure onboarding/pairing. | IOT | EN 303 645 - 5.1; CWE-1392 | Default credentials remain the top mass-exploitation vector for device botnets. | Factory-state device refuses operation on default/shared credentials. |
| SEC-IOT-02 | Keep device software securely updatable for a **declared support period**: signed updates verified on-device before install, with the support period disclosed to buyers. | IOT | EN 303 645 - 5.3, 5.7 | Unpatchable fleets become permanent attack infrastructure. | Unsigned/tampered update rejected; support period published. |
| SEC-IOT-03 | Store sensitive security parameters securely (hardware-backed where available); no hardcoded remote-service credentials or per-model shared secrets in firmware. | IOT | EN 303 645 - 5.4; CWE-798 | One firmware dump must not compromise the fleet or the cloud. | Firmware extraction/analysis yields no reusable credentials. |
| SEC-IOT-04 | Minimize the attack surface: unused network ports closed, debug interfaces (UART/JTAG/SWD) disabled or locked in production, services run least-privilege, secure boot enforced. | IOT | EN 303 645 - 5.6, 5.7 | Every open port/pad is a free entry point post-purchase. | Port scan + board-level inspection: no accessible debug/unused services. |
| SEC-IOT-05 | Remain resilient to network/power outage (core function degrades safely), examine telemetry for security anomalies, and validate all input on device APIs. | IOT | EN 303 645 - 5.9, 5.10, 5.13 | Availability failures and unvalidated local APIs are the quiet half of device risk. | Outage test degrades safely; malformed local API input rejected. |

---

# PART E — AI / LLM-Enabled Features

## SEC-AI — GenAI & Agent Security

**Use for:** any feature embedding an LLM, RAG pipeline, or tool-using agent. Conventional controls in Parts A–D still apply to the surrounding app.

| ID | Requirement | Applies | Ref | Rationale | Verify |
|----|-------------|---------|-----|-----------|--------|
| SEC-AI-01 | Treat all model input crossing a trust boundary as untrusted: segregate system instructions from user/third-party content, and defend against direct **and indirect** prompt injection (content tagging/spotlighting, input filtering, policy checks on resulting actions). | AI | LLM01:2025; NIST SSDF (SP 800-218A) | Injected instructions in user input or retrieved content hijack model behavior and downstream tools. | Adversarial suite (direct + indirect injection corpora, e.g. Promptfoo/Garak/PyRIT) meets defined pass threshold. |
| SEC-AI-02 | Treat model **output** as untrusted input: encode before rendering, validate against schema before parsing, and never execute generated code/SQL/URLs without a policy gate. | AI | LLM05:2025; CWE-79, CWE-94 | Improper output handling turns the model into an injection proxy (XSS/RCE by generation). | Generated payloads (script/SQL) are inert in downstream sinks. |
| SEC-AI-03 | Constrain agency: least-privilege, allow-listed tools per agent; per-user authorization enforced at the tool layer (not by the model); human confirmation for state-changing or irreversible actions. | AI | LLM06:2025 | The model must not be the authorization layer; excessive agency converts prompt injection into real-world actions. | Injected instruction to misuse a tool → blocked at tool authz; destructive action requires confirmation. |
| SEC-AI-04 | Protect sensitive data in the AI path: no secrets in system prompts (assume leakable), DLP/redaction on prompts and completions, and an approved-data policy for third-party model providers. | AI | LLM02:2025, LLM07:2025 | Prompts and context windows are a new, poorly-audited data egress channel. | System-prompt extraction yields no secrets; DLP blocks seeded PII/secret in prompt. |
| SEC-AI-05 | Secure the model supply chain: verify provenance/signatures of models and adapters, pin versions, evaluate third-party models before use, and protect training/RAG data against poisoning. | AI | LLM03:2025, LLM04:2025; NIST SSDF | Models are executable dependencies; poisoned weights or corpora are persistent backdoors. | Model registry shows signed, pinned artifacts; RAG ingestion applies source allow-lists. |
| SEC-AI-06 | Bound consumption: per-principal quotas on tokens/requests/tool invocations and cost alerting to prevent denial-of-wallet and resource exhaustion. | AI | LLM10:2025; API4:2023 | Unbounded generation is an availability and budget attack surface. | Load test triggers quota + alert before service/cost impact. |