Provenance and SBOM

From your hashes to everyone’s proofs

Lesson 5.1’s manifest asserts integrity to yourself. This lesson is the ecosystem-standard machinery that asserts it to everyone else — three artifacts, each answering a different question:

PROVENANCE   "who built this, from what, how?"  - a signed attestation
ATTESTATION    binding artifact -> source commit -> build system -> workflow
SBOM         "what's inside it?"                - the ingredient list
             (CycloneDX or SPDX - both now international standards)
SIGNATURE    "has it changed since signing?"    - and, keyless, "was the
             signer really that CI workflow?"

Provenance — the signed statement of who built this artifact, from which commit, on which build system — is cheap on the platforms that produce it natively, and one build-it-yourself step on the one that does not:

PLATFORM        NATIVE PROVENANCE?     WHAT YOU DO
GitHub          yes                    one action call attests workflow / commit / builder
GitLab          yes                    built-in attestation on the job
Azure DevOps    NO - and it is this   a cosign `attest` step signed with a Key Vault key
                training's reference
                platform
                                       (its KMS integration), placed in the 2.2 stage
                                       template so every pipeline inherits it

The framework language for “how trustworthy is this build?” is SLSA (Supply-chain Levels for Software Artifacts) — a 0-to-3 ladder for build integrity (the Build track); on GitHub the defaults land you at Build L2 and hardened reusable workflows at L3, while GitLab’s provenance is opt-in and Azure DevOps has none native (current version and pairings: the callout below). What matters more than producing provenance is checking it: a verify step in your own deploy gate refuses any artifact whose attestation does not match the expected repository and workflow — so an artifact built outside your pipeline, or from a repository or workflow you did not expect, is stopped before production (provenance proves where a build came from — review is a separate gate). That refusal is the control, and it costs one template step. Provenance nobody verifies is Lesson 3.4’s SARIF lesson again — emitted on the bet that a consumer arrives; here the consumer can be your own gate, today.

The signing-tool split, stated plainly for an Azure-leaning audience: cosign/Sigstore is the open-ecosystem volume leader (keyless signing bound to CI identity — the workload-identity idea from the other trainings, applied to artifacts); Notation is what the Azure container registry and AKS admission tooling natively expect for enterprise PKI signing. They coexist: cosign for OSS-facing and CI attestations, Notation where your ACR/AKS policy enforcement lives. Choosing is an ADR (3.5), not a religion.

One honest gap to name: none of this yet has a standard category for AI authorship — agent-authored commits carry the co-author trailers from Lesson 2.4, but no provenance spec attests “which agent, which model, which prompt.” The trailer convention is what exists; treat it as provenance’s TODO, not its answer.

The SBOM story: mandate died, practice didn’t

Teach this as the case study in why controls survive, because 2026 rewrote the compliance story mid-year: the US federal attestation-collection regime was rescinded — M-26-05 (January 2026) withdrew the M-22-18/M-23-16 memos requiring vendor attestation forms; agencies set their own risk-based requirements now, and contract- or agency-specific SBOM obligations can still apply, so read your own contracts before declaring anything gone. Naive prediction: SBOM practice collapses. What actually happened: generation kept growing — because the real drivers were never that one memo:

- EU Cyber Resilience Act: reporting obligations begin WEEKS after this
  training's review date, full application following next year (exact dates:
  the callout) - anyone selling into Europe keeps SBOMs (ENISA's SBOM
  Adoption State of Play 2026, n=334, June 2026: 78% had STARTED adopting,
  44 of those points still pilot or limited - and its sample was over 80%
  CRA-affected, so read it as a CRA cohort, not the market)
- DoD's fast-track authorization path went the OTHER way from the civilian
  rescission - SBOM/supply-chain artifacts are CENTRAL to it
- The worm-class attacks (3.3) made "what's inside, exactly?" an incident-
  response question you answer in minutes or in days
- CISA's 2025 refresh of the SBOM minimum elements (finalization status in the callout) means
  the bar for what a useful SBOM contains is better-defined than ever

The durable lesson beneath the churn: a control justified by one memo dies with the memo; a control justified by operations survives every administration. Generate the SBOM because you need the ingredient list on worm-day — the compliance uses then come free. (And the known industry gap is consumption: everyone generates, few actually read them into vulnerability workflows — being the shop whose SBOMs feed anything puts you ahead of most.)

The artifact - the integrity stage, added to the Module 2 templates:
1. SBOM generation at build (CycloneDX for the container + app), attached
   to the artifact alongside 5.1's manifest
2. provenance attestation via the platform's native machinery (GitHub) or
   the cosign-plus-Key-Vault step template (Azure DevOps), and the
   VERIFY step in the deploy template - deployment refuses artifacts whose
   attestation doesn't match expected repo/workflow
3. signing per the split: cosign attest in CI; Notation where registry/
   admission policy consumes it - the choice recorded as an ADR
4. the consumption starter: a nightly job diffing the SBOMs bound to every
   CURRENTLY DEPLOYED artifact digest (not just the latest build) against
   the vulnerability feed - filtered by suppliers' VEX statements (the
   emerging standard for machine-readable 'this CVE does not affect this
   product' notes - the answer to feed noise) - filing what remains into
   the 3.4 severity flow -
   the step that makes the ingredient list OPERATIONAL
5. the AI-authorship note in the ADR: trailers today, standard TBD -
   revisit on the freshness cadence

Practice status — among mature regulated delivery programs, commercial and federal

(a few rows carry a more specific status - principle, canon, suspended - where one of the five would mislead)

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

Provenance attests who-built-from-what (platform-native, verify-side wired into your own gates), SBOMs inventory what’s inside (generated because worm-day is operational, consumed so they’re not residue), signatures follow the cosign/Notation split by consumer — and the whole stack survived its mandate churn because it was never really about the mandate. AI authorship remains the standards gap; trailers hold the line. Next: pushing all of this evidence somewhere it counts.

LEADERSHIP DECISION   fund provenance + SBOM as standing pipeline steps
                      regardless of mandate status - the driver is incident
                      response time, not a memo
PRACTITIONER ACTION   attest in CI (native or cosign+Key Vault), verify in the
                      deploy gate, generate SBOMs per build and diff the
                      deployed ones nightly with VEX filtering
SUCCESS MEASURE       time to answer 'are we exposed to today's worm?'
                      measured in minutes of query, not days of inventory;
                      zero unverified artifacts reaching prod