SBOM and Build Provenance

This lesson does not configure a real CI/CD system, registry, or signing service. SEC015-LAB1 is fully local and synthetic, using only harmless JSON and text. The goal is to keep three questions separate: What artifact is being evaluated? What components are reported for it? How does provenance say that artifact was built, and by which builder?

The learner output is SBOM & Build Provenance Verification Record v1. It correlates artifact identity, SBOM observations, build provenance, local trust policy, negative evidence, and residual risk.

1. SBOM and build provenance are not the same evidence

An SBOM primarily describes component inventory and relationships. Build provenance describes build origin and process: build type, builder identity, inputs, and the output subject digest. Substituting one for the other leaves a gap.

An SBOM does not establish that a build was trusted. Provenance does not automatically establish complete dependency inventory. A bounded decision becomes stronger when both are correlated to the same artifact and evaluated under an explicit policy.

2. Establish the artifact before interpreting metadata

The baseline uses a synthetic artifact named acme-app-3.2.0 with a fixed fake SHA-256 value. The SBOM target and provenance subject must refer to that same identity and digest. A schema-valid SBOM for 3.1.0, or provenance whose subject digest points elsewhere, cannot support the local release decision.

3. What the SBOM contributes

The fixture records a primary component plus declared direct and transitive dependencies. Fields such as component name, version, purl, hash, and dependency relationship are observations. The lab uses them for inventory transparency, not as proof that software is vulnerability-free or benign.

A missing dependency can produce DENY_SBOM_COVERAGE under this fixture's declared expectations. That is a local policy result, not a universal rule for all SBOM consumers.

4. Use SPDX and CycloneDX within their claim boundary

SPDX and CycloneDX are established BOM standards, but this lesson does not rank one as universally superior. The lab uses a compact instructional representation while source notes anchor terminology and current versions to official specifications.

On the September 17, 2026 source recheck, SPDX lists 3.0 as the current stable document version. CycloneDX lists 1.7 as the current 1.x specification. Draft or release-candidate material is not promoted to stable authority in this lesson.

5. What build provenance adds

SLSA build provenance binds output artifacts through subject and describes build context through buildDefinition and runDetails. This lesson focuses on subject.digest, builder.id, and the source revision represented among resolved dependencies.

Those fields still do not make the final trust decision. The consumer needs an expectation for which builder and attestation identity are acceptable for this release.

6. Subject digest is the provenance-to-artifact join

If provenance refers to a different artifact digest, the rest of the metadata cannot repair that mismatch. The PROVENANCE_SUBJECT_MISMATCH probe changes only the subject digest and must stop the decision at that boundary.

This differs from an SBOM target mismatch: one breaks build-origin correlation; the other breaks composition correlation.

7. Keep builder and attestation identity explicit

In SLSA, builder identity identifies the build platform that executed the invocation. Attestation identity belongs to the trust context around the statement. The lab performs no real cryptographic signing; it uses opaque synthetic identifiers to model the decision boundary safely.

The baseline allows only https://builder.example/secure/v1 and attestor:test-build-A. Changing the builder to an unapproved identity yields DENY_UNAPPROVED_BUILDER even when the subject digest is correct.

8. What the positive case proves

In the baseline, the artifact digest matches both the SBOM target and provenance subject, required dependencies are present, builder and attestation identity are allowed, and the source revision matches policy. The result is ACCEPT_EVIDENCE_SET.

That means only that the synthetic evidence set satisfies the bounded local policy. It is not proof of malware absence, zero vulnerabilities, reproducibility, or production security.

9. Negative evidence: SBOM artifact mismatch

The first probe changes the SBOM target from acme-app-3.2.0 to acme-app-3.1.0 while the evaluated artifact stays unchanged. The SBOM may still be valid data, but correlation fails and the result is DENY_SBOM_ARTIFACT_MISMATCH.

10. Negative evidence: provenance subject mismatch

The second probe changes only subject.digest.sha256. Builder and source revision remain unchanged. The result must be DENY_PROVENANCE_SUBJECT_MISMATCH.

This demonstrates that trusted-builder evidence cannot substitute for artifact binding.

11. Negative evidence: unapproved builder

The third probe keeps the artifact and subject digest aligned but changes builder.id outside the local allowlist. The result is DENY_UNAPPROVED_BUILDER. This is a trust-policy failure, not a syntax or inventory failure.

12. Record coverage limits honestly

CISA's updated SBOM guidance emphasizes coverage and producing an associated SBOM as software builds/releases change. This lab checks coverage only against dependencies declared by its own synthetic policy. Real ecosystems may include dynamic, generated, remote, or otherwise difficult-to-enumerate dependencies.

residual_risk must preserve that limitation.

13. Evidence-record fields

Each case records artifact_id, artifact_digest, sbom_format, sbom_version, sbom_component_count, sbom_artifact_match, provenance_predicate_type, provenance_subject_digest, builder_id, source_revision, attestation_identity, observed_state, acceptance_decision, negative_evidence, and residual_risk.

Observed state stores fixture output. Acceptance decision is the local policy result. Residual risk prevents a bounded pass from becoming a universal security claim.

14. Changed-context transfer

The transfer case keeps the application name but changes artifact digest, dependency graph, and approved builder. The learner must rebuild artifact correlation, SBOM coverage, provenance subject, builder policy, and source revision rather than copying the baseline decision.

The template leaves final_decision blank to preserve human accountability.

15. Source freshness boundary

The September 17, 2026 recheck stays within the declared source plan: SPDX 3.0 as stable current, CycloneDX 1.7 as current 1.x, SLSA 1.2 as current, and CISA 2025 Minimum Elements for lifecycle/coverage framing. Material changes at review time require versioned requalification rather than silent mutation.

16. Query 1 completion

Macro-A requires one positive baseline, three negative classes, an evidence template, assessment surfaces, bilingual semantic parity, and a local executable lab. Query 1 does not Golden-freeze the lesson; it produces the Atomic Candidate for F2-L2 — INTERNAL_ADVERSARIAL_PANEL.