SBOMs, Component Provenance, Vulnerability Governance, Repository Firewall Concepts, and Supply-Chain Risk: Configuration, Design Choices, and Tradeoffs

1. Start with the decision you need to defend

Architecture should begin with a decision, not a product logo. Examples: “May developers download this third-party component?”, “May this build enter release?”, “May this exact digest deploy to production?”, or “Which applications must be remediated after new intelligence appears?” Each decision has a different evidence context.

Nexus and Repository Firewall are strongest at controlled repository admission/consumption. Build scanners and application analysis have richer knowledge of which components are actually assembled into an application. Provenance verification belongs near build/release trust boundaries. A mature design connects these controls rather than forcing one control to answer every question.

2. Central repository governance versus build-time scanners

3. Allowlists and denylists are governance shortcuts, not complete risk models

An allowlist can be appropriate for highly constrained production environments where only reviewed component identities/digests may enter. Its operational cost grows quickly and can block updates if ownership is weak. A denylist is easier to start but reacts only to what has already been identified as disallowed. Policy engines combine multiple attributes and can express richer rules, but policy quality and exception process become critical.

Whatever the choice, anchor entries to the right identity. A package name without version/digest may be too broad; a digest-only rule may ignore package semantics and ecosystem metadata. Record why the rule exists and who owns it.

4. Immutable bytes versus mutable risk state

Keep the immutable and mutable records separate:

• Immutable build packet: artifact digest, source commit, build ID, SBOM for that build, provenance/attestation, signatures, publication timestamp.
• Mutable governance stream: vulnerability intelligence updates, exploitability context, policy version, waiver state, owner, remediation status, deployment disposition.

This separation lets you answer both “what did we know then?” and “what do we know now?” without rewriting historical evidence.

5. Internal provenance versus third-party packages

For internally built software, the organization can often control the builder, source repository, build definition, signing/attestation identity, and provenance retention. For third-party packages, you may receive only ecosystem coordinates, hashes, vendor signatures, published SBOMs, or external provenance of varying quality. Do not invent internal-grade provenance for external packages.

A common model is to attach the evidence you actually have to the exact digest, record evidence source/trust level, and apply different admission requirements for first-party and third-party content.

6. Quarantine versus deletion

Quarantine or “hold” preserves evidence while preventing normal consumption. Deletion removes content from a repository and can destroy rollback or forensic options if done carelessly. When a vulnerability is discovered, the first action is usually to identify affected artifacts/deployments and govern new consumption—not to delete production evidence reflexively.

7. SBOM/provenance evidence can itself be sensitive

SBOMs may reveal internal component names, versions, architecture, or dependency choices. Provenance may expose source URIs, builder identifiers, workflow names, or parameters. Treat evidence as governed data: classify it, redact secrets, control who can read it, and decide what customers or regulators receive. Do not put CI tokens, private keys, Authorization headers, or secret environment variables into attestations.

8. Evidence retention and rollback value

Retention should align artifact and evidence lifetimes. If you keep a release binary for two years but discard its SBOM/provenance after 30 days, future incident response loses context. Conversely, retaining every temporary development SBOM forever may be expensive and privacy-heavy. Define retention by artifact class and regulatory/forensic needs.

9. Worked scenario: choose controls for three paths

10. Decision table

11. Knowledge check

12. Summary and next step

The design pattern is layered: control shared dependency ingress, preserve immutable build evidence, re-evaluate mutable risk, and make exceptions auditable. Lesson 4 now breaks this design intentionally—stale intelligence, bypassed proxies, misunderstood signatures, unsafe deletion, and performance symptoms—to practice evidence-first diagnosis.

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.