@blamejs/exceptd-skills 0.9.1

package/skills/supply-chain-integrity/skill.md

@@ -0,0 +1,318 @@
+---
+name: supply-chain-integrity
+version: "1.0.0"
+description: Supply-chain integrity for mid-2026 — SLSA L3+, in-toto attestations, Sigstore signing, SBOM (CycloneDX/SPDX), VEX via CSAF 2.0, AI-generated code provenance, model weights as supply-chain artifacts
+triggers:
+  - supply chain
+  - slsa
+  - sbom
+  - vex
+  - sigstore
+  - cosign
+  - in-toto
+  - cyclonedx
+  - spdx
+  - software composition
+  - model provenance
+  - ai bom
+  - aibom
+  - csaf
+data_deps:
+  - cve-catalog.json
+  - atlas-ttps.json
+  - framework-control-gaps.json
+  - rfc-references.json
+  - cwe-catalog.json
+  - d3fend-catalog.json
+atlas_refs:
+  - AML.T0010
+  - AML.T0018
+attack_refs:
+  - T1195.001
+  - T1195.002
+  - T1554
+framework_gaps:
+  - NIST-800-218-SSDF
+  - SLSA-v1.0-Build-L3
+  - VEX-CSAF-v2.1
+  - CycloneDX-v1.6-SBOM
+  - SPDX-v3.0-SBOM
+  - NIST-800-53-SA-12
+  - HITRUST-CSF-v11.4-09.l
+  - SWIFT-CSCF-v2026-1.1
+  - FedRAMP-Rev5-Moderate
+  - CMMC-2.0-Level-2
+rfc_refs:
+  - RFC-8032
+forward_watch:
+  - SLSA v1.1 (draft) — adds attestation chain requirements above L3 and a hardened-builder profile; track for re-baselining
+  - CSAF 2.1 finalization — VEX status vocabulary expansion and machine-readable advisory pivoting
+  - CycloneDX 1.7 — ML-BOM enrichment, model card embedding, training-data lineage fields
+  - SPDX 3.1 — AI profile maturation, dataset provenance schema stabilization
+  - EU CRA (Regulation 2024/2847) — implementing acts for technical documentation and SBOM submission expected through 2027
+  - OpenSSF model-signing — emerging Sigstore-based signing standard for ML model weights; track for production adoption
+cwe_refs:
+  - CWE-1357
+  - CWE-1395
+  - CWE-494
+  - CWE-502
+  - CWE-829
+d3fend_refs:
+  - D3-CBAN
+  - D3-EAL
+  - D3-EHB
+last_threat_review: "2026-05-11"
+---
+
+# Supply-Chain Integrity Assessment
+
+## Threat Context (mid-2026)
+
+The supply chain has expanded far beyond "a vulnerable dependency in npm or PyPI." In mid-2026 the in-scope artifacts are every build-pipeline input, every CI runner image, every container base, every transitive package, every model weight loaded at inference time, and every snippet of code generated by an AI coding assistant and committed to the repository.
+
+The defining incidents driving this expansion:
+
+- **CVE-2026-30615 (Windsurf MCP zero-interaction RCE)** — a developer tool, distributed without enforced manifest signing or provenance attestation, executed attacker-controlled code with zero user interaction. The vulnerability class is reachable across the AI coding-assistant ecosystem (150M+ combined downloads). See the `mcp-agent-trust` skill for the trust-boundary analysis; this skill addresses the supply-chain artifact-integrity layer.
+- **AI-generated code is opaque-provenance code.** GitHub Copilot, Cursor, Claude Code, Windsurf, Codex, and Gemini CLI emit code that is committed without attestation of which model produced it, against what context, with what training cutoff. SBOM completeness claims that omit AI-generated code are theater — the SBOM lists `npm:lodash@4.17.21` but not "function `parseUrl` was emitted by Copilot from a docstring that contained an indirect prompt injection."
+- **Model weights are native binary artifacts that execute on load.** PyTorch `.pt` checkpoints in code-executing serialization formats distributed via Hugging Face / GitHub LFS are CWE-502 deserialization vectors. Hash-pinning a malicious blob does not prevent execution; only signature verification against a pinned publishing key (Sigstore keyless or OpenSSF model-signing) plus a non-executing format (safetensors) closes the class.
+- **Typosquat campaigns target the MCP, Hugging Face, npm `@modelcontextprotocol/*`, and PyPI ML namespaces.** The MITRE ATLAS technique AML.T0010 (ML Supply Chain Compromise) is the umbrella class; AML.T0018 (compromised model weight) is the specific artifact.
+- **The XZ Utils backdoor (2024, CVE-2024-3094)** remains the canonical example of a maintainer-position long-game supply-chain compromise that no SBOM-only program detects. The defense is in-toto attestation chain plus reproducible builds plus maintainer-key transparency — none of which are mandated by current compliance frameworks.
+
+Mid-2026 baseline expectations have shifted to: SLSA Build L3 minimum on every release pipeline; in-toto attestations for every step in the build graph; Sigstore keyless signing (cosign + Fulcio + Rekor) for container images, packages, and model weights; CycloneDX 1.6 or SPDX 3.0 SBOM at build time and re-verification at deploy time; CSAF 2.0 VEX statements published by vendors and consumed by operators to filter false-positive vulnerability noise. Adoption is uneven — security-mature orgs and open-source foundations (Kubernetes, Sigstore, Linux Foundation projects) are at or near this baseline; most enterprise pipelines are between SLSA L1 and L2 with no attestation chain and no VEX consumption.
+
+This project itself uses Ed25519 (RFC 8032) signing for skill integrity (`lib/sign.js`, `lib/verify.js`, public key at `keys/public.pem`). That is the smallest-scale living example of the broader pattern this skill defines: artifacts are signed by an identified key, signatures are verified before load, tampered artifacts are rejected, and the signing key is operationally separated from the artifact registry. The same pattern scales to every layer of the build pipeline — exceptd is just the scoped-to-one-repo version.
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control | Why It Fails for mid-2026 Supply Chain |
+|---|---|---|
+| NIST SP 800-218 SSDF | PS, PW, RV practices ("verify integrity," "configure software securely," "respond to vulnerabilities") | SSDF v1.1 (2022) is process-only and does not pin a SLSA level, an attestation format, or a signing technology. An organization can claim full SSDF conformance with no SLSA provenance, no in-toto attestation, and no Sigstore signing in place. SSDF does not address AI-generated code provenance at all. |
+| SLSA v1.0 | Build L3 (hardened builder, isolated, signed provenance) | SLSA itself is the standard, not a gap — but the framework gap is that *no compliance regime mandates SLSA L3+ as a baseline*. SLSA is opt-in best practice; auditors do not require L3 evidence. The lag is in the regulatory layer, not in SLSA. |
+| CSAF 2.1 VEX | `vex` profile (`affected`, `not_affected`, `under_investigation`, `fixed` status with justification) | CSAF 2.0 VEX is published; CSAF 2.1 expands status vocabulary. No framework requires producers to publish VEX or consumers to consume it. Vulnerability scanners flood operators with non-applicable CVEs because the VEX-aware filtering layer is optional. |
+| CycloneDX 1.6 SBOM | `bom-1.6` schema with `cdx:ml`, `cdx:cryptography`, `cdx:vulnerability` extensions | CycloneDX 1.6 supports ML-BOM (model + dataset + hyperparameter inventory) and crypto-BOM. No framework requires ML-BOM or crypto-BOM specifically. EO 14028 and FDA premarket guidance require *an* SBOM, not a CycloneDX-1.6-with-ML-BOM SBOM. |
+| SPDX v3.0 SBOM | Core, Build, AI, Dataset profiles | SPDX 3.0 (2024) introduced the AI and Dataset profiles. Adoption is early; no compliance baseline requires the AI profile. The lag is between specification maturity and regulatory adoption. |
+| NIST 800-53 Rev 5 | SA-12 (Supply Chain Protection) | Process control: "develop a supply chain risk management plan." Does not require cryptographic provenance verification, SLSA level achievement, or VEX consumption. Auditors accept a written plan as SA-12 evidence. See `data/framework-control-gaps.json` `NIST-800-53-SA-12` entry for full gap text. |
+| NIST 800-161 | C-SCRM controls (broader and more specific than 800-53 SA-12) | Most concrete US guidance, addresses transitive risk and supplier criticality scoring. Still does not specify SLSA level, in-toto attestation, or Sigstore. AI artifact provenance is not addressed. |
+| ISO 27001:2022 | A.5.21 (Managing information security in the ICT supply chain), A.5.23 (Information security for use of cloud services) | A.5.21 is process-language. The Annex A control text does not require cryptographic provenance attestation. ISO 27002:2022 implementation guidance is high-level. |
+| EU Cyber Resilience Act (Regulation 2024/2847) | Technical documentation including software composition for products with digital elements | Adopted October 2024; phased application through December 2027. Requires SBOM for products with digital elements but allows producer-chosen format. Does not require SLSA, in-toto, or Sigstore signing. Implementing acts may tighten this through 2027. |
+| EU AI Act (Regulation 2024/1689) | Articles 10 (data governance), 13 (technical documentation), 15 (accuracy, robustness, cybersecurity) for high-risk AI systems | Requires training-data documentation and technical file for high-risk AI; does not specify ML-BOM format, model-weight signing, or training-data lineage attestation. The CycloneDX 1.6 ML-BOM and SPDX 3.0 AI profile are the implementation vehicles, but neither is mandated. |
+| UK NCSC Supply Chain Security | 12 principles for supply chain security guidance | Principles-based, jurisdictionally aligned with ISO 27001 A.5.21. No technical floor specified. NCSC has published guidance on SBOM but not made it mandatory. |
+| Australia ISM / Essential Eight | ISM controls under "Application Control" (E8 Maturity Level 3) and "Patch Applications" | E8 ML3 requires application control to allowlist executable content. Does not require cryptographic provenance or model-weight signing. AI artifact supply chain is not addressed in current ISM (Sep 2024 update). |
+| Australia IRAP | Aligned with ISM | Same gap; IRAP assessors evaluate against ISM, which is not yet sufficient for the AI artifact layer. |
+| PCI DSS 4.0 | 6.3.2 (inventory of bespoke and custom software), 12.8 / 12.9 (third-party service providers) | Inventory is required; cryptographic provenance verification is not. The MCP / AI-coding-assistant supply chain is in scope when a developer accesses a CDE codebase but is not specifically called out. |
+| HITRUST CSF v11.4 | 09.l (Outsourced Services / Service Delivery) | Healthcare-sector outsourced-service control aligned to ISO 27002 and NIST 800-53 supplier requirements. Same shape of gap as ISO A.5.21: process-language for supplier review, no cryptographic provenance verification, no SLSA / in-toto / Sigstore floor for MCP servers or AI coding assistants accessing PHI-bearing codebases. |
+| SWIFT CSCF v2026 | 1.1 (SWIFT Environment Protection) | Mandates segregation and protection of the SWIFT secure zone, including third-party connectors and middleware. Does not specify cryptographic provenance (SLSA / Sigstore / in-toto) for the software loaded into the secure zone — AI-codegen, MCP servers, and unsigned model weights inside a SWIFT user's adjacent dev environment fall outside the explicit CSCF control surface. |
+| US FedRAMP Rev 5 Moderate | SA-12 / SR family (Supply Chain Risk Management) baseline | Federal cloud authorization baseline inherits NIST 800-53 SA-12 and the SR controls. Same process-level gap — SBOM is increasingly expected (EO 14028 implementing guidance) but SLSA level, in-toto attestation, and Sigstore signing are not specified as mandatory evidence for ATO; AI artefact provenance is not addressed. |
+| US DoD CMMC 2.0 Level 2 | Practices aligned to NIST 800-171 r2 + r3 (Configuration Management, Risk Assessment, Supply Chain) | DoD contractor baseline for CUI. Inherits the NIST 800-171 / 800-53 supply-chain gap. Does not require SLSA L3+ provenance, in-toto attestation, or Sigstore signing for software used to develop, build, or process CUI; MCP servers and AI coding assistants accessing CUI codebases are not specifically controlled. |
+
+**Fundamental gap:** No current framework requires cryptographic provenance verification at load time as the supply-chain control. Every framework allows process-only or inventory-only evidence to satisfy supply-chain controls. Model weights as supply-chain artifacts have effectively zero compliance-framework coverage as of mid-2026; the technical standards (CycloneDX 1.6 ML-BOM, SPDX 3.0 AI profile, OpenSSF model-signing) exist and are usable, but they are not mandated anywhere.
+
+### Expanded jurisdictional coverage (per `data/global-frameworks.json`)
+
+Supply-chain integrity is a heavily cross-border domain — data-localization, third-party risk, and sovereign supplier-review regimes interact with SBOM and provenance practice in jurisdiction-specific ways:
+
+- **China (Cybersecurity Review Measures 2022 + Network Data Security Regulation):** CAC-led security review for procurement of network products and services by CII operators, with explicit supply-chain criteria for foreign-origin software, model weights, and cloud services. No SLSA-equivalent named, but the review covers "controllability of suppliers" — which makes opaque AI-codegen and unsigned model weights material findings.
+- **Vietnam (Cybersecurity Law + Decree 53/2022/ND-CP):** Data-localization obligations affect SBOM workflows materially — SBOMs that reference foreign-hosted package registries or model registries must be reconciled against the in-country storage requirement for "important data." Decree 53 is the operational hook.
+- **Israel (INCD Cyber Defense Methodology v2.0 + Defense Export Control Law):** INCD methodology has an explicit supply-chain section requiring inventory, criticality classification, and continuous supplier-risk reassessment — closer to NIST 800-161 than to ISO A.5.21. Defense-export rules add a layer for any organisation in the defence-industrial base.
+- **Switzerland (FADP + FINMA Circular 2018/3 Outsourcing):** FINMA outsourcing rules apply to ICT third-party arrangements with banking-grade rigour; FADP Art. 9 imposes processor obligations that are operationalised as supplier audits but do not pin SLSA, in-toto, or Sigstore.
+- **Hong Kong (HKMA SA-2 + PCPD Outsourcing Guidance):** HKMA SA-2 imposes operational-resilience expectations on outsourced ICT including supplier concentration risk; AI / MCP supplier classification under SA-2 is an open question.
+- **Taiwan (CSMA + FSC supply-chain controls):** CSMA Art. 14 requires CII operators to assess supply-chain risk; FSC sector-specific guidance for financial CIIs adds quarterly reporting on critical suppliers.
+- **Indonesia (UU PDP + ISO 27001 adoption):** UU PDP imposes processor due diligence; BSSN has issued non-binding SBOM guidance aligned with NTIA minimum-elements but not mandated.
+- **Japan (METI Software Tamper-Resistance Guidelines + FISC):** METI's revised guidelines reference SBOM as a recommended practice; FISC Security Guidelines impose supplier-risk requirements on financial-sector ICT.
+- **South Korea (KISA SECaaS evaluation + Cloud Security Assurance Program):** Cloud and supplier evaluation programs incorporate supply-chain integrity checks; the K-CSAP scheme is the operational baseline for public-sector procurement.
+- **Brazil (LGPD Art. 39 + ANPD processor guidance):** Processor due-diligence obligations apply to AI suppliers; no SBOM mandate.
+- **US sub-national — NYDFS 23 NYCRR 500.11 (Third-Party Service Provider Security Policy):** Most prescriptive US sub-national third-party requirement — written TPSP security policy, due diligence, periodic risk assessment, contractual requirements including encryption and notification. Class A companies face heightened expectations including independent audits. NYDFS 500.11 is the closest US sub-national analogue to NIS2 Art. 21(2)(d) and applies materially to MCP / AI-provider relationships used by covered entities.
+
+The catalog's expansion means a supply-chain assessment that names only NIST 800-218 SSDF, EU CRA, and ISO 27001 A.5.21 is incomplete for any covered entity operating in CN, VN, IL, CH, HK, TW, ID, KR, BR, or under NYDFS.
+
+---
+
+## TTP Mapping
+
+| ATLAS / ATT&CK ID | Technique | Supply-Chain Relevance | Gap |
+|---|---|---|---|
+| AML.T0010 | ML Supply Chain Compromise | Direct: malicious model, malicious MCP server, malicious ML library — the umbrella attack class for AI artifact compromise | ATLAS v5.1.0 classifies the attack; no framework mandates the cryptographic control that would detect it at load |
+| AML.T0018 | Backdoor ML Model | Specific: a model weight file with an embedded backdoor (trojaned weights, data poisoning persisted into weights, or executable payload in a code-executing serialization format) is loaded at inference | No framework requires model-weight signature verification; CWE-502 deserialization risk is not mapped to a compliance control |
+| T1195.001 | Supply Chain Compromise: Compromise Software Dependencies and Development Tools | The XZ Utils class, the typosquat class, the dependency-confusion class — directly addressable by SLSA L3 provenance + in-toto attestation chain | Standard SCA tooling detects known-vulnerable dependencies but does not detect novel compromise of an authentic-looking dependency. SLSA L3 + reproducible builds closes this; not required by any framework |
+| T1195.002 | Supply Chain Compromise: Compromise Software Supply Chain | Build pipeline compromise (CI runner, build-time toolchain, signing-key compromise). Defense: hardened builder per SLSA L3, key custody in HSM or cloud KMS, ephemeral CI tokens | NIST 800-218 PS practices are process-level. No framework prescribes hardened-builder requirements. |
+| T1554 | Compromise Host Software Binary | Modification of a binary in place — addressable by D3-EHB (hash-based allowlisting at runtime) plus Sigstore verification at deploy | Frameworks accept file-integrity monitoring as SI-7 evidence; D3-EHB-grade hash-allowlisting at execution is rare |
+
+Cross-walk to CWE (see `data/cwe-catalog.json`):
+
+| CWE | Why It Maps |
+|---|---|
+| CWE-1357 (Reliance on Insufficiently Trustworthy Component) | Continuous re-evaluation of supplier trust — the XZ class is exactly the CWE-1357 lag (maintainer-position compromise that procurement-time review does not catch) |
+| CWE-494 (Download of Code Without Integrity Check) | Direct map: download a package, model, or MCP server without verifying its signature against a pinned key — CVE-2026-30615 is reachable here |
+| CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) | Allowlist of approved publishers; private registry mirrors; runtime dependency-introduction review for AI tooling |
+| CWE-1395 (Dependency on Vulnerable Third-Party Component) | SBOM + VEX-aware vulnerability matching + reachability analysis. AI pipeline transitive dependencies are typically out of patch-SLA scope |
+| CWE-345 (Insufficient Verification of Data Authenticity) | Sigstore / cosign signature verification on all model and plugin loads; SLSA L3+ provenance attestation; transparency-log inclusion proof checked at install time |
+| CWE-502 (Deserialization of Untrusted Data) | Model weights in code-executing serialization formats — reject and migrate to safetensors |
+
+---
+
+## Exploit Availability Matrix
+
+Sourced from `data/cve-catalog.json`, `data/exploit-availability.json`, and public incident history as of 2026-05-11. Per AGENTS.md hard rule #1, every CVE reference includes CVSS, KEV status, PoC availability, AI-discovery flag, active-exploitation status, and patch availability. Technique-class rows (no single CVE) are scored as ongoing class risks per AGENTS.md hard rule #3 — RWEP is not assigned because the field is defined for individual CVEs in `data/cve-catalog.json`.
+
+| Incident / Class | CVSS | RWEP | PoC Public? | CISA KEV? | AI-Accelerated? | Patch / Mitigation | SLSA-Detectable? | SBOM-Detectable? | VEX-Helpful? |
+|---|---|---|---|---|---|---|---|---|---|
+| CVE-2026-30615 (Windsurf MCP zero-interaction RCE) | 9.8 | 35 (see `cve-catalog.json`) | Partial conceptual exploit | No (architectural class) | No direct AI weaponization recorded; the attack rides on AI agent tool-call autonomy | Vendor IDE update + manifest signing | Partially — SLSA L3 on the MCP server build would attest the binary, but client-side trust verification is the actual control | Partially — SBOM lists the MCP server package; VEX from the publisher would mark unpatched versions as `affected` | Yes — CSAF 2.0 VEX from the vendor classifies versions |
+| XZ Utils backdoor (CVE-2024-3094, historical reference 2024) | 10.0 | not in current `data/cve-catalog.json` — pre-scope incident | Yes — fully public post-disclosure | Yes (KEV at time of disclosure) | No — multi-year human social-engineering long game | Distro rollback to 5.4.x; key revocation in build pipelines | Yes — SLSA L3 with reproducible builds would have detected divergence between source and binary | Partially — SBOM lists `xz` but not the modified release tarball provenance | Yes — VEX statements published rapidly after disclosure |
+| Typosquat in `@modelcontextprotocol/*` namespace (AML.T0010 class, ongoing 2024-2026) | N/A (technique class) | N/A | Yes — multiple public incidents | No (technique class) | Yes — AI assistants accelerate convincing tool-description authoring | Mitigation only: pin versions, verify npm provenance attestation, enforce publisher allowlist | Yes — SLSA provenance from a known publisher fails for a typosquatted package | Yes — SBOM diff at install time flags new unrecognized package | Limited — VEX is about known vulns, not malicious-by-design packages |
+| Hugging Face poisoned model weights (AML.T0018, ongoing) | N/A (technique class) | N/A | Yes — public research demonstrations of RCE in model artifacts using code-executing serialization formats | No | Yes — adversarial weights via training-data poisoning is AI-accelerated | Reject code-executing serialization formats; require safetensors; verify Sigstore / OpenSSF model-signing signatures | Yes — SLSA-style attestation of model training run | Partial — ML-BOM (CycloneDX 1.6) inventories models; does not by itself attest integrity | Limited — VEX semantics map weakly to model integrity |
+| AI-coding-assistant generated code with no provenance markers (no CVE — class risk) | N/A | N/A | N/A — pervasive in 2024-2026 codebases | No | Yes — by definition | Mitigation: commit-message provenance markers, in-toto-style attestation that ties commit to model + prompt context | Partially — SLSA provenance can attest the human author of a commit; AI-co-author attribution is not standardized | No — SBOM does not currently inventory AI-generated code segments | Not applicable |
+| Build pipeline compromise (T1195.002, ongoing) | N/A (technique class) | N/A | Yes — multiple public incidents (SolarWinds 2020, CodeCov 2021) | No (technique class) | Yes — AI-assisted lateral movement in CI environments | SLSA L3 hardened builder; ephemeral runners; short-lived CI tokens; no production write from CI | Yes — that is precisely what SLSA L3 attests | Yes when SBOM is regenerated post-compromise and diffed | Yes — VEX from affected vendors |
+
+Reference RFC: RFC 8032 (Edwards-Curve Digital Signature Algorithm, Ed25519 / Ed448) is the asymmetric signature algorithm used by this project itself (`lib/sign.js`) and by Sigstore for keyless signing (Ed25519 is one of the supported algorithms in Sigstore Fulcio-issued certificates alongside ECDSA P-256). The signing-baseline reference is in `data/rfc-references.json` `RFC-8032`. PQC-readiness: see the `pqc-first` skill — SLSA does not yet require PQC signatures, but ML-DSA (FIPS 204) / SLH-DSA (FIPS 205) migration for signing keys is on the forward-watch list.
+
+---
+
+## Analysis Procedure
+
+The procedure threads three foundational principles. Each is non-negotiable; any supply-chain program missing one of them is structurally vulnerable.
+
+### Defense in depth
+
+Layered controls. One layer is fragile; the depth is what makes the program robust.
+
+- **Build-time signing.** Sigstore cosign keyless signing of every released artifact (container images, packages, model weights, MCP server binaries) against an OIDC-issued Fulcio certificate, with the signature recorded in the Rekor transparency log.
+- **In-toto attestation chain.** Every step in the build graph (checkout, build, test, package, sign, release) emits an in-toto attestation. The chain is verified end-to-end before publish.
+- **SBOM at build time AND deploy time.** CycloneDX 1.6 or SPDX 3.0 SBOM generated at build, regenerated at deploy, and diffed. Build-only SBOMs miss drift introduced by the deployment manifest.
+- **VEX statements at the consumer side.** CSAF 2.0 (or 2.1 when finalized) VEX consumption filters known-vulnerable-but-not-affected noise from operator triage.
+- **Runtime admission control.** Kyverno verify-images, Sigstore policy-controller, or equivalent enforces signature verification on every container or model load before execution. Default-deny on unsigned artifacts.
+- **Egress monitoring for runtime pulls.** Any pull from a registry at runtime is logged and matched against the build-time SBOM. Unexpected pulls (e.g., model fetches not in the manifest) alert.
+
+### Least privilege
+
+Scope every privilege as narrowly as the build action requires.
+
+- Build pipeline workers run with minimum scope: no production write paths, no long-lived cloud credentials, no shell on the build host.
+- CI tokens are short-lived (minutes, not days) and scoped to a single repository path. GitHub Actions OIDC + cloud-side IAM trust policies are the canonical pattern.
+- Model-loading services have read-only access to model registries. No write path from inference back to the registry.
+- AI coding assistants run in scoped sandboxes: no automatic merge to main, no automatic credential access, MCP servers running under D3-SCP seccomp profile and D3-EHB binary hash allowlist.
+- Signing keys live in HSMs or cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) — never on a developer workstation, never in CI environment variables.
+
+### Zero trust
+
+Every artifact is untrusted until provenance is verified.
+
+- Default-deny on unsigned artifacts at admission control.
+- Verify the **signature**, not just the presence of a signature file. A file ending in `.sig` next to the artifact is decoration, not evidence.
+- Verify the **identity** that signed (Sigstore Fulcio certificate subject), not just that the certificate is valid. A Fulcio certificate proves "some OIDC identity signed this" — only checking the subject proves "the expected identity signed this."
+- Verify the **build config**: that the artifact was produced from a hardened builder (SLSA L3 evidence in the in-toto attestation), not just that *some* builder signed it.
+- Verify the **transparency log inclusion proof** from Rekor; a signature not in Rekor was not subject to public scrutiny.
+
+### Step-by-step procedure
+
+1. **Inventory every build pipeline.** CI workflows (GitHub Actions, GitLab CI, Jenkins, Buildkite, CircleCI). Model-training pipelines (Vertex AI, SageMaker, KubeFlow, Ray clusters, local training runs). AI-codegen workflows (developer IDEs with Copilot / Cursor / Claude Code; agentic code-generation runners). For each pipeline, record: trigger, runner host class (managed vs. self-hosted), credentials granted, output artifacts.
+
+2. **Classify each pipeline against SLSA Build levels.**
+   - **L1:** Build is scripted; provenance documents the build process. Most pipelines achieve L1 trivially.
+   - **L2:** Provenance is generated by a hosted build service and signed. Tampering by the build service or its operators is still possible.
+   - **L3:** Build service runs in a hardened, isolated environment; provenance is unforgeable by the project's own tenants. Examples: GitHub Actions with reusable workflows + OIDC + Sigstore; SLSA-conformant GoReleaser; KubeFlow with attestation generators.
+   - Record SLSA achievement per pipeline. Any L1 pipeline producing production artifacts is a finding.
+
+3. **Generate SBOM per release.** CycloneDX 1.6 (preferred for ML-BOM and crypto-BOM extension support) or SPDX 3.0 (preferred for AI / Dataset profile use cases). Generated by build tooling (Syft, cdxgen, Trivy, GitHub dependency-graph SBOM export). SBOM must include direct and transitive dependencies; for AI pipelines must include model weights and training datasets.
+
+4. **Generate in-toto attestations for each build step.** Use `slsa-github-generator`, `in-toto-attestation` tooling, or the SLSA reference implementation. Sign each attestation with Sigstore cosign keyless. Publish attestations alongside artifacts in the registry (`cosign attach attestation` or OCI 1.1 referrers API).
+
+5. **Publish VEX statements per release.** CSAF 2.0 document with `vex` profile entries marking each known CVE in the SBOM as `affected`, `not_affected` (with justification), `under_investigation`, or `fixed`. Distribute via the CSAF Trusted Provider model (well-known URL on the producer domain).
+
+6. **Set up runtime admission verification.**
+   - Kubernetes: Sigstore policy-controller or Kyverno verify-images policy. Default-deny on unsigned images.
+   - Container hosts outside K8s: cosign verify in the pull pipeline; reject unsigned.
+   - Model serving: pre-load signature verification of model weights against pinned publisher identity (cosign or OpenSSF model-signing).
+   - Package installation: pinned package version + signature verification (npm provenance, PyPI Trusted Publishers + sigstore-python, Cargo crates.io with index integrity).
+
+7. **Monitor for drift.** Daily diff of in-production SBOM vs. last build-time SBOM. Alert on:
+   - Unexpected new dependencies (transitive drift).
+   - Unexpected model weight loads (file hash diverges from manifest).
+   - Unsigned artifact pulls (admission control bypassed by emergency-override).
+   - Maintainer-key changes for any direct dependency (CWE-1357 continuous re-evaluation).
+
+8. **AI-generated code provenance.** Implement at least one of:
+   - Commit message convention: prefix or trailer markers (`AI-Generated-By: copilot/...` or `Co-Authored-By: Claude <noreply@anthropic.com>`) parsed by CI.
+   - Repository-level attestation: in-toto-style record per merged PR linking commit SHA to AI model identifier to prompt context hash to human reviewer.
+   - Static-analysis-augmented review: AI-emitted-code detector (e.g., CodeBERT-class classifiers) flags un-attested AI code at PR time.
+
+9. **Model-weight integrity.** Reject code-executing serialization formats in production. Require safetensors or equivalent type-safe format. Require Sigstore signature verification against pinned publisher identity for every model load. Maintain an explicit allowlist of approved model publishers (org-internal MLOps registry, vetted Hugging Face orgs, vendor model registries).
+
+10. **Gap remediation roadmap.** For each pipeline below SLSA L3, document the specific delta (hosted builder? OIDC token issuance? isolated builder? attestation generator?), the cost to remediate, and the timeline. SBOM coverage, VEX publication, and admission control gaps each get their own roadmap line.
+
+---
+
+## Output Format
+
+```
+## Supply-Chain Integrity Assessment
+
+**Assessment Date:** YYYY-MM-DD
+**Scope:** [pipelines / repositories / model registries / runtime environments assessed]
+**Frameworks in scope:** [NIST 800-218 SSDF | NIST 800-161 | ISO 27001:2022 A.5.21 | EU CRA | EU AI Act | UK NCSC | AU ISM / IRAP | PCI 4.0]
+
+### Pipeline SLSA Scorecard
+| Pipeline | Type (CI / model-train / AI-codegen) | Runner | Current SLSA Level | Provenance Signed? | Attestation Chain? | Gap |
+
+### SBOM Coverage
+| Artifact Class | Format (CycloneDX 1.6 / SPDX 3.0) | Build-Time SBOM | Deploy-Time SBOM | ML-BOM Where Applicable | Drift Monitoring |
+
+### VEX Statement Coverage (Producers and Consumers)
+| Producer Status | Format (CSAF 2.0 / 2.1) | Distribution Channel | Last Statement Date |
+| Consumer Status | VEX-Aware Scanner? | False-Positive Reduction Measured? |
+
+### Sigstore / Signing Status
+| Artifact Class | Signing Tooling (cosign / OpenSSF model-signing) | Key Custody (KMS / HSM / Fulcio keyless) | Rekor Inclusion Verified? | Admission Control Enforcement |
+
+### AI-Generated Code Provenance Audit
+| Repository | AI Codegen Tool(s) in Use | Commit-Marker Convention? | PR-Level Attestation? | Detector in CI? | Estimated Untracked AI Code |
+
+### Model-Weight Integrity Audit
+| Model | Source (HF / vendor / internal) | Format (safetensors / code-executing / GGUF / ONNX) | Signed? Publisher Identity | Verification at Load | Allowlisted? |
+
+### CVE / Incident Exposure
+[CVE-2026-30615 status; ongoing class risks per Exploit Availability Matrix; any open VEX-`under_investigation` items]
+
+### Framework Gap Declaration
+[Per framework in scope: which control nominally applies, why current implementation does not close the supply-chain control gap, what real evidence would close it]
+
+### Gap Remediation Roadmap
+[Prioritized by RWEP for any CVE-driven gaps; otherwise prioritized by blast radius. Each item: specific delta, owner, target date, success criterion (e.g., "SLSA L3 attestation published on release pipeline X by YYYY-MM-DD, verified via cosign + Rekor inclusion proof").]
+```
+
+---
+
+## Compliance Theater Check
+
+Concrete tests that distinguish a paper-compliant supply-chain program from one that actually verifies provenance. Run all four. Any "we don't" answer is theater.
+
+1. **SLSA provenance evidence.** Ask: *"Show me the SLSA provenance attestation for your last production release. Paste the in-toto statement and the cosign / Rekor verification command output."* If the answer is "we don't generate SLSA provenance" or "we generate it but don't publish it," SSDF and SLSA conformance claims are paper. NIST 800-218 PS practices are not satisfied by intent.
+
+2. **Cosign verify on deploy.** Ask: *"For your last container image push, paste the `cosign verify --certificate-identity=<expected> --certificate-oidc-issuer=<expected>` command and its output. If you do not sign, explain how you verify integrity at deploy. If you sign but do not verify on deploy, explain what stops a tampered image from being pulled."* "We sign but we don't verify" is the most common theater pattern — the signature is decoration without admission-control enforcement.
+
+3. **Model-weight provenance.** Ask: *"For your last model weight load in production inference, what was the file's SHA-256, who is the signing publisher identity, who attested the training data lineage, and when was the signature verified against Rekor?"* If the answer is "we downloaded it from Hugging Face and pinned the URL," AI supply chain is unverified. Pinning a URL does not protect against publisher-key compromise or registry tampering.
+
+4. **AI-generated code provenance.** Ask: *"Pull the last 100 merged commits. How many include an AI-generation provenance marker (commit trailer, PR attestation, or detector annotation)? For the unattested commits, how do you exclude that AI-generated code was emitted with a training-data leak, an embedded credential, or a string-concat SQLi pattern from an injection-vulnerable prompt context?"* If the answer is "we don't track that," SBOM completeness claims are theater for the AI-codegen layer, and CWE-798 / CWE-89 regression risk is unmanaged.
+
+A genuinely conformant program answers all four with concrete artifacts: published provenance documents, deploy-time verification logs, Rekor inclusion proofs, and parseable AI-codegen attribution.
+
+---
+
+## Defensive Countermeasure Mapping
+
+D3FEND techniques referenced (see `data/d3fend-catalog.json`):
+
+- **D3-EAL (Executable Allowlisting)** — At runtime, restrict execution to a pre-approved set of executables. For supply-chain integrity, this is the runtime enforcement layer that closes the loop on build-time signing: even if a tampered binary reaches the host, D3-EAL blocks execution. In containerized / ephemeral environments the equivalent is signed-image admission control (Sigstore policy-controller, Kyverno verify-images).
+- **D3-EHB (Executable Hash-based Allowlist)** — Hash-pinned allowlist for binaries. Maps cleanly to MCP server binary hash pinning, model-weight SHA-256 verification at load time, and in-toto / SLSA Level 3 attestation enforcement. Note: D3-EHB requires runtime active rejection of unpinned binaries, not just SBOM presence — the lag against SA-12 is the active-rejection delta.
+
+Signing baseline reference: RFC 8032 (Ed25519 / Ed448) is the algorithm used by this project's `lib/sign.js` for skill-integrity signing, and is one of the Sigstore-supported algorithms for keyless signing certificates. The exceptd skill-signing implementation is a scoped living example of the broader pattern this skill defines:
+
+- Artifacts (skill.md files) are signed by an identified key (Ed25519 keypair, public key at `keys/public.pem`).
+- Signatures are verified before load (`lib/verify.js` runs as part of pre-ship and is invoked by the orchestrator).
+- Tampered artifacts are rejected (verification failure halts loading).
+- Signing key is operationally separated from the artifact registry (the private key lives at `.keys/private.pem`, gitignored, never in the repo).
+
+The same four invariants — signed by known identity, verified before load, tampered rejected, keys segregated — scale from a single-repo skill catalog to a full SLSA L3 release pipeline. The technology changes (Sigstore Fulcio keyless instead of a local Ed25519 keypair, Rekor instead of a local verify script, in-toto attestations instead of a single signature line); the principles do not.
+
+Forward-watch on PQC: the `pqc-first` skill tracks the migration from Ed25519 / ECDSA to ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signing. SLSA, Sigstore, and the major signing tools have not yet incorporated PQC signatures into their canonical workflows; this is a forward-watch item, not a current control gap.