SBOMs, Component Provenance, Vulnerability Governance, Repository Firewall Concepts, and Supply-Chain Risk: Concepts, Architecture, and Mental Model

1. The practical problem: “we have the artifact” is not enough

Chapter 22 added policy evaluation at the repository boundary. Chapter 23 asks a harder question: what evidence supports a decision about one artifact? A release can have a Maven coordinate, SHA-256 digest, source commit, build run ID, SBOM, provenance statement, package signature, vulnerability report, and repository policy result. Those values are related, but they are not interchangeable.

If an incident response runbook stores only the coordinate com.example:learner-widget:1.0.0, it may not prove which bytes were used. If it stores only the SHA-256, it still does not explain which source or builder produced those bytes. If it stores only an SBOM, it still does not establish who produced the application or whether the inventory is complete. Precision begins by naming the claim.

2. One artifact, many evidence layers

3. Mental model: evidence and enforcement surround repository storage

flowchart TD
  SRC[Source commit] --> BUILD[Build invocation]
  BUILD --> ART[Artifact bytes]
  BUILD --> PROV[Provenance attestation]
  BUILD --> SBOM[SBOM inventory]
  ART --> HASH[Digest / checksum]
  ART --> NX[Nexus hosted or proxy repository]
  NX --> DB[(Repository metadata DB)]
  NX --> BLOB[(Blob content)]
  SBOM --> IDENT[Component identities]
  IDENT --> VULN[Time-varying vulnerability intelligence]
  PROV --> GOV[Verification / policy]
  HASH --> GOV
  VULN --> GOV
  FW[Repository Firewall policy] --> GOV
  GOV --> DEC{{Allow / quarantine / hold / waive}}
  DEC --> CONSUME[Downstream consumption]

The database/blob pair is Nexus state. The SBOM, provenance, vulnerability feed, signature trust, and policy history may live in other systems. A production evidence packet links them by immutable identifiers—most importantly cryptographic digests—rather than pretending they are one database record.

4. Coordinate is not digest; digest is not provenance

Package managers commonly use coordinates such as group/name/version, npm scope/name/version, Python project/version, NuGet ID/version, or image tag. Coordinates are essential for discovery and dependency resolution, but a mutable repository or tag can map the same logical name to different bytes. A cryptographic digest fixes that ambiguity for a particular byte sequence.

That still leaves origin. A SHA-256 such as sha256:3f… tells you whether two copies match; it does not tell you who built them. Provenance ties an output subject—normally identified by digest—to builder and build-process information. SLSA’s current provenance model explicitly treats provenance as verifiable information about where, when, and how an artifact was produced.

5. SBOM: inventory, not a universal security certificate

A Software Bill of Materials is an inventory of software components and relationships. Current Sonatype documentation supports SBOM workflows in CycloneDX and SPDX; CycloneDX commonly identifies components with Package-URL (PURL), hashes, and coordinates. The important operational property is that an SBOM describes a particular application/build context.

Sonatype’s current best-practice guidance warns that vulnerability data inside an SBOM is point-in-time information. The dependencies can remain unchanged while new CVEs or exploitability information appears later. Therefore archive the SBOM as immutable evidence for the build, but re-evaluate the represented components against current intelligence.

6. Provenance and attestation: claims about production

Provenance is evidence about how the artifact was created. In the SLSA build model, the provenance identifies output artifacts by cryptographic digest and describes the builder/build process and relevant inputs. An attestation is a structured, potentially signed statement containing such claims. Verification asks whether the subject digest matches the artifact and whether the attestation satisfies an expected trust policy.

7. Checksum, signature, and TLS are three different controls

• Checksum/digest: detects byte mismatch relative to an expected value.
• Digital signature: binds data to a signing identity/key under a verifier’s trust model. Key compromise, revocation, identity policy, and timestamping still matter.
• TLS: protects/authenticates the network channel endpoint according to certificate trust while data is in transit. It does not turn downloaded bytes into a signed release artifact.

Disabling TLS verification because a client cannot connect destroys transport assurance. Ignoring a checksum mismatch destroys identity assurance. Accepting an untrusted signature because it is cryptographically valid ignores the trust-policy layer.

8. Repository Firewall belongs at admission/consumption, not inside the SBOM

Repository Firewall, taught in Chapter 22, can evaluate newly requested components against licensed policy and quarantine policy-violating content. That is a repository-boundary control. It does not replace build provenance or make an SBOM unnecessary, and a Firewall policy result can change independently of the artifact bytes.

Also remember the bypass problem: if CI or developer machines can silently switch to public upstreams when Nexus denies a component, the repository policy is not an authoritative control. Endpoint governance and network/client configuration are part of the security model.

9. Read-only inspection before mutation

Before adding evidence or changing policy, prove the current repository state:

1. Record Nexus version/edition/runtime and repository name/type/format.
2. Browse the component and identify every associated asset.
3. Capture the package coordinate/version and any repository-reported checksums available for the asset.
4. Use a fresh client or direct download to calculate SHA-256 independently.
5. Record whether the artifact came from hosted publication, proxy cache, or group routing.
6. Record the evidence system separately: SBOM file/version, provenance file, vulnerability snapshot timestamp, signature status, policy decision.

# Disposable downloaded file only
sha256sum learner-widget-1.0.0.jar

# PowerShell equivalent
Get-FileHash .\learner-widget-1.0.0.jar -Algorithm SHA256

A digest comparison is useful only when you state which expected digest you are comparing against and where that expectation came from.

10. State map: where evidence actually lives

11. Why this matters in DevOps

Reliable delivery needs a verifiable chain from source and build to repository and deployment. When a production incident occurs, the team should be able to answer: which exact bytes were deployed, which source/build produced them, which components were represented, what risk intelligence was known at the decision time, what policy allowed the release, and whether later intelligence changes require action. Nexus is one important custody/distribution boundary in that chain—not the entire chain.

12. Knowledge check

13. Summary and next step

You now have a layered evidence model: coordinate for logical identity, digest for byte identity, SBOM for inventory, provenance for build origin/process, signatures for authenticated claims, vulnerability intelligence for time-varying risk, and policy for governance. Lesson 2 turns that model into a disposable workflow and deliberately changes the intelligence while keeping the artifact bytes fixed.

Official references and version notes

• Sonatype: Software Bill of Materials (SBOM) — SBOM purpose, CycloneDX/SPDX support, analysis/export concepts, and point-in-time risk context.
• Sonatype: SBOM Best Practices — generate/store an SBOM for each application and do not use embedded vulnerability data as long-term risk state.
• Sonatype: CycloneDX Application Analysis — component identification by Package-URL, hashes, and coordinates plus dependency relationships.
• Sonatype: Repository Firewall — licensed repository-boundary policy enforcement and supported package ecosystems.
• Sonatype: Firewall Configuration for Nexus Repository — current repository-level enforcement model for recent Nexus versions.
• Sonatype: Nexus Repository Feature Matrix — Community/Pro entitlement boundaries; IQ/Firewall remain separate products/licensing.
• Sonatype: Nexus Repository System Requirements — current Java/database/runtime requirements.
• Sonatype nexus-public release 3.95.2-01 — dated Nexus baseline used by this chapter.
• CycloneDX: Specification Overview — current BOM object model, components, dependencies, hashes, and external references.
• CycloneDX 1.7 JSON Reference — current schema reference used to explain fields, not a claim that every Sonatype integration ingests every 1.7 feature.
• SLSA v1.2: Provenance — provenance as verifiable information describing where, when, and how software was produced.
• SLSA v1.2: Build Requirements — output identification by cryptographic digest and provenance-generation/integrity requirements.