# 01 — Control Frameworks as Code (NIST CSF 2.0 spine)

The reusable engine under every regime in this skill: pick an organizing spine,
crosswalk each outcome to a mechanism that already exists in your stack, and make
that mechanism emit its own evidence. Do this once and most of NIST CSF, 800-53,
800-171, SOC 2, ISO 27001, and the CRA fall out as views over the same controls.

## 1. Use NIST CSF 2.0 as the spine, not the control catalog

**Status (verified July 2026):** NIST Cybersecurity Framework **2.0** (CSWP 29)
was published **26 Feb 2024** and is current, superseding 1.1
(csrc.nist.gov/pubs/cswp/29). CSF is an **outcome map**, not a control list — it
says *what* good looks like and defers *how* to "Informative References"
(SP 800-53, etc.). That makes it the right top-level structure for a skill or a
control program; the concrete requirements come from rules/02–05.

**The six Functions** (2.0 added **Govern**, which wraps the other five):

| Function | Engineering meaning | Where the mechanism lives |
|---|---|---|
| **GOVERN** (GV) | Risk strategy, roles, policy, supply-chain oversight | Mostly organizational — note & route out (see SKILL boundary); the engineering hook is policy-as-code + the crosswalk itself |
| **IDENTIFY** (ID) | Asset & data inventory, risk assessment | `sota-privacy-compliance` rules/01 (data), `sota-cloud-infrastructure` (asset inventory), `sota-threat-modeling` |
| **PROTECT** (PR) | Access control, data security, platform hardening | `sota-identity-access`, `sota-secrets-management`, `sota-network-security`, `sota-sandboxing`, `sota-kubernetes` |
| **DETECT** (DE) | Continuous monitoring, anomaly detection | `sota-detection-engineering`, `sota-observability` |
| **RESPOND** (RS) | Incident handling, reporting | `sota-detection-engineering` (NIST 800-61), rules/04 clocks |
| **RECOVER** (RC) | Restoration, backups, continuity | `sota-cloud-infrastructure` (DR/backups), `sota-databases` |

The lesson: this skill's job is **binding and evidence**, not re-implementing
PROTECT/DETECT. If you find yourself writing an encryption or RBAC section here,
stop — reference the skill that owns it.

## 2. The crosswalk is the deliverable

**Rule:** For every control in scope, record three things as code in-repo — the
framework control ID, the *mechanism* that enforces it, and the *evidence source*
that proves it — with an owner. This single artifact serves every framework at
once and is the thing an assessor, a customer, or a future engineer actually uses.

```yaml
# GOOD: controls/sc-8.yaml — one control, many frameworks, a real mechanism
control: "Transmission confidentiality & integrity"
maps:
  nist_800_53: [SC-8, SC-8(1)]
  nist_800_171: ["3.13.8"]         # verify exact Rev 3 req ID against the 800-171r3 PDF
  csf_2_0: [PR.DS-02]
  cra: ["Annex I §1(2)(e)"]         # secure by default in transit
mechanism: >
  TLS 1.3 terminated at the mesh; mTLS between services (sota-network-security
  rules/04); FIPS-validated module in the moderate/CUI boundary (rules/02 §4).
evidence:
  - source: ci_policy
    query: "opa gate: deny plaintext listeners / TLS<1.2 — see policy/tls.rego"
  - source: mesh_config
    query: "istio PeerAuthentication STRICT, exported nightly"
owner: platform-team
inherited_from: ~   # or the CSP/PaaS control the customer inherits (FedRAMP CRM)
```

```text
BAD: a spreadsheet cell "SC-8 — Encryption in transit — Compliant" with no link
to a mechanism or a query. On sampling, two of five services listen plaintext
inside the cluster and nobody can produce proof either way.
```

**Build the crosswalk from the mechanism up, not the framework down.** Enumerate
what your systems already enforce (from the sota-* skills you apply), then attach
control IDs. You will find you already satisfy 70–90% of any framework — the work
is *mapping and recording*, the same insight `sota-privacy-compliance` rules/05
makes for SOC 2/ISO. Only the genuine gaps become new engineering.

## 3. Inheritance and shared responsibility

Most controls in a cloud system are **inherited** from the platform, not built by
you. Record the split explicitly or you will either re-build inherited controls or
claim controls you don't own:

- **Fully inherited** (e.g., physical security of a hyperscaler region) → reference
  the provider's attestation; you implement nothing.
- **Shared** (e.g., encryption at rest: provider offers KMS, *you* must enable it
  and manage keys) → your mechanism is "enabled + enforced by policy-as-code."
