# Security Requirements Catalog

Reference key: 
- ASVS = OWASP ASVS 5.0.0 (chapter.section)
- ISO 21434 = ISO/SAE 21434:2021 (clause)
- R155 / R156 = UN Regulations
- CCC DK = CCC Digital Key R3
- CWE = MITRE CWE
- NIST SSDF = SP 800-218.

## 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 | Ref | Rationale | Verify |
|----|-------------|-----|-----------|--------|
| SEC-ARCH-01 | Maintain a documented threat model (STRIDE per element) and a TARA covering every trust boundary; refresh it when the architecture changes. | ASVS - 15.2; ISO 21434 - Cl.9, Cl.15 | Credential/vehicle access is a high-impact asset; the threat model is the evidence base for assurance and 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. | 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 (device app, server, gateway, vehicle) with explicit, authenticated crossings. | ASVS - 15.2; R155 - Annex 5 | Prevents implicit trust assumptions between app ↔ server ↔ gateway ↔ vehicle. | Each boundary crossing requires authentication in design + test. |
| SEC-ARCH-04 | Default every security-control failure to a safe, no-access state (fail secure). | 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 | 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. | ASVS - 6.3, 6.8, 10.5 | State-changing operations (share/revoke) 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. | 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 "friend" key) to a valid owner attestation; reject issuance not backed by proof the requester owns the asset. | CCC DK - R3; 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. | CCC DK - R3; 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-SESS — Session & Token Management

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

| ID | Requirement | 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. | 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. | ASVS - 7.4 | A user must be able to terminate all sessions after a compromise. | Revoked session can no longer call the API. |

## 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 | 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. | ASVS - 8.2, 8.3; 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. | 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. speed cap, geofence, time window) server-side as authorization constraints, not advisory hints relayed downstream. | 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. | 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 | Ref | Rationale | Verify |
|----|-------------|-----|-----------|--------|
| SEC-VAL-01 | Validate all inputs against a positive (allow-list) schema — type, range, and format — before processing. | ASVS - 2.2, 1.2 | 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 by string concatenation. | 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). | ASVS - 2.3; 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. | ASVS - 2.3 | Hardens validity/duplicate checks against TOCTOU races. | Concurrent duplicate requests → only one succeeds. |

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

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

| ID | Requirement | Ref | Rationale | Verify |
|----|-------------|-----|-----------|--------|
| SEC-CRYPTO-01 | Generate and store cryptographic key **material** in a device Secure Element / trust anchor; never transit it in plaintext through the management plane, which operates on **references and attestations** only. | CCC DK - R3; 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). | 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. | 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. | ASVS - 11.5; CWE-330 | Object IDs appearing in URLs must not be guessable/enumerable. | ID entropy / non-sequential check. |

## SEC-COMM — Communication Security

**Use for:** designing network connections — client↔server, service↔service, or server↔device/vehicle (infrastructure and connectivity functions).

| ID | Requirement | Ref | Rationale | Verify |
|----|-------------|-----|-----------|--------|
| SEC-COMM-01 | Use TLS 1.3 with HSTS for all external client↔server traffic; reject downgrade and cleartext. | ASVS - 12.1, 12.2 | 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. | 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. | CCC DK - R3; 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-DATA — Data Protection & Privacy

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

| ID | Requirement | Ref | Rationale | Verify |
|----|-------------|-----|-----------|--------|
| SEC-DATA-01 | Classify and tag all PII fields; transmit only de-identified payloads to downstream endpoints (e.g. the vehicle receives no user ID or email). | ASVS - 14.1, 14.2 | Minimizes PII exposure across trust boundaries. | Downstream/vehicle 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). | ASVS - 14.2 | Retention must be defensible under applicable privacy regulation. | Retention/purge job test. |
| SEC-DATA-03 | Record and enforce consent / lawful-basis state when processing a third party's PII (e.g. a recipient's notification email). | ASVS - 14.2 | Issuing a shared credential processes another person's PII. | Consent-state presence and enforcement check. |

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

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

| ID | Requirement | 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. | 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. | 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. | 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. | ASVS - 16.3 | Non-repudiation depends on trustworthy time. | Time-source integrity check. |

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

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

| ID | Requirement | Ref | Rationale | Verify |
|----|-------------|-----|-----------|--------|
| SEC-API-01 | Enforce rate limiting / anti-automation per principal and per IP, with stricter limits on sensitive mutations. | ASVS - 2.4, 4.1 | 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. | 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. | ASVS - 16.5, 13.4; CWE-209 | Pairs with SEC-AUTHZ-02 to remove information-disclosure oracles. | Induced error returns a sanitized body. |

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

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

| ID | Requirement | Ref | Rationale | Verify |
|----|-------------|-----|-----------|--------|
| SEC-SUPPLY-01 | Run SAST, dependency/SCA, secret scanning, and IaC scanning as merge-blocking pipeline gates. | ASVS - 15.2; NIST SSDF | Makes the build security-gated, not advisory. | A failing scan blocks merge. |
| SEC-SUPPLY-02 | Build container images from pinned digests, sign them, and attach an SBOM; deploy only signed images. | 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. | 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. | R156; CCC DK - R3 | A revocation is a safety-relevant update to a remote component. | Update-integrity verification test. |

## SEC-VEHICLE — Endpoint / Vehicle Command Integrity

**Use for:** designing functions that issue commands or credentials to a remote endpoint/vehicle that may be intermittently connected.

| ID | Requirement | 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. | R155 - Annex 5; CCC DK - R3; 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. | 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 ranging) for passive-entry / proximity flows to mitigate relay attacks. | CCC DK - R3; 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. | CCC DK - R3; ISO 21434 - Cl.10 | A "revoked" DB row is meaningless if the endpoint still honors the credential. | Post-revoke: endpoint denies access + confirmation logged. |