- **Customer** (e.g., your app's authz logic) → wholly yours.

FedRAMP calls this the Customer Responsibility Matrix (rules/02); the concept is
universal. A control marked "inherited" with no named provider control is a
finding.

## 4. Encode controls as gates, not prose

**Rule:** Every control that *can* be machine-enforced is a policy-as-code check at
CI and at the platform boundary (admission controllers, org policies/SCPs), not a
sentence in a PDF. Two products fall out of one policy: the **prevention** (the
control) and the **evaluation log** (the evidence).

```rego
# GOOD: a CUI/moderate data store cannot ship without validated crypto & boundary
# tags — one policy keeps the rules/02 boundary and FIPS requirement honest
deny[msg] {
  r := input.resource_changes[_]
  r.type in {"aws_s3_bucket", "aws_rds_cluster", "aws_dynamodb_table"}
  r.change.after.tags.data_category == "cui"
  not r.change.after.tags.boundary == "authorized"
  msg := sprintf("%s: CUI resource outside the authorization boundary", [r.address])
}
deny[msg] {
  r := input.resource_changes[_]
  r.change.after.tags.data_category == "cui"
  not r.change.after.kms_key_fips_validated   # your module verifies the KMS key's module
  msg := sprintf("%s: CUI at rest without FIPS-validated crypto (rules/02 §4)", [r.address])
}
```

Exceptions live in a register with `policy, resource, justification, compensating
control, owner, approved-by, expires` — CI re-fails the build the day an exception
expires. An exception that cannot expire is a policy change; argue it as one. (Same
discipline as `sota-privacy-compliance` rules/05 §4 and `sota-devsecops`.)

## 5. Baselines and tailoring

Frameworks ship **baselines** — predefined control sets keyed to system impact
(rules/02). Do not start from a blank catalog:

1. **Categorize the system** (impact: low/moderate/high, per data sensitivity —
   FIPS 199 in the US context).
2. **Inherit the matching baseline** as your starting control set.
3. **Tailor:** mark inherited controls, scope out non-applicable ones *with
   justification*, and add compensating controls where you deviate. Record the
   tailoring — an unjustified scope-out is the first thing an assessor pulls.

The tailoring record is the US-framework analog of ISO 27001's Statement of
Applicability (`sota-privacy-compliance` rules/05 §2): justify every inclusion and
exclusion, as code, reviewed like code.

## 6. Continuous, not point-in-time

A control that passed once and is never re-checked is a point-in-time artifact;
assessments increasingly want **operating effectiveness over time** (SOC 2 Type II,
FedRAMP ConMon, CMMC affirmation). The engineering consequence is the same one
that makes automation non-optional: you cannot retro-create a year of operating
evidence. So:

- Gates run on **every** change, and their logs are retained as the evidence
  population (`sota-devsecops`).
- Drift detection re-checks live infra against policy continuously.
- The crosswalk is reviewed at defined cadence; control owners get diffs, not
  a 300-row spreadsheet to rubber-stamp (the anti-pattern from
  `sota-privacy-compliance` rules/05 §2b).

Where a framework moves toward **machine-readable evidence** (FedRAMP 20x Key
Security Indicators, OSCAL control catalogs/SSPs), emit that format directly from
the enforcing system rather than transcribing into it — OSCAL SSP/SAP/SAR and
component definitions are the interchange target (rules/02).

## Audit checklist

- [ ] A control crosswalk exists **as code** in-repo: control ID → enforcing mechanism → evidence source → owner; covers the applicable framework(s), not one silo per framework
- [ ] CSF 2.0 (or the mandated framework) used as the organizing spine; controls reference the sota-* skill that owns the mechanism rather than re-implementing it
- [ ] Every control maps to a *running mechanism*, not a policy document; spot-check three controls by executing the gate / sampling the log
- [ ] Inherited vs shared vs customer responsibility recorded per control; no control claimed as inherited without a named provider control
- [ ] Machine-enforceable controls are policy-as-code gates at CI and the platform boundary; exception register with owner + expiry; CI re-fails on expiry
- [ ] System categorized (impact level) and the matching baseline inherited then tailored; tailoring (scope-outs, compensating controls) justified as code
- [ ] Evidence is generated by the enforcing system (CI log, IaC history, signed attestation, KSI/OSCAL feed) and producible in minutes — no screenshot evidence
- [ ] Controls re-evaluated continuously (gates on every change, drift detection), not point-in-time; evidence population generated by reproducible query
- [ ] Organizational controls (GOVERN, training, physical) explicitly marked as GRC/org-owned with the engineering hook noted — not silently skipped nor faked in code
- [ ] Framework versions/dates in the crosswalk re-verified against primary sources within the last 6 months

# 02 — NIST 800-53 / 800-171 / CMMC / FedRAMP

The US federal control stack. These four are one lineage: **SP 800-53** is the
master control catalog; **SP 800-171** is its tailored subset for protecting
Controlled Unclassified Information (CUI) on non-federal systems; **CMMC** is the
DoD program that *assesses* 800-171 implementation; **FedRAMP** applies 800-53
baselines to cloud services sold to the government. Learn the catalog once; the
rest are scopes and assessment wrappers over it.

> Statuses verified July 2026 against csrc.nist.gov, fedramp.gov, and the Federal
> Register. Re-verify dates before relying on them; route scoping/level decisions
> to your assessor or sponsor (engineering guidance, not assessment advice).

## 1. SP 800-53 — the control catalog

**Status:** **Rev 5**, finalized 10 Dec 2020 (Rev 5.1.1); the **SP 800-53/53B** catalog and baselines
reached **Release 5.2.0 on 27 Aug 2025** — the catalog is current
and actively maintained, no Rev 6 (csrc.nist.gov/pubs/sp/800/53/r5/upd1/final).

**20 control families**; Rev 5 added **PT** (PII processing) and **SR** (supply-
chain risk). The families engineers implement directly:

| Family | What it drives in code/infra |
|---|---|
| **AC** Access Control | RBAC/ABAC, least privilege, session control → `sota-identity-access` |
| **AU** Audit & Accountability | auditable events, log content, retention, tamper-evidence → `sota-observability`, `sota-detection-engineering` |
| **SC** System & Comms Protection | TLS, boundary/segmentation, FIPS crypto, key mgmt → `sota-network-security`, `sota-secrets-management` |
| **SI** System & Info Integrity | flaw remediation, malware, input validation, monitoring → `sota-code-security` |
| **CM** Configuration Management | baselines, least functionality, change control → `sota-devsecops`, `sota-kubernetes` |
| **IA** Identification & Authentication | MFA, authenticator mgmt (800-63) → `sota-identity-access` |
| **SA** System & Services Acquisition | secure SDLC, developer testing (SA-11/SA-15/SA-22) → rules/03 SSDF |

**Baselines (800-53B):** **low / moderate / high**, keyed to the system's impact
level (FIPS 199 categorization across confidentiality/integrity/availability),
plus a **privacy baseline** applied regardless of impact. Start from the baseline
and tailor (rules/01 §5) — never a blank catalog.

**Interchange format:** NIST publishes the catalog and baselines in **OSCAL**
(machine-readable JSON/XML/YAML). Consume OSCAL for the control catalog and emit
OSCAL SSP/SAP/SAR from your crosswalk (rules/01 §2) rather than hand-maintaining
Word documents.

## 2. SP 800-171 — protecting CUI on your systems

**Status:** **Rev 3 is FINAL — published 14 May 2024**
(csrc.nist.gov/pubs/sp/800/171/r3/final), superseding Rev 2. Re-derived from
800-53 Rev 5 moderate baseline; introduces **organization-defined parameters
(ODPs)** and reorganizes into **17 families** (Rev 2 had 14 — Rev 3 adds Planning,
System & Services Acquisition, and Supply Chain Risk Management).

> **Version caveat that bites right now:** CMMC Level 2 is currently pinned to
> **800-171 Rev 2** (110 controls) via the DoD rule text, even though Rev 3 is the
> current NIST publication. Which revision your contract requires is a
> **contract-level fact** — verify against the DFARS clause / SSP template before
> building to Rev 3 numbering. Rev 3 also **renumbered** some requirements, so
> confirm exact IDs against the 800-171r3 PDF, not memory.

**What CUI is:** government-created or -owned information that is not classified but
requires safeguarding (contract data, technical drawings, etc.). If you process,
store, or transmit CUI on a non-federal system, 800-171 applies.

**The requirements that drive architecture** (Rev 2 numbering shown; map forward
carefully):
- **Define and isolate the CUI boundary** — boundary protection (3.13.1) and
  subnetworks for publicly accessible components (3.13.5). This is the single
  biggest design decision: a **CUI enclave** (segmented network/accounts/identity)
  keeps scope small; a flat network puts the whole company in scope.
- **FIPS-validated cryptography** to protect CUI confidentiality (3.13.11) — a
  *validated module* (FIPS 140-3, CMVP certificate), not merely "AES somewhere."
  See §4.
- **Audit logging & retention** (3.3.x) — auditable events, protected logs,
  reviewed.
- **Separation of duties + least privilege** (3.1.x) and **MFA** (3.5.3) for
  network/privileged access.
- **SPRS score:** DoD contractors self-assess against 800-171 and post a score to
  the Supplier Performance Risk System; the SSP + POA&M are the assessable
  artifacts. Generate them from the crosswalk (rules/01), don't hand-write.

## 3. CMMC — assessing 800-171 for DoD

**Status:** the **CMMC program rule (32 CFR Part 170)** was published 15 Oct 2024
and became **effective 16 Dec 2024**. The **acquisition rule (48 CFR / DFARS, Case
2019-D041)** that lets DoD put CMMC clauses into contracts was published 10 Sep
2025, **effective 10 Nov 2025** (Federal Register 2024-22905 and 2025-17359). CMMC
is live; contract requirements are phasing in.

**Three levels:**
- **Level 1 (Foundational)** — Federal Contract Information (FCI); 15 requirements
  from FAR 52.204-21; **annual self-assessment**.
- **Level 2 (Advanced)** — CUI; **maps to NIST SP 800-171 (110 controls)**;
  self-assessment *or* third-party assessment by a **C3PAO** depending on the
  contract.
- **Level 3 (Expert)** — adds a subset of **SP 800-172** (enhanced controls for
  advanced persistent threats); government-led assessment.

**Phase-in** (per 32 CFR 170, clock from the 48 CFR effective date 10 Nov 2025):
Phase 1 (self-assessments) now → **Phase 2 (~Nov 2026)** L2 C3PAO certification in
solicitations → Phase 3 (~2027) L3 → Phase 4 (~2028) full inclusion. *Dates are
DoD-planned and can slip — verify against the actual DFARS clause at contract
time.* Engineering consequence: implement the 800-171 controls in §2, maintain an
SSP + POA&M as living, assessable evidence, and re-affirm annually.

## 4. FIPS-validated cryptography — the recurring hard requirement

CUI, FedRAMP, and many OT/federal contexts require **FIPS 140-3 validated
cryptographic modules** — not just "strong encryption." Engineering consequences:

- Use a crypto module holding a current **CMVP certificate** (check the module and
  version on the NIST CMVP list; "FIPS-capable" ≠ "validated" ≠ "operating in FIPS
  mode"). Verify the *module* your runtime actually loads.
- In cloud: use the provider's **FIPS-validated endpoints/KMS** and record the
  module in the crosswalk (`sota-secrets-management`). A non-validated library
  (or a validated one running outside FIPS mode) protecting CUI is a **critical**
  finding.
- Don't roll your own or use a non-validated cipher for in-scope data. This is the
  one place "the crypto works fine" is not the standard — validation is the
  requirement.

## 5. FedRAMP — 800-53 for government cloud

**Status:** the traditional program uses **800-53 Rev 5 baselines** at **Low /
Moderate / High** impact (FIPS 199), via **Agency ATO** or PMO paths. **FedRAMP
20x is a real, active initiative** (fedramp.gov/20x) reframing authorization toward
continuous, **machine-readable evidence** (Key Security Indicators) over
document-heavy SSPs — first 20x pilot authorizations issued **6 Mar 2026**, with
wider submission planned for **FY26 Q4**; consolidated program rules took effect
**4 Jul 2026**, and new Rev 5 certifications stop being accepted **11 Jun 2027**.
*Future-phase dates are FedRAMP estimates — re-verify at fedramp.gov/changelog.*

**Engineering implications (both paths):**
- **Authorization boundary:** a hard, documented edge around the service; every
  component and data flow that touches federal data is inside it and inventoried.
  Scope discipline is the whole game (as with the CUI enclave, §2).
- **Complete asset inventory**, reconciled continuously — a stale inventory is the
  most common ConMon finding.
- **Continuous monitoring (ConMon):** scanning, POA&M management, and change
  control run monthly, not at audit time.
- **20x-shaped work:** emit control evidence as **machine-readable KSIs** straight
  from the enforcing system (rules/01 §6) rather than transcribing into an SSP.
- **Customer Responsibility Matrix:** document which controls the consuming agency
  inherits from you vs. must implement themselves (rules/01 §3).

## Audit checklist

- [ ] System categorized (impact level / FIPS 199) and the correct 800-53 baseline (low/moderate/high) inherited then tailored, with justification as code
- [ ] If CUI is present: a defined, segmented CUI enclave/boundary — verified in network/IAM config, not asserted; publicly accessible components subnetworked
- [ ] FIPS-validated (140-3, CMVP-certificated) crypto module protects CUI/federal data at rest and in transit; the *loaded* module verified, and it runs in FIPS mode
- [ ] 800-171 revision in use matches the **contract** requirement (CMMC L2 may pin Rev 2); exact requirement IDs confirmed against the primary PDF, not memory
- [ ] CMMC level matches the contract; SSP + POA&M generated from the control crosswalk and kept current; SPRS score posted where required; annual affirmation wired
- [ ] AU/audit-logging controls implemented with retention + tamper-evidence; logs reviewed (mechanism, not manual promise)
- [ ] AC/IA controls: least privilege, separation of duties, MFA for privileged/network access — enforced by the IdP, not policy prose (`sota-identity-access`)
- [ ] FedRAMP (if applicable): authorization boundary drawn and enforced; asset inventory reconciled continuously; ConMon (scans/POA&M/change control) operating monthly; CRM published
- [ ] Where FedRAMP 20x applies, control evidence emitted as machine-readable KSIs from the enforcing system; OSCAL used for SSP/SAP/SAR interchange
- [ ] All statuses/dates in this file re-verified against primary sources (CSRC, fedramp.gov, Federal Register) within the last 6 months

# 03 — Secure SDLC: NIST SSDF (SP 800-218)

The framework that turns "we develop securely" from a claim into an assessable set
of practices. The SSDF is deliberately high-level and tool-agnostic; its value here
is as a **checklist to crosswalk your existing pipeline against** (rules/01), and
as the thing US federal buyers make you **attest to**. Almost none of it is new
engineering if you already apply `sota-devsecops`, `sota-testing`, and
`sota-secrets-management` — the work is mapping and closing gaps.

> **Status (verified July 2026):** the operative version is **SSDF v1.1, SP
> 800-218, published 3 Feb 2022** (csrc.nist.gov/pubs/sp/800/218/final). A **Rev 1
> (SSDF v1.2)** initial public draft appeared **Dec 2025** — *draft, not a
> baseline; do not cite as current.* **SP 800-218A** (AI/model development
> profile) is **final, 26 Jul 2024**. Re-verify before relying on any of these.

## 1. The four practice groups

SSDF organizes practices into four groups. Map each to the sota-* skill and CI
stage that already implements it:

| Group | Intent | Where it lives in your stack |
|---|---|---|
| **PO — Prepare the Organization** | Define security requirements, roles, toolchains, and criteria *before* coding | Governance + `sota-devsecops` (pipeline setup), `sota-docs-workflow` (requirements) |
| **PS — Protect the Software** | Protect code and releases from tampering | Source integrity, branch protection, artifact **signing & provenance (SLSA/Sigstore)**, protected registries → `sota-devsecops`, `sota-secrets-management` |
| **PW — Produce Well-Secured Software** | The design/code core: build security in | **Threat modeling** (`sota-threat-modeling`), secure defaults & secure coding (`sota-code-security` + language skills), **SAST/DAST/secret-scanning**, code review, vetting reused components → `sota-devsecops`, `sota-testing` |
| **RV — Respond to Vulnerabilities** | Find, triage, remediate, and root-cause post-release | VDP/CVD intake, scanning, SLA-tracked remediation → rules/04 (CRA overlaps), `sota-devsecops` |

**PW drives architecture and code most directly**; PS drives the pipeline; RV
drives operations. PO is largely governance with a few engineering hooks (the
toolchain and the security-requirements definition).

## 2. Make each practice a gate, not an intention

The failure mode assessors hunt is a **signed attestation whose practices aren't
enforced**. Encode the machine-checkable practices as CI gates so the attestation
is backed by a mechanism (rules/01 §4):

- **PW.7 / PW.8 (review & testing)** → SAST, DAST, and secret-scanning gates that
  fail the build; test-coverage and security-test suites (`sota-testing`,
  including its security-testing/WSTG rules).
- **PW.4 (reuse secure components)** → dependency scanning + an allowlist/denylist;
  SBOM generation (rules/04); no unvetted transitive pull-through.
- **PS.1 / PS.2 (protect & provide provenance)** → signed commits, SHA-pinned
  actions, **build provenance (SLSA)** and artifact signing (`sota-devsecops`).
- **PS.3 (archive & protect each release)** → immutable, signed release artifacts
  with retained provenance.
- **PW.1 (threat modeling / secure design)** → a design-review gate that references
  the threat model (`sota-threat-modeling` rules/06) for features crossing trust
  boundaries.
- **RV.1 (identify vulns continuously)** → scheduled dependency/container/runtime
  scanning with SLA-tracked tickets; **RV.2** remediation; **RV.3** root-cause.

The crosswalk row for each practice cites the gate and its evidence — the CI log
*is* the operating evidence (rules/01 §6).

## 3. Federal secure-software self-attestation

**Status (needs verification — enforcement scope has shifted across
administrations):** under OMB M-22-18 / M-23-16, software producers selling to the
US government are required to **self-attest** to SSDF-aligned practices via the
**CISA Secure Software Development Attestation Form**, with artifacts submitted
through CISA's repository (cisa.gov/secure-software-attestation-form). *Confirm the
current mandate, covered-software scope, and deadlines before asserting them* —
this is the most politically volatile item in this skill.

**Engineering consequence regardless of the mandate's status:** an attestation is
a **signed claim by a named officer**. Before anyone signs, the PW/PS/RV practices
must be *demonstrably enforced* — because the attestation is only as true as the
gates behind it, and a false attestation carries legal exposure (False Claims Act
risk in the US). Treat "can we sign this honestly?" as "are these practices gates
in CI?" Produce the artifacts (SBOM, provenance, scan results) the form references
straight from the pipeline.

## 4. SP 800-218A — AI / model development

If you develop or fine-tune AI models, **SP 800-218A** (final, Jul 2024) augments
the SSDF with model-specific tasks. The additions that drive engineering:

- **Training-data provenance & integrity** — data lineage, poisoning defenses,
  and the same inventory discipline as `sota-privacy-compliance` rules/01 extended
  to datasets (see `sota-ml-engineering` for leakage/lineage mechanics).
- **Model weights as high-value assets** — protect and sign them like release
  artifacts (PS practices applied to weights); access-control and provenance for
  checkpoints.
- **Dual-use foundation-model considerations** and eval/misuse testing before
  release (`sota-llm-engineering` evals, `sota-code-security` rules/08 for
  prompt-injection/agent surface).

This is the crosswalk target when an SSDF attestation or a customer questionnaire
asks about AI development specifically.

## 5. Don't rebuild — reference

The SSDF is intentionally a *reference framework*; the concrete SOTA practice for
every task it names already lives in this library. This rule's job is to give you
the **mapping** and the **attestation discipline**, not a second copy of the
pipeline guidance. When a PW/PS/RV practice needs implementing, jump to:

- `sota-devsecops` — the pipeline, SLSA/Sigstore provenance, SBOM, dependency & IaC
  scanning, admission control
- `sota-testing` — SAST/DAST placement, security testing (WSTG), fuzzing, mutation
- `sota-code-security` + the language skills — secure coding, the vuln classes
- `sota-secrets-management` — signing keys, protected credentials
- `sota-threat-modeling` — the PW.1 design analysis

## Audit checklist

- [ ] SSDF practices (PO/PS/PW/RV) crosswalked to concrete pipeline stages and sota-* mechanisms (rules/01); gaps tracked, not hand-waved
- [ ] PW machine-checkable practices are CI gates that fail the build: SAST, DAST, secret-scanning, dependency scanning, test suites
- [ ] PS: signed commits, SHA-pinned actions, build provenance (SLSA) and artifact signing; releases immutable, signed, provenance retained
- [ ] PW.1 secure-design/threat-modeling gate for features crossing trust boundaries, referencing the threat model
- [ ] RV: continuous vuln identification (deps/containers/runtime) with SLA-tracked remediation and root-cause analysis
- [ ] If federal self-attestation applies: the attested practices are demonstrably enforced *before* signing; SBOM/provenance/scan artifacts produced from the pipeline; current mandate/scope/deadline verified (not assumed)
- [ ] If developing/fine-tuning AI: SP 800-218A additions applied — training-data provenance/integrity, model weights protected & signed as high-value assets, eval/misuse testing before release
- [ ] Attestation, if any, backed by mechanisms not prose — no signed claim without an enforcing gate (False Claims exposure)
- [ ] SSDF version referenced is the current final (v1.1 / SP 800-218) unless a newer revision has been finalized; drafts not cited as baseline
- [ ] No pipeline guidance duplicated here — implementation deferred to `sota-devsecops` / `sota-testing` / `sota-code-security`

# 04 — EU Cyber Resilience Act (CRA)

The first horizontal EU law that makes **product cybersecurity** a legal
requirement for placing a "product with digital elements" on the EU market. Unlike
the framework crosswalks elsewhere in this skill, the CRA is binding regulation
with CE-marking, penalties, and hard reporting clocks — and its obligations are
overwhelmingly *engineering* obligations (SBOM, vulnerability handling, secure-by-
default, a maintained update channel). Retrofitting them is brutal; design them in.

> **Status (verified July 2026 against EUR-Lex and the European Commission):**
> Regulation **(EU) 2024/2847**, in force **10 Dec 2024**. Phased application:
> **conformity-assessment/notified-body provisions from 11 Jun 2026**;
> **reporting obligations (Art. 14) from 11 Sep 2026**; **main/essential
> requirements from 11 Dec 2027**. Article sub-numbering below should be confirmed
> against EUR-Lex before quoting verbatim; the dates and Art. 14 clocks are
> corroborated by the Commission's summary page. Re-verify — and route
> product-class/conformity-route decisions to counsel or a notified body.

## 1. Does it apply? Scope

- **Product with digital elements (PDE):** any software or hardware product (plus
  its remote data-processing solutions) whose intended or reasonably foreseeable
  use includes a direct or indirect logical/physical data connection to a device or
  network. Components placed on the market separately are covered.
- **Risk tiers → conformity route:** **default** (self-assessment, Module A) →
  **"important" products (Annex III), Class I and Class II** → **"critical"
  products (Annex IV)**. Higher tiers require stricter routes — third-party
  (notified-body) assessment or an EU cybersecurity certification scheme.
- **Open-source nuance:** non-commercial OSS is out of scope. The **open-source
  software steward** role (Art. 24) carries a lighter, tailored regime (a
  cybersecurity policy, vulnerability handling, cooperation) and stewards are **not
  subject to the penalty regime**. Commercial productization of OSS pulls you back
  into full manufacturer obligations.

If you sell software/hardware into the EU and it talks to a network or device,
assume in-scope and confirm the tier — the tier decides how heavy the conformity
route is, not whether the essential requirements apply.

## 2. Essential requirements → engineering work (Annex I)

Annex I has two parts: **Part I = product security properties**; **Part II =
vulnerability-handling process**. Both are engineering.

**Part I — secure by design & default:**
- Ship **without known exploitable vulnerabilities** → a **release gate** that
  blocks known-exploitable findings; a mechanism to know your components' CVE
  status (ties to the SBOM below and to `sota-devsecops` scanning).
- **Secure default configuration** — hardened out of the box, no default
  credentials, minimal attack surface, secure-by-default TLS/auth
  (`sota-code-security`, `sota-network-security`).
- Protect **confidentiality/integrity** of data and commands (encryption,
  authenticated updates), **minimize attack surface**, and provide
  **security-relevant logging** (`sota-observability`).

**Part II — vulnerability handling (for the whole support period):**
- **SBOM** covering at least the top-level dependencies → **generate in CI/CD**
  (SPDX or CycloneDX), keep it current per release, and be able to produce it
  (`sota-devsecops`). Pair with **VEX** to communicate which listed components are
  actually exploitable.
- **Coordinated Vulnerability Disclosure (CVD) policy** → a published intake
  (`security.txt`, a disclosure address/portal) and a documented handling process.
- **Timely security updates** over the **support period — by default at least 5
  years** (or the product's expected use time if shorter; confirm the exact Article
  reference in EUR-Lex): a **signed update channel** and a maintained
  long-lived branch. Updates must be **without delay** and **free** for security
  fixes; separable from feature updates.

## 3. The reporting clocks (Article 14) — wire them into on-call

For an **actively exploited vulnerability** in your product **or** a **severe
incident** affecting its security, report to the designated coordinating **CSIRT**
*and* **ENISA** via the single reporting platform:

| Stage | Deadline |
|---|---|
| **Early warning** | **≤ 24 hours** of awareness |
| **Notification** | **≤ 72 hours** of awareness |
| **Vulnerability final report** | ≤ 14 days after a corrective/mitigating measure is available |
| **Severe-incident final report** | ≤ 1 month after the incident notification |

Engineering consequence: this is a **detection + telemetry + workflow** problem,
not a legal one. You need to *know* within hours that a vuln in your product is
being exploited (threat intel, telemetry, disclosure intake — `sota-detection-
engineering`, `sota-observability`) and a rehearsed reporting runbook. A clock that
depends on someone happening to notice is already blown. These clocks sit alongside
NIS2 (24h/72h) and DORA (4h/24h/72h) covered in `sota-privacy-compliance` rules/04
§6 — build one incident pipeline that satisfies the strictest applicable clock.

## 3a. Triaging a report someone else sent you — what actually starts the clock

§2 gives you an **intake** (CVD policy, `security.txt`, a portal) and §3 gives you the
**outbound** clocks. The decision in between — is this real, is it ours, is it exploitable —
is the part with no obligation attached and the part the clocks depend on, because Article
14 runs from **awareness** and an untriaged report is precisely the state where "are we
aware?" is undecided. §3's warning that *"a clock that depends on someone happening to
notice is already blown"* applies to your own inbox, not just to telemetry.

The standards that own this are **ISO/IEC 30111:2019** (vulnerability *handling* — the
internal process: investigate, verify, prioritize, remediate) paired with **ISO/IEC
29147:2018** (vulnerability *disclosure* — the external interface to finders and users).
30111 is the one most teams have never read; it is the process behind the mailbox 29147
tells you to publish. *Both are under revision as ISO/IEC AWI 29147 / AWI 30111 — confirm
the current edition before citing one in an assessment.*

**R3a — write down when your clock starts, then triage against a fixed order.**

1. **Acknowledge on a stated SLA.** 29147 expects a responsive interface; silence is what
   turns a coordinated report into a public one.
2. **Reproduce before you rate.** A report is a *claim*. Rating from the reporter's summary
   is how a fabricated finding acquires a CVSS score and a deadline.
3. **Check that the cited code exists.** The 2026-specific step, and the cheapest: a
   machine-generated report is internally consistent, formatted like expertise, and may
   reference functions, files or call paths that are not in your tree. curl has published a
   worked example of exactly this shape. Grep the identifiers the report names *before*
   reading its argument — if they do not exist, you are done, and you learned it in a minute
   rather than an afternoon.
4. **Scope it: ours, a dependency, or documented behaviour?** A vulnerable dependency that
   your build does not reach is a **VEX** statement (§2) and an upstream conversation, not a
   product vulnerability and not an Article 14 report. Intended behaviour that surprises the
   reporter is a documentation fix.
5. **Rate it on `sota/rules/03` §1** — impact × exploitability in context — not on the
   reporter's claimed severity and not on CVSS alone (§1 there: CVSS may inform a rating; it
   is never the rating).
6. **Decide the clock explicitly and record the decision either way**, with its timestamp:
   does this meet "actively exploited vulnerability" or "severe incident" under §3? A
   recorded *no* is what makes a later *yes* defensible; an unrecorded no is
   indistinguishable from never having looked.
7. **Close the loop with the reporter**, including on reject. The reporter is the control
   that finds your next one.

**Triage capacity is a security property, not a nicety.** Inbound reports now arrive at
machine speed while triage stays human-speed, and the failure mode is not a wrong decision —
it is a queue nobody reads, which looks exactly like having no reports. curl, which has
handled well over a thousand reports, paused intake entirely for a month in July 2026 to
recover maintainer capacity; treat that as evidence that the queue is a resource to be
budgeted, and note that pausing intake does **not** pause a regulatory clock.

**The one lever you have on inbound quality is publishing what a usable report contains.**
Put it next to the intake address, and make the bar concrete rather than polite: a
human-written first paragraph saying what breaks and what that leads to; a **self-contained
reproducer** the team can build and run; the affected versions, with the earliest found by
bisecting; ideally a patch; and a reporter who stays reachable. That list is Daniel
Stenberg's, published from curl's intake in June 2026, and it doubles as your triage rubric
— a report missing the reproducer is not yet a finding, whoever or whatever wrote it.

## 4. Conformity & the harmonized-standards route

- **CE marking** signals CRA conformity. **Presumption of conformity** flows from
  **harmonized standards** being drafted by CEN/CENELEC under a Commission
  standardization request (a horizontal **EN 40000** series for all digital
  products, plus vertical/OT tracks).
- **Conformity routes — the split is conditional, not categorical.** Article 32(1) makes
  the **internal control procedure (Module A)** available, and 32(2) sends a **class I**
  important product to the stricter routes (module B+C, or module H) only *"where the
  manufacturer has not applied or has applied only in part"* harmonised standards, common
  specifications or a qualifying certification scheme at assurance level at least
  `substantial` — or where none exist. **Fully apply them and Module A remains open to class
  I.** Article 32(5) also provides a distinct route for products qualifying as free and
  open-source software. Critical products are the genuinely stricter case. Verified
  2026-09-16 against the Article 32 text; check which harmonised standards actually exist at
  your date of use, because "fully applied" is doing the work in that sentence.
  ([Regulation (EU) 2024/2847, Art. 32](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng))
- **ISA/IEC 62443 and NIST frameworks** are widely expected to *inform* the
  harmonized standards and are common industry mappings — CEN/CENELEC is adapting
  **EN IEC 62443-4-1 / 4-2** as the OT/industrial route (rules/05). **But being a
  formally-recognized presumption-of-conformity route depends on the harmonized
  standards actually cited in the Official Journal**, which are still being
  finalized (target dates around late 2026). *Flag: evolving — confirm the
  published hEN list at use time before claiming conformity via a standard.*

**Practical stance:** build to Annex I now (SBOM, CVD, signed updates, secure-by-
default, no-known-exploitable-vulns, the reporting pipeline). Those are true
regardless of which harmonized standard you later certify against, and they are the
expensive-to-retrofit parts. Track the hEN list; don't wait for it to start.

## 5. What this shares with the rest of the library

The CRA is mostly a **repackaging of good product-security engineering** with legal
teeth and deadlines. Reuse, don't rebuild:
- SBOM/provenance/signing → `sota-devsecops`; secure-by-default & vuln classes →
  `sota-code-security` + language skills; update-channel signing keys →
  `sota-secrets-management`; the incident/reporting pipeline → `sota-detection-
  engineering` + `sota-observability`; OT products → rules/05 (62443).

## Audit checklist

- [ ] CRA applicability determined: is it a PDE placed on the EU market? tier (default / important Class I–II / critical) identified; OSS-steward status if relevant
- [ ] Release gate blocks **known exploitable vulnerabilities** at ship; component CVE status known via SBOM + scanning
- [ ] **SBOM generated in CI/CD** (SPDX/CycloneDX), current per release, producible on request; VEX used to scope exploitability
- [ ] Secure-by-default config verified: no default credentials, hardened defaults, minimal attack surface, authenticated/encrypted comms and updates
- [ ] **Coordinated Vulnerability Disclosure** intake published (security.txt / portal) with a documented handling process
- [ ] The handling process is **written and ordered**, not just claimed: acknowledge SLA → reproduce → confirm the cited code exists → scope (ours / dependency-VEX / documented behaviour) → rate on `sota/rules/03` §1 → clock decision → reporter closed out (ISO/IEC 30111:2019 is the standard for this half; 29147:2018 for the interface)
- [ ] **When awareness begins is defined in writing** and a clock decision is recorded for every report **including the rejects**, with a timestamp — an unrecorded "not reportable" is indistinguishable from never having looked, and Article 14's 24h runs from awareness
- [ ] Triage capacity is budgeted and the queue's age is visible: an unread backlog is indistinguishable from having no reports, and pausing intake does not pause the clock
- [ ] The intake page states what a usable report must contain (human-written summary, self-contained reproducer, affected + earliest versions, ideally a patch) — the only lever on inbound quality, and the rubric triage then applies
- [ ] **Signed update channel** and a maintained branch covering the support period (default ≥ 5 years / expected use time); security updates delivered without delay, free, separable
- [ ] Article 14 reporting pipeline built and rehearsed: detection → 24h early warning / 72h notification to CSIRT + ENISA; final reports (14 days / 1 month) covered; unified with NIS2/DORA clocks where applicable
- [ ] Conformity route chosen for the tier (self-assessment vs notified body / certification scheme); CE-marking obligations understood
- [ ] Harmonized-standard reliance (incl. 62443 for OT) confirmed against the current OJ-published hEN list, not assumed
- [ ] All CRA dates/Article references re-verified against EUR-Lex / the Commission within the last 6 months (timeline is live: reporting from 11 Sep 2026, main obligations from 11 Dec 2027)

# 05 — ISA/IEC 62443 for OT / ICS / Embedded

The cybersecurity standard for **operational technology**: industrial control
systems (ICS), industrial automation and control systems (IACS), IIoT, and embedded
industrial products. Its models — **zones and conduits**, **Security Levels**, the
**7 Foundational Requirements** — assume a control-system, availability-first,
physical-process context that general IT frameworks don't. If your code runs a
turbine, a PLC, a medical device, or a factory line, this is your frame.

> **Scope honestly.** 62443 is **not** the right frame for general IT / SaaS / web
> apps — those fit ISO 27001, OWASP/ASVS, and NIST CSF/SSDF (rules/01–03). Reach
> for 62443 when the system is OT/ICS/IACS/embedded/industrial. Statuses below
> verified July 2026 against ISA, IEC, ISAGCA, and ISASecure; certification-scheme
> and CRA-harmonization details are evolving — re-verify at use time.

## 1. Family structure — the parts engineers touch

The series has four groups: **General (1-x)**, **Policies & Procedures (2-x)**,
**System (3-x)**, **Component (4-x)**. The engineering-facing parts:

| Part | What it governs |
|---|---|
| **62443-4-1** (2018) | **Secure product development lifecycle** — requirements on the *supplier's development process*: security requirements definition, secure-by-design, secure implementation, verification/validation testing, defect & patch management, product end-of-life. Prescriptive enough to certify against. |
| **62443-4-2** (2019) | **Technical security requirements for components** — four component types: software application, embedded device, host device, network device. |
| **62443-3-3** (2013) | **System security requirements + Security Levels** — system-level SRs mapped to the 7 FRs and the four SLs. |
| **62443-3-2** | Risk assessment & system design for zones/conduits — sets target SLs. |
| **62443-2-1 / 2-4** | The security *program* (CSMS) for asset owners / service providers — largely organizational (route out per the SKILL boundary). |

## 2. 62443-4-1 vs NIST SSDF — companions, not competitors

Both cover secure development. The difference is prescription:
- **SSDF (rules/03)** is broad, tool-agnostic, and **non-certifiable** — a
  reference framework.
- **62443-4-1** is **narrower and certification-oriented** (measurable process
  requirements, supports the ISASecure **SDLA** certification). It gives
  prescriptive, auditable detail for the same practices SSDF names at a higher
  level.

**Practical stance:** if you already run an SSDF-aligned SDLC (rules/03), you have
most of 62443-4-1; the gap is the *measurable process artifacts* and end-of-
life/patch-management rigor that a 4-1 audit expects. Crosswalk them (rules/01) —
one secure-SDLC, two framings.

## 3. Zones and conduits — the segmentation model

The architecture-driving core. Partition the IACS into **zones** (groupings of
assets by risk, function, and required security) and force all inter-zone
communication through controlled **conduits**:

- A zone groups assets with a common security requirement (e.g., the control zone
  vs. a DMZ vs. the enterprise/IT zone). Assign each zone a **target Security
  Level** from a risk assessment (62443-3-2).
- A conduit is the *only* sanctioned path between zones — a controlled channel
  (firewall, data diode, gateway) where you enforce and monitor traffic. No
  side-channels, no flat OT network.
- This is the OT expression of segmentation and blast-radius control that
  `sota-network-security` covers for IT — apply that skill's depth (default-deny,
  egress control) at the conduit, respecting OT constraints (availability first,
  legacy protocols, no casual patching).

A flat OT network with no zone/conduit model is the equivalent of the flat-network
finding in rules/02 — it makes everything one blast radius and defeats SL
assignment.

## 4. Security Levels (SL 0–4) and the 7 Foundational Requirements

**Security Levels** express resistance to escalating attacker capability:
- **SL 0** none · **SL 1** casual/accidental · **SL 2** intentional, low resources/
  skill · **SL 3** sophisticated, moderate resources (sector specialists) · **SL 4**
  nation-state, high resources.

Each zone carries an **SL vector** — one value per Foundational Requirement — in
three forms you must keep straight:
- **SL-T (Target):** required level, from the risk assessment.
- **SL-C (Capability):** what a properly-configured component/system *can* deliver.
- **SL-A (Achieved):** the actual level after deployment.

**Design obligation: ensure SL-C and SL-A ≥ SL-T for every zone.** Asserting an
SL-T with no risk assessment behind it, or deploying components whose SL-C can't
meet the target, is the core 62443 finding.

**The 7 Foundational Requirements** (all SRs in 3-3 and component requirements in
4-2 map to these):

1. **Identification & Authentication Control (IAC)** — who/what is acting.
2. **Use Control (UC)** — least privilege / authorized actions only.
3. **System Integrity (SI)** — code/config/data not tampered.
4. **Data Confidentiality (DC)** — protect data at rest/in transit.
5. **Restricted Data Flow (RDF)** — zones & conduits enforcement.
6. **Timely Response to Events (TRE)** — detection, logging, response.
7. **Resource Availability (RA)** — availability against DoS/degradation (the
   FR that most distinguishes OT: availability is the top priority, not
   confidentiality).

The mechanisms behind FR1–FR4, FR6 live in `sota-identity-access`,
`sota-code-security`, `sota-secrets-management`, `sota-detection-engineering`;
FR5 in the zone/conduit design (§3); FR7 in resilience/DR
(`sota-cloud-infrastructure`, `sota-architecture`) adapted to OT.

## 5. Certification and the CRA link

- **Certification exists.** **ISASecure** (an ISO/IEC 17065 scheme) certifies:
  **SDLA** → against 62443-4-1 (the dev process); **CSA** (Component Security
  Assurance) → 4-2 (a component); **SSA** (System Security Assurance) → 3-3 (a
  system). *A separate IECEE CB scheme also covers 62443 — confirm scope from a
  primary IECEE source before relying on it.*
- **CRA route (rules/04 §4):** CEN/CENELEC (TC65X WG3) is **adapting EN IEC
  62443-4-1 / 4-2 into CRA harmonized standards** for OT/industrial "important
  products" (CRA Annex III), which would grant presumption of conformity. Target
  dates cluster around **late 2026**, with a compressed runway before CRA
  obligations apply (Dec 2027). *Flag: EN designations and dates are reported
  inconsistently and are moving — verify against the OJ-published hEN list.*

**So for an OT/industrial product sold into the EU:** 62443-4-1/4-2 is likely your
*most direct* path to both a recognized OT security posture and (once harmonized)
CRA conformity. Build to it now; certify when the hENs land.

## Audit checklist

- [ ] 62443 is the *appropriate* frame — system is OT/ICS/IACS/embedded/industrial (not general IT/SaaS, which routes to ISO 27001 / CSF / SSDF)
- [ ] Zones and conduits defined: assets grouped into zones by risk/function; all inter-zone traffic forced through controlled, monitored conduits; no flat OT network
- [ ] Each zone has a **target Security Level (SL-T)** derived from a documented risk assessment (62443-3-2), not asserted
- [ ] Components/systems meet the target: **SL-C and SL-A ≥ SL-T** per zone, per FR; components selected/configured to their required capability level
- [ ] The 7 Foundational Requirements addressed with named mechanisms (IAC, UC, SI, DC, RDF, TRE, RA) — availability (FR7) treated as top priority per OT context
- [ ] Secure development per **62443-4-1** crosswalked to the SSDF SDLC (rules/03); measurable process artifacts, defect/patch management, and product end-of-life defined
- [ ] Component technical requirements (**4-2**) and system requirements (**3-3**) met for the relevant component types
- [ ] Patch/update strategy fits OT constraints (availability, maintenance windows, legacy) while still delivering security fixes over the support period
- [ ] If EU-market: 62443 harmonization path to CRA conformity tracked against the current OJ hEN list (rules/04); certification (ISASecure SDLA/CSA/SSA) pursued where required
- [ ] 62443 part versions, certification-scheme scope, and CRA-harmonization status re-verified against primary sources within the last 6 months