Executive Summary
Software is no longer something an enterprise only writes. It is something an enterprise receives — as container images, libraries, base layers, and agents delivered by third-party vendors whose source code we will never see. The central governance question is no longer "is our code secure?" but "can we trust what was handed to us, and can we prove it?"
This document presents a complete Third-Party Software Supply Chain Governance Framework for an environment built on Red Hat OpenShift, Sonatype Nexus Repository, Sonatype (Nexus) Repository Firewall, Prisma Cloud, Trivy, HashiCorp Vault, and Git-based CI/CD, where a material portion of running software arrives as third-party vendor container images pulled into private registries.
It is deliberately broader than SBOM generation. A Software Bill of Materials answers "what is inside?" — an essential question, but only one of seven the enterprise must answer. The framework treats the SBOM as a single evidence artifact within a larger trust system that also covers provenance, signing, vulnerability context (VEX), reachability, runtime exploitability, and continuous monitoring.
The Core Problem
When a scanner finds a critical CVE in a vendor image, the vendor often replies "false positive" or "not exploitable." Without source code, the enterprise cannot naively accept — or naively reject — that claim. It must verify it.
The Approach
Replace trust-by-assertion with trust-by-evidence: signed provenance, attestations, machine-readable VEX, reachability analysis, and runtime telemetry — each with documented limitations and a defined fallback.
The Outcome
A defensible, auditable decision for every third-party artifact: admit, admit-with-exception, or reject — governed by policy-as-code, recorded in immutable audit trails, and monitored continuously after deployment.
The Seven Business Questions This Framework Answers
| Business Question | How the Framework Answers It | Primary Section |
|---|---|---|
| How do we validate third-party software? | A multi-gate pipeline: identity & signature verification, provenance/attestation checks, SBOM ingestion, scanning (Trivy + Prisma Cloud), VEX reconciliation, and policy-as-code admission control before anything runs on OpenShift. | 05, 06, 07, 18 |
| How do we verify vendor responses? | Evidence hierarchy: vendor assertions are accepted only when backed by signed VEX, reachability analysis, provenance, and corroborating runtime telemetry — cross-checked against independent scanner output. | 11 |
| What evidence should be required? | A tiered evidence matrix tied to vendor criticality and data sensitivity, from signature + SBOM at the floor to signed SLSA provenance + VEX + reachability for business-critical workloads. | 04, 11, Appendix B |
| How is risk acceptance managed? | Formal exception workflow with risk scoring, compensating controls, time-boxed expiry, named accountable owner, and governance-board approval recorded in an audit trail. | 16 |
| When is an image rejected? | Deterministic rejection criteria: malware, invalid/absent signature, failed provenance, unresolved critical with no credible VEX, prohibited license, or expired exception. | 06, 16, Appendix A |
| When can an exception be approved? | When residual risk is understood, compensating controls exist, exposure is time-boxed, and an accountable owner accepts it at the right authority level. | 16 |
| How is software monitored after deployment? | Continuous re-scanning of registry contents, VEX/advisory feeds, runtime exploitability via eBPF, drift detection, and SBOM-driven impact analysis for newly disclosed CVEs. | 13, 17 |
A vendor's claim is a hypothesis, not a conclusion. "We don't use that package," "it's a false positive," and "the code isn't reachable" are testable statements. This framework defines exactly how to test each one with the evidence and tooling available to an organization that does not own the source.
What Decision-Makers Should Take Away
- Shift the burden of proof to the vendor. Make signed provenance, SBOM, and VEX contractual deliverables at onboarding, not after-the-fact requests during an incident.
- Never accept "false positive" verbally. Require it as a signed, machine-readable VEX statement with a justification the enterprise can independently corroborate.
- Verify, don't trust, at the registry boundary. The Repository Firewall and OpenShift admission control are the enforcement points where policy becomes reality.
- Treat runtime as the final arbiter. When static evidence is inconclusive, eBPF runtime telemetry shows whether vulnerable code actually loads and executes.
- Make every decision auditable. Regulators, including insurance supervisors, increasingly expect demonstrable third-party software due diligence, not just policy statements.
Document Contents
The framework is organized into six parts, moving from the nature of the problem through the trust model, vendor validation, governance operations, and a concrete reference architecture mapped to the customer's tooling.
Every technical claim, incident description, and standard referenced in this document is drawn from publicly available primary sources, which are cited in Section R: References. Where an implementation pattern is shown to illustrate how an enterprise might apply a control — rather than a publicly documented fact about a named company — it is explicitly labelled "Illustrative enterprise example." Named-company practices (Google, Microsoft, Red Hat, and others) are described only to the extent they are publicly documented.
01 · The Third-Party Software Threat Landscape
The last seven years turned software supply chain attacks from a theoretical concern into the dominant enterprise breach vector. The pattern is consistent: attackers no longer breach the target directly — they compromise something the target trusts and installs.
For an insurance enterprise consuming third-party container images, this matters because the attack does not arrive through the firewall. It arrives through the registry, signed and apparently legitimate, inside an image a vendor delivered and an engineer pulled. The defining incidents below are not anecdotes; each one maps directly to a control in this framework.
Anatomy of a Supply Chain Attack Surface
credentials"] A2["Source repo /
dependencies"] end subgraph BUILD["Build & CI/CD"] B1["Build system"] B2["CI secrets /
tokens"] B3["Build tooling"] end subgraph DIST["Distribution"] C1["Package registry"] C2["Update channel"] C3["Signing keys"] end subgraph CONSUME["Consumption"] D1["Private registry"] D2["Runtime /
OpenShift"] end A2 -->|"event-stream
XZ Utils"| B1 A1 -->|"CircleCI"| B2 B1 -->|"SolarWinds
3CX"| C2 B3 -->|"Codecov"| B2 C3 -->|"stolen cert"| C2 C2 --> D1 --> D2 classDef src fill:#15375f,stroke:#0b1f38,color:#fff; classDef bld fill:#2b577f,stroke:#0b1f38,color:#fff; classDef dist fill:#cc1f2d,stroke:#8e1420,color:#fff; classDef cons fill:#1f9d6b,stroke:#0b5a3c,color:#fff; class A1,A2 src; class B1,B2,B3 bld; class C1,C2,C3 dist; class D1,D2 cons;
Defining Incidents — and What Each One Teaches
The following incidents are documented from primary and authoritative public sources. The "control lesson" column is the bridge from history to the framework that follows.
| Incident | What Happened (publicly documented) | Control Lesson |
|---|---|---|
| SolarWinds / SUNBURST 2020 |
Attackers (attributed by FireEye to UNC2452) trojanized the SolarWinds Orion build process, inserting the SUNBURST backdoor into legitimately signed software updates distributed to roughly 18,000 customers. | A valid digital signature proves who shipped it, not that the build was clean. Build integrity and provenance (SLSA) are required, not just signing. |
| Log4Shell (CVE-2021-44228) CVSS 10.0 |
An unauthenticated RCE in Apache Log4j 2: a crafted string such as ${jndi:ldap://…} in a logged value caused the library to fetch and execute remote code. Buried as a transitive dependency in thousands of products. |
You cannot remediate what you cannot find. SBOMs + dependency inventory are prerequisites for answering "are we affected, and where?" |
| XZ Utils Backdoor (CVE-2024-3094) 2024 |
A multi-year social-engineering operation planted an obfuscated backdoor in the liblzma build of XZ Utils 5.6.0/5.6.1, enabling SSH auth bypass. Discovered by a Microsoft engineer investigating a ~500 ms SSH latency anomaly — not by a scanner. |
Malicious code can be invisible to signatures and SBOMs. Build reproducibility, behavioral/runtime monitoring, and dependency-maintainer trust matter. |
| 3CX (cascading) 2023 |
A double supply chain compromise: a 3CX employee installed a trojanized X_TRADER app; attackers (suspected DPRK-nexus) pivoted into 3CX's build environment and shipped a malicious, signed 3CX DesktopApp to customers. | Vendor trust is transitive. Your vendor's vendors are your risk. Vendor onboarding must assess the vendor's own supply chain hygiene. |
| Codecov Bash Uploader 2021 |
Attackers modified the Bash Uploader script (via credentials extracted from a Docker image) to exfiltrate CI environment variables — tokens, keys, credentials — undetected for roughly two months. Detected by a customer noticing a SHA-256 mismatch. | Integrity verification (checksums/signatures) of build tooling and secret hygiene in CI are essential. Trust the hash, not the URL. |
| CircleCI 2023 |
Malware on an engineer's laptop stole a post-2FA session cookie, letting attackers impersonate the user and exfiltrate customer secrets (including AWS keys and OAuth tokens). CircleCI told all customers to rotate every stored secret. | CI/CD platforms are high-value targets. Short-lived credentials, secret rotation, and Vault-backed dynamic secrets limit blast radius. |
| npm event-stream 2018 |
A new maintainer added a malicious dependency (flatmap-stream) to the popular event-stream package; the payload specifically targeted the Copay bitcoin wallet's build environment and was downloaded millions of times. |
Maintainer handoff is an attack vector. Repository Firewall policies on package age, provenance, and behavior catch what reputation alone misses. |
In SolarWinds, 3CX, and XZ Utils, the malicious artifact was correctly signed and passed conventional checks. Signature verification, SBOMs, and CVE scanning are necessary but not sufficient. A mature program assumes the artifact may be compromised even when the paperwork is perfect, and adds provenance, reproducibility, behavioral analysis, and runtime monitoring as independent lines of defense.
02 · The Vendor Claim Problem & The Trust Gap
The customer's most acute concern is not the initial scan finding — it is what happens next. A scanner flags a critical CVE in a vendor image, and the conversation that follows is where most enterprises lose control of their own risk posture.
The Conversation Every Enterprise Has Had
Why "Just Trust the Vendor" and "Just Reject Everything" Both Fail
Blind acceptance
- Transfers the vendor's risk appetite onto your balance sheet.
- Leaves no audit trail a regulator or insurer will accept.
- Was the exact failure mode in SolarWinds and 3CX — "it's signed, it's fine."
- Creates unmonitored, undocumented residual risk in production.
Blind rejection
- Most flagged CVEs genuinely are non-exploitable in context — rejecting everything is operationally impossible.
- Drives teams to disable scanning or route around governance ("shadow registries").
- Destroys the vendor relationship and delivery timelines without reducing real risk.
- Wastes scarce security capacity on noise instead of genuine exposure.
The goal is not to decide whether to believe the vendor. The goal is to convert each vendor claim into a verifiable evidence requirement. "It's a false positive" becomes "provide a signed VEX statement with a CSAF/OpenVEX justification we can corroborate." "The code isn't reachable" becomes "demonstrate it via reachability analysis, and we will confirm with runtime telemetry." This is the subject of Section 11.
The Five Claims, Mapped to Verifiable Evidence
| Vendor Claim | What It Really Asserts | Evidence That Verifies It |
|---|---|---|
| "We don't use that package" | The component is not present in the shipped artifact. | Vendor SBOM + independent SBOM regeneration (Trivy/Syft) from the image; binary composition analysis. |
| "It's a false positive" | The scanner mis-identified the component or version. | Component coordinates (PURL) + hash reconciliation; signed VEX with component_not_present or version evidence. |
| "The package exists but isn't executed" | Code is present but never loaded/invoked. | VEX vulnerable_code_not_in_execute_path + reachability analysis + eBPF runtime confirmation of loaded modules. |
| "The vulnerable code isn't reachable" | No call path reaches the vulnerable function. | Static reachability (call-graph) analysis; runtime function-level telemetry over a representative window. |
| "This CVE doesn't affect our implementation" | Configuration/usage neutralizes the flaw. | Signed VEX with inline_mitigations_already_exist + vendor security advisory + config attestation; validated by your own config inspection. |
Each row is a contract: the enterprise specifies the evidence it will accept, and the vendor's willingness (or refusal) to provide it becomes a risk signal in its own right.
Evidence Concepts Explained — A Plain-Language Guide
The "Evidence That Verifies It" column above uses precise technical terms. Because these concepts are the foundation of every verification decision, each one is unpacked below in plain language, with a concrete example and the specific tools that produce or check it. Read this section as a glossary for the table above.
Each concept follows the same shape: what it is (the definition), why it matters (what claim it lets you test), a worked example, and the tools that generate or validate it. The keywords in monospace (such as component_not_present) are standardized machine-readable values — they are not free text, and using the exact string is what makes them auditable.
1 · SBOM — Software Bill of Materials
What it is: A complete, machine-readable inventory of every component, library, and dependency inside a piece of software — the "ingredients label" for a container image or application. The two dominant formats are CycloneDX and SPDX.
Why it matters: It lets you test the claim "we don't use that package." If a vulnerable library is not in the SBOM — and you can independently confirm that — the claim holds.
Example: A vendor says their image does not ship log4j. You open their SBOM and search for it. But you don't stop there — you regenerate your own SBOM from the actual image (see below) and compare. If both agree log4j is absent, the claim is verified by evidence, not by trust.
Tools: Syft and Trivy (generate SBOMs), CycloneDX / SPDX (the formats), Sonatype Nexus (stores and manages them).
What the file looks like — CycloneDX (JSON): each dependency is one component entry, precisely identified by its purl.
// sbom.cdx.json — CycloneDX 1.5 { "bomFormat": "CycloneDX", "specVersion": "1.5", "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79", "components": [ { "type": "library", "name": "log4j-core", "version": "2.17.1", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1", "hashes": [ { "alg": "SHA-256", "content": "4f3c...e19a" } ] } ] }
The same component in SPDX (tag-value): a different format, identical intent.
# sbom.spdx — SPDX 2.3 PackageName: log4j-core SPDXID: SPDXRef-Package-log4j-core PackageVersion: 2.17.1 PackageLicenseConcluded: Apache-2.0 ExternalRef: PACKAGE-MANAGER purl pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1 PackageChecksum: SHA256: 4f3c...e19a
The same component as YAML (SPDX): identical data, often easier to read. SPDX officially defines a YAML serialization alongside JSON, tag-value, and RDF.
# sbom.spdx.yaml — SPDX, YAML serialization spdxVersion: SPDX-2.3 packages: - name: log4j-core SPDXID: SPDXRef-Package-log4j-core versionInfo: "2.17.1" licenseConcluded: Apache-2.0 checksums: - algorithm: SHA256 checksumValue: 4f3c...e19a externalRefs: - referenceCategory: PACKAGE-MANAGER referenceType: purl referenceLocator: pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1
YAML is fully machine-readable and interchangeable with JSON: any JSON document is also valid YAML, and both parse to the same data. YAML is often preferred for human editing and is standard across the Kubernetes/OpenShift ecosystem, while JSON is the more universal default emitted by most tools.
Format support differs per standard. SPDX officially supports YAML (as above), JSON, tag-value, and RDF. CycloneDX's official serializations are JSON, XML, and Protobuf — not YAML — so for CycloneDX use JSON. Always confirm which serializations a given tool accepts.
The signing caveat. For cryptographically signed evidence — signed VEX and in-toto/SLSA attestations — the signature is computed over exact bytes, so the signed-and-stored form is canonical JSON (typically wrapped in a DSSE envelope). You can author or view it as YAML, but verification runs against the canonical JSON so the hash stays stable. For unsigned inventory files like SBOMs, storing and consuming YAML directly is perfectly fine.
2 · Independent SBOM Regeneration
What it is: Instead of trusting the SBOM the vendor hands you, you generate a fresh SBOM yourself directly from the delivered artifact (the container image or binary), then compare the two.
Why it matters: A vendor-supplied SBOM can be outdated, incomplete, or — in the worst case — deliberately trimmed. Regenerating it independently closes that gap. Discrepancies between the vendor SBOM and your regenerated one are themselves a risk signal.
Example: The vendor SBOM lists 140 components. You run trivy image --format cyclonedx against their image and get 148. The eight extra components — and any vulnerabilities they carry — are exactly what you need to ask about.
Tools: Trivy, Syft (regenerate from the image), then a diff of the two component lists.
What it looks like in practice — regenerate, then diff:
# 1. Generate your own SBOM straight from the vendor image $ syft vendor-registry.io/app:2.4.0 -o cyclonedx-json > mine.cdx.json # 2. Diff the vendor's component list against yours $ diff <(jq -r '.components[].purl' vendor.cdx.json | sort) \ <(jq -r '.components[].purl' mine.cdx.json | sort) # 3. Output: 8 components present in the image but NOT in the vendor SBOM > pkg:golang/github.com/klauspost/compress@1.15.9 > pkg:npm/minimist@1.2.5 ... (6 more) — each one now needs a vendor answer
3 · Binary Composition Analysis
What it is: Inspecting the compiled binary itself — not the manifest or package list — to identify what code is actually baked in. This catches statically linked or vendored code that never appears in a package manifest.
Why it matters: A component can be present in the binary even when it is missing from the dependency list. Composition analysis sees what the manifest cannot.
Example: A Go binary statically links a vulnerable compression library. Nothing in a go.mod file flags it after compilation, but binary analysis fingerprints the embedded library and surfaces it.
Tools: Prisma Cloud software composition analysis (SCA) and Trivy (both fingerprint embedded/statically-linked code), with Syft binary matchers for SBOM-level detail.
4 · Component Coordinates (PURL) & Hash Reconciliation
What it is: A PURL (Package URL) is a standardized identifier that names a component exactly — its ecosystem, name, and version — e.g. pkg:npm/lodash@4.17.21. Hash reconciliation means comparing the cryptographic hash (checksum) of the file you received against the known-good hash of the real component.
Why it matters: Together they test "it's a false positive." Scanners sometimes flag the wrong version. A precise PURL plus a matching hash either confirms or disproves that the flagged component is truly present.
Example: A scanner reports openssl 1.1.1 (vulnerable). The vendor says it is actually 3.0.12 (patched). You compare the PURL and the file hash of the shipped library against the official 3.0.12 release hash. If they match, the scanner was wrong — a genuine false positive.
Tools: PURL spec, Trivy and Prisma Cloud (report component PURLs), cosign / sha256sum (hash verification), with Sonatype Nexus holding the known-good component coordinates.
5 · Signed VEX & Its Justification Keywords
What it is: VEX (Vulnerability Exploitability eXchange) is a machine-readable statement from the vendor saying whether a specific CVE actually affects their product, and why. "Signed" means it is cryptographically signed, so you can prove who issued it and that it was not altered. The justification is a fixed, standardized keyword explaining the "why."
Why it matters: It replaces a verbal "trust us, it's fine" with a signed, auditable, standardized artifact. The justification keyword is not free text — it must be one of the defined values below, which is what lets a policy engine act on it automatically.
| Justification Keyword | Plain Meaning | Example |
|---|---|---|
component_not_present | The flagged component isn't actually in the product. | The CVE is in a module the vendor stripped out of their build. |
vulnerable_code_not_in_execute_path | The code ships but is never loaded or run. | A vulnerable function lives in an unused sub-module that is never imported at runtime. |
inline_mitigations_already_exist | Configuration or code already neutralizes the flaw. | The vulnerable feature is disabled by default and the vendor enforces that setting. |
Tools & formats: OpenVEX and CSAF VEX (the standards), cosign (signs and attaches VEX to the image as an attestation), Trivy (consumes VEX to suppress verified false positives during scans).
What the file looks like — OpenVEX (JSON): a vendor statement that CVE-2021-44228 does not affect their product, with a standardized justification. This is the machine-readable replacement for a verbal "it's a false positive."
// log4shell.openvex.json — required fields: @context, @id, author, timestamp, version, statements { "@context": "https://openvex.dev/ns/v0.2.0", "@id": "https://openvex.dev/docs/public/vex-log4shell-app-2-4-0", "author": "Acme Vendor Security <psirt@acme.example>", "timestamp": "2026-02-11T09:00:00Z", "version": 1, "statements": [ { "vulnerability": { "name": "CVE-2021-44228" }, "products": [ { "@id": "pkg:oci/app@sha256:9b2c...d41f" } ], "status": "not_affected", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "The JndiLookup class is removed from the shipped build; the code path is never loaded." } ] }
How you consume it in a scan: point Trivy at the VEX file with the --vex flag. Trivy filters out the vulnerability and logs the status and justification it applied.
# Apply a local VEX file when scanning the image (Trivy --vex flag) $ trivy image vendor-registry.io/app:2.4.0 --vex log4shell.openvex.json # INFO Filtered out the detected vulnerability # {"VEX format": "OpenVEX", "vulnerability-id": "CVE-2021-44228", # "status": "not_affected", "justification": "vulnerable_code_not_in_execute_path"} # Alternatively, discover a VEX attestation attached to the image in the registry $ trivy image vendor-registry.io/app:2.4.0 --vex oci
Command output above is adapted from the Trivy VEX documentation. Signature verification of an attached attestation is handled by cosign verify-attestation against the vendor's identity/key before the VEX is trusted.
6 · Reachability Analysis (Static Call-Graph)
What it is: Static analysis that maps the program's call graph — every path of function calls — to determine whether execution can ever actually reach the vulnerable function. Done without running the code.
Why it matters: It tests "the vulnerable code isn't reachable." A library can contain a flaw, but if no call path in the application ever invokes the flawed function, the practical risk is far lower.
Example: An image includes a library with a vulnerability in its XML parser, but the application only ever calls the library's JSON functions. Call-graph analysis shows no path leads to the XML parser, supporting the vendor's claim.
Tools: Prisma Cloud (reachability / code-path analysis) is the primary tool in this stack, complemented by language-specific call-graph analyzers where deeper inspection is needed.
7 · eBPF Runtime Confirmation & Function-Level Telemetry
What it is: eBPF is a Linux kernel technology that safely observes what a running program actually does — which modules it loads and which functions it executes — without modifying the application. "Function-level telemetry" is the record of that activity over a representative period.
Why it matters: Static analysis predicts behavior; runtime evidence proves it. eBPF is the final arbiter: if the vulnerable module never loads in production over a representative window, the claim that it "isn't executed" is confirmed by observation.
Example: A vendor claims a vulnerable module is never loaded. You monitor the workload with eBPF for a week under normal traffic and confirm the module is never mapped into memory — corroborating the static reachability finding with live evidence.
Tools: Prisma Cloud runtime defense (eBPF-based) is the primary source of this telemetry in the stack, running as an OpenShift DaemonSet; the underlying eBPF technology (also exposed by Falco/Tetragon) is what makes the observation possible.
What the evidence looks like — an illustrative runtime observation (JSON): a simplified, representative record of loaded/executed modules for the workload over the monitored window. The absence of the vulnerable module is the evidence that corroborates the vendor's claim. This is a conceptual shape, not a verbatim Prisma Cloud export — consult the product documentation for the exact schema.
// runtime-observation.json — illustrative shape (not a verbatim vendor export) { "image": "vendor-registry.io/app@sha256:9b2c...d41f", "namespace": "payments-prod", "observationWindow": "2026-02-04T00:00Z/2026-02-11T00:00Z", "cve": "CVE-2021-44228", "vulnerableModule": "log4j-core/JndiLookup", "loaded": false, "executed": false, "verdict": "not_in_execute_path_confirmed_at_runtime" }
8 · Vendor Security Advisory & Config Attestation
What it is: A security advisory is the vendor's published analysis of a CVE against their product. A config attestation is a signed statement about how the software is configured — proving, for example, that a risky feature is turned off by default.
Why it matters: Together they test "this CVE doesn't affect our implementation." The advisory explains the reasoning; the signed config attestation is the tamper-evident proof — which you then confirm by inspecting the configuration yourself.
Example: A CVE only triggers when a debug endpoint is enabled. The vendor's advisory states the endpoint is disabled in production builds, and a signed config attestation proves it. You independently inspect the shipped config to confirm the endpoint is absent.
Tools: Vendor advisories in CSAF format, in-toto / cosign attestations, and your own config inspection against a hardening baseline.
What the file looks like — in-toto config attestation (JSON): a signed statement binding a configuration claim to the exact image it describes.
// config.attestation.json — in-toto Statement { "_type": "https://in-toto.io/Statement/v1", "subject": [ { "name": "vendor-registry.io/app", "digest": { "sha256": "9b2c...d41f" } } ], "predicateType": "https://acme.example/attestations/config/v1", "predicate": { "debugEndpointEnabled": false, "tlsMinVersion": "1.2", "appliesToCVE": "CVE-2025-1234", "note": "Vulnerable debug endpoint is disabled by default and enforced at startup." } }
Then confirm it yourself — don't just read the attestation:
# Verify the vendor's signature on the config attestation $ cosign verify-attestation --type https://acme.example/attestations/config/v1 \ vendor-registry.io/app@sha256:9b2c...d41f # Independently inspect the shipped config to confirm the claim is true $ grep -i "debug" /etc/app/config.yaml > debug.endpoint.enabled: false # matches the attestation
Every term in the evidence column maps to a real artifact a vendor can produce and you can independently check. You are never asked to simply believe a claim — you ask for the SBOM, the signed VEX, the reachability report, or the runtime telemetry, and you verify it with your own tooling (Trivy, Syft, cosign, Prisma Cloud, and eBPF sensors). That is the difference between trust-by-assertion and trust-by-evidence.
03 · The Governance Framework Overview
The framework is a layered trust model. Each layer answers a distinct question, and an artifact must clear every applicable layer before it is permitted to run. No single layer — not even the SBOM — is treated as sufficient on its own.
The Seven Layers of Supply Chain Assurance
Who produced this? — Cosign / Sigstore / Notary v2 signatures"] L2["2 · Provenance & Integrity
How was it built? — SLSA, in-toto attestations"] L3["3 · Composition
What is inside? — SBOM: CycloneDX / SPDX"] L4["4 · Vulnerability Context
What is exploitable? — Trivy + Prisma Cloud + VEX"] L5["5 · Reachability & Exploitability
Can it actually be triggered? — call-graph + runtime"] L6["6 · Policy & Admission
Are we allowed to run it? — Policy-as-Code, OpenShift gates"] L7["7 · Continuous Assurance
Is it still safe? — re-scan, drift, eBPF, audit"] L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7 L7 -.->|"new CVE / advisory
feedback loop"| L4 classDef a fill:#15375f,stroke:#0b1f38,color:#fff; classDef b fill:#1f8fb3,stroke:#0b1f38,color:#fff; classDef c fill:#1f9d6b,stroke:#0b5a3c,color:#fff; class L1,L2 a; class L3,L4,L5 b; class L6,L7 c;
Mapping Layers to the Customer's Toolchain
| Layer | Question Answered | Primary Tooling (customer stack) | Enforcement Point |
|---|---|---|---|
| 1. Identity | Did a trusted party produce this exact artifact? | Cosign / Sigstore; Notary v2 (notation); keys in HashiCorp Vault | Registry & OpenShift admission |
| 2. Provenance | Was it built by a trusted, tamper-resistant process? | SLSA provenance, in-toto attestations (verified with Cosign) | CI/CD & admission |
| 3. Composition | What components and licenses are inside? | Trivy / Syft (SBOM gen), CycloneDX & SPDX, Nexus | Build & registry |
| 4. Vuln Context | Which known vulnerabilities apply? | Trivy, Prisma Cloud, Nexus (Repository) Firewall, VEX | Registry Firewall |
| 5. Reachability | Is the vulnerable code actually exploitable here? | Reachability analysis tooling; Prisma Cloud runtime; eBPF (Falco/Tetragon) | Pre-prod & runtime |
| 6. Policy | Does this satisfy enterprise policy? | Policy-as-Code (OPA/Gatekeeper, Kyverno), Prisma Cloud policies | OpenShift admission webhook |
| 7. Continuous | Is it still trustworthy in production? | Prisma Cloud runtime defense, eBPF, Nexus re-evaluation, SIEM | Runtime & audit |
Adopt the layers incrementally but in order of leverage. Most organizations already have Layers 3–4 (SBOM + scanning). The highest marginal risk reduction for a vendor-image-heavy estate comes from adding Layer 1 (mandatory signature verification at admission) and Layer 2 (provenance) — precisely the layers that would have changed the outcome in SolarWinds and 3CX. Treat Layer 5 (reachability/runtime) as the tie-breaker for disputed vendor claims rather than a universal gate.
04 · Vendor Onboarding & Tiering
Governance fails when evidence is requested reactively, mid-incident. The single highest-leverage intervention is to make supply chain evidence a contractual onboarding deliverable, scaled to how much trust the vendor's software will be granted.
Risk-Based Vendor Tiering
Not every vendor warrants the same scrutiny. Tier the vendor by the blast radius of its software, then attach evidence requirements to the tier. This keeps governance proportional and defensible.
Tier 1 — Critical
Handles PII/PHI/policyholder or claims data, runs with elevated privilege, or is internet-facing.
- Signed images (mandatory)
- SLSA provenance (Build L3 target)
- SBOM (CycloneDX or SPDX) per release
- VEX for all critical/high findings
- Security advisory feed / PSIRT contact
- Right-to-audit clause
Tier 2 — Important
Internal business systems, limited data scope, no direct internet exposure.
- Signed images (mandatory)
- SBOM per release
- VEX for critical findings
- Provenance (Build L2 target)
- Defined remediation SLAs
Tier 3 — Standard
Non-sensitive, sandboxed, or developer-tooling images with minimal reach.
- Signed images (preferred)
- SBOM on request
- Standard scanning gates
- Best-effort remediation
The 3CX compromise originated in another vendor's trojanized software. Tier 1 onboarding should therefore assess the vendor's own supply chain controls — do they sign, generate SBOMs, and verify their upstreams? Map this to a recognized baseline such as the NIST Secure Software Development Framework (SP 800-218) and request the vendor's CISA Secure Software Development attestation where applicable.
Onboarding Workflow
Business sponsorship & classification
The requesting business unit declares the data sensitivity and exposure of the intended workload. This sets the vendor tier.
Security due-diligence questionnaire
Vendor completes an SSDF-aligned assessment: build security, signing, SBOM capability, vulnerability disclosure (PSIRT), and their own third-party governance.
Evidence capability validation
Confirm the vendor can actually deliver the tier's required artifacts (signature, provenance, SBOM, VEX) — ideally by validating a sample image before contract signature.
Contractual codification
Evidence deliverables, remediation SLAs, right-to-audit, and breach-notification timelines are written into the master agreement — not left to goodwill.
Trust anchor establishment
The vendor's signing identity (Cosign key / Fulcio OIDC identity / Notary v2 cert) is registered in the enterprise trust policy stored in Vault and referenced by admission control.
Registry namespace provisioning
A dedicated Nexus proxy/hosted repository and OpenShift namespace are created with policies bound to the vendor's tier.
05 · Software Approval Workflow
Once a vendor is onboarded, every individual image release runs through a deterministic approval pipeline. The outcome of that pipeline is always one of three states — Admit, Admit with Exception, or Reject — and every outcome is recorded.
identity valid?"} SIG -->|No| REJ["REJECT
quarantine + notify vendor"] SIG -->|Yes| PROV{"Provenance /
attestation valid?"} PROV -->|No| REVW1["Hold for review"] PROV -->|Yes| SBOMC{"SBOM present
& consistent?"} REVW1 --> SBOMC SBOMC -->|No| GEN["Generate SBOM
independently (Trivy/Syft)"] GEN --> SCAN SBOMC -->|Yes| SCAN["Scan: Trivy +
Prisma Cloud"] SCAN --> FIND{"Critical / High
findings?"} FIND -->|None| ADMIT(["ADMIT
sign + promote"]) FIND -->|Yes| VEXQ{"Credible VEX
or fix available?"} VEXQ -->|Fix available| PATCH["Require fixed version"] VEXQ -->|Valid VEX,
verified| REACH{"Reachability /
runtime confirms
not exploitable?"} VEXQ -->|No evidence| EXC{"Exception
justified?"} REACH -->|Confirmed| ADMIT REACH -->|Inconclusive| EXC EXC -->|Approved by board| ADMITX(["ADMIT W/ EXCEPTION
time-boxed + controls"]) EXC -->|Denied| REJ classDef rej fill:#cc1f2d,stroke:#8e1420,color:#fff; classDef adm fill:#1f9d6b,stroke:#0b5a3c,color:#fff; classDef dec fill:#fff,stroke:#2b577f,color:#0b1f38; class REJ rej; class ADMIT,ADMITX adm;
Approval Gates & Their Owners (RACI)
| Gate | Decision | Accountable | Tooling |
|---|---|---|---|
| G1 — Authenticity | Is the signature trusted? | Platform Engineering | Cosign verify, admission webhook |
| G2 — Provenance | Is the build trustworthy? | DevSecOps | SLSA verifier, in-toto |
| G3 — Composition | Is the SBOM complete & consistent? | DevSecOps | Trivy, Syft, Nexus |
| G4 — Vulnerability | Are findings within policy? | Security Operations | Trivy, Prisma Cloud, Nexus Firewall |
| G5 — Exploitability | Is a flagged risk real in context? | Security Architecture | VEX, reachability, eBPF runtime |
| G6 — Risk acceptance | Approve exception? | Supply Chain Governance Board | Exception register, audit trail |
06 · Repository & Repository-Firewall Governance
The private registry is the chokepoint where governance becomes enforceable. Everything an enterprise runs should be able to trace back to an artifact that passed through a governed Nexus repository — and nothing should reach a build or a cluster from an ungoverned public source.
The Registry as a Trust Boundary
Sonatype Nexus Repository acts as the system of record for binaries, container images, and packages. Sonatype Repository Firewall (formerly Nexus Firewall) sits in front of proxy repositories and evaluates every inbound component against policy before it is allowed into the local environment. When a requested component violates policy, the Firewall can place it into quarantine: it is not served to the requester while quarantined, and the requester receives an explanatory error linking to the component details.
The Repository Firewall's Audit and Quarantine capability uses IQ Server policy to identify and, when configured, prevent a proxy repository from serving unwanted components. Quarantine must be enabled to block critical threats; by default, malicious components are quarantined and "should never be allowed in your repository." Disabling quarantine releases previously quarantined components, so enablement is a deliberate governance decision, not a default to assume.
Recommended Repository Topology
Docker Hub, npm,
Maven Central")] subgraph NEXUS["Sonatype Nexus + Repository Firewall"] FW{{"Repository Firewall
policy evaluation"}} QUAR["Quarantine
(blocked)"] PROXY["Proxy repos
(governed cache)"] HOSTED["Hosted repos
vendor images,
internal builds"] STAGE["Staging /
release repos"] end DEV["Developers /
CI pipelines"] OCP["OpenShift
clusters"] PUB --> FW FW -->|"policy fail"| QUAR FW -->|"policy pass"| PROXY VENDOR["Third-party
vendor images"] --> HOSTED PROXY --> STAGE HOSTED --> STAGE STAGE --> DEV STAGE --> OCP classDef bad fill:#cc1f2d,stroke:#8e1420,color:#fff; classDef good fill:#1f9d6b,stroke:#0b5a3c,color:#fff; class QUAR bad; class STAGE good;
Recommended Repository Firewall Policy Set
| Policy | Condition | Action | Rationale / Incident link |
|---|---|---|---|
| Malicious component | Component matches known-malware intelligence | Quarantine | Non-negotiable. Directly addresses npm-style malicious-package attacks. |
| Critical CVE, no fix | Critical vuln with no remediated version | Quarantine + review | Forces the VEX/reachability conversation before entry. |
| Suspicious newness | Package version published < N days ago | Warn / hold | Mitigates fast-moving malicious releases (event-stream pattern). |
| Namespace / typosquat | Name resembles a known popular package | Quarantine | Defends against dependency-confusion & typosquatting. |
| Integrity mismatch | Hash differs from expected/declared | Quarantine | Codecov lesson — trust the hash, not the source URL. |
| Prohibited license | License on enterprise deny-list | Block / warn | License governance (14). |
| Missing signature | Tier 1/2 image lacks valid signature | Hold | Enforces Layer 1 authenticity for sensitive workloads. |
Deterministic Rejection Criteria
To remove ambiguity (and protect engineers from pressure to "just let it through"), the following are hard rejections with no exception path at the registry boundary:
- Confirmed malware or backdoor indicators.
- Invalid, missing, or untrusted signature on a Tier 1 image.
- Failed or absent provenance where the vendor tier requires it.
- Integrity/hash mismatch against the vendor-declared digest.
- A prohibited (copyleft-incompatible or denied) license in a distributed artifact.
- An expired security exception with no renewal.
Everything else — notably a critical CVE that the vendor disputes — flows into the structured validation and exception process rather than an ad-hoc email thread.
07 · Image Trust, Digital Signatures & Cosign
A signature answers one precise question: did the holder of a trusted key (or identity) attest to this exact artifact by digest? It does not prove the artifact is safe — SolarWinds was signed — but it is the foundation on which every other attestation is anchored.
The Three Signing Approaches in This Estate
Cosign / Sigstore
Part of the Sigstore project. Signs OCI artifacts and stores the signature in the registry alongside the image. Supports both key-based and keyless signing.
Keyless signing binds an identity rather than a long-lived key: Fulcio issues a short-lived certificate tied to an OIDC identity, and the signing event is recorded in the Rekor transparency log.
Notary v2 (notation)
An OCI-native signing specification using X.509 certificates and registry-stored signatures. Aligns with traditional PKI / certificate-authority trust models familiar to enterprises.
Harbor began deprecating the original Notary (v1 / Docker Content Trust) in v2.6; Cosign and Notary v2 are the forward-looking options.
Docker Content Trust (Notary v1)
The legacy TUF-based approach. Functional but being superseded; treat as legacy and migrate toward Cosign or Notary v2.
Listed here for completeness — not recommended for new Tier 1 trust anchors.
Keyed vs. Keyless: Choosing for an Insurance Enterprise
| Dimension | Key-based (Cosign + KMS/Vault) | Keyless (Sigstore: Fulcio + Rekor) |
|---|---|---|
| Trust anchor | Long-lived private key (store in HashiCorp Vault / KMS) | OIDC identity + short-lived cert; public transparency log |
| Key management burden | High — rotation, custody, HSM | Low — no long-lived key to protect |
| Air-gapped / on-prem fit | Strong — self-contained | Requires accessible Fulcio/Rekor (or self-hosted instances) |
| Auditability | Via internal logging | Strong — public/instance transparency log (Rekor) |
| Best fit here | Internal builds & regulated on-prem signing with Vault custody | OSS/vendor verification & CI identity-bound signing |
Use Cosign with keys custodied in HashiCorp Vault (or a Vault-backed KMS/transit engine) for internally produced and re-signed artifacts, giving the enterprise full control of the trust anchor. Verify vendor signatures against the specific identity registered at onboarding. Enforce verification at both the Nexus boundary and the OpenShift admission webhook — defense in depth, since a registry-only check can be bypassed by a direct cluster pull.
# Verify a vendor image against the identity registered at onboarding cosign verify registry.internal/vendor-x/app:1.4.2 \ --certificate-identity="release@vendor-x.example" \ --certificate-oidc-issuer="https://token.actions.githubusercontent.com" # Key-based verification using a Vault-custodied public key cosign verify --key hashivault://supply-chain/cosign-pub \ registry.internal/internal/payments-api@sha256:...
Signing proves integrity and origin, not safety. A compromised build pipeline (SolarWinds, 3CX) produces a perfectly valid signature over malicious content. This is precisely why Layer 1 (signing) must be paired with Layer 2 (provenance) — the subject of the next section.
08 · Provenance, SLSA & in-toto Attestations
Provenance answers the question signatures cannot: how, and by what process, was this artifact built? It is the control that directly targets build-system compromise — the attack class behind SolarWinds, 3CX, and Codecov.
SLSA — Supply-chain Levels for Software Artifacts
SLSA is an industry-consensus framework, originally proposed by Google in collaboration with the OpenSSF, that defines incrementally adoptable levels of build integrity. The v1.0 release marked the first stable version; the specification has since continued to evolve (the project now publishes a v1.2 Build track). The Build track levels capture increasing protection against tampering of the build, the provenance, or the artifact.
No guarantees"] --> L1["Build L1
Provenance exists
& is available"] L1 --> L2["Build L2
Signed provenance from
a hosted build platform"] L2 --> L3["Build L3
Hardened build platform;
non-falsifiable provenance"] classDef l0 fill:#9aa7b5,stroke:#5a6776,color:#fff; classDef l1 fill:#2b577f,stroke:#0b1f38,color:#fff; classDef l2 fill:#1f8fb3,stroke:#0b1f38,color:#fff; classDef l3 fill:#1f9d6b,stroke:#0b5a3c,color:#fff; class L0 l0; class L1 l1; class L2 l2; class L3 l3;
| Level | What it guarantees | Would it have helped against… |
|---|---|---|
| L0 | Nothing — absence of SLSA. | — |
| L1 | Provenance exists describing how the artifact was built. | Basic transparency; catches naive tampering. |
| L2 | Provenance is signed and generated by a hosted build platform. | Raises the bar against casual provenance forgery. |
| L3 | Hardened build platform; provenance is non-falsifiable and resistant to insider/build tampering. | SolarWinds-class build compromise — the target state for Tier 1 vendors. |
in-toto Attestations — The Container for Evidence
in-toto provides a standard, signed attestation format that binds a predicate (a statement about an artifact — its provenance, SBOM, test results, scan results) to a subject (the artifact, by digest). SLSA provenance is expressed as an in-toto predicate. Cosign can attach and verify these attestations against an image, giving a single mechanism to carry SBOM, provenance, and VEX as verifiable, signed evidence travelling with the artifact.
# Attach a signed SLSA provenance attestation to an image cosign attest --predicate provenance.json \ --type slsaprovenance --key hashivault://supply-chain/cosign-priv \ registry.internal/internal/app@sha256:... # Verify provenance at admission time cosign verify-attestation --type slsaprovenance \ --certificate-identity="build@internal" ... image@sha256:...
Provenance proves how something was built and that it was not altered afterward — it does not prove the inputs were benign. A backdoor introduced into source (XZ Utils) or a dependency (event-stream) yields entirely valid SLSA L3 provenance. Provenance must therefore be combined with composition analysis, dependency-trust controls, and runtime monitoring. For third-party images, you are typically consuming and verifying vendor provenance rather than producing it — so the practical control is requiring it contractually (Tier 1) and verifying it at admission.
09 · SBOM — One Component of the Framework
The Software Bill of Materials is essential, but it is a parts list, not a safety certificate. It tells you what is inside. It does not tell you whether what is inside is exploitable, reachable, or even truthfully declared. This framework treats the SBOM as Layer 3 of seven — necessary, foundational, and deliberately not sufficient.
EO 14028 (10(j)) defines an SBOM as a "formal record containing the details and supply chain relationships of various components used in building software" — analogous to an ingredients label. Its enduring value was proven by Log4Shell: organizations with accurate component inventories could answer "are we affected, and where?" in hours; those without spent weeks.
CycloneDX vs. SPDX
| Dimension | CycloneDX | SPDX |
|---|---|---|
| Steward | OWASP | Linux Foundation |
| Standardization | OWASP flagship; ECMA-424 | ISO/IEC 5962:2021 |
| Original focus | Application security & vulnerability management | License compliance & provenance |
| Native extensions | VEX, VDR, CBOM, ML-BOM, HBOM, SaaSBOM | Broad license metadata; relationships |
| Best leveraged for | Security-driven supply chain & VEX workflows | License governance & regulatory/long-term interchange |
Both are explicitly recognized in the U.S. federal "SBOM Minimum Elements" guidance, and tooling can convert between them. The choice is not zero-sum.
Standardize on CycloneDX as the primary internal format — its native VEX and security extensions align directly with the vendor-claim validation workflow that is this customer's core concern — while accepting SPDX from vendors that produce it and converting on ingest. Critically: always regenerate the SBOM independently from the delivered image using Trivy (or Syft) and reconcile it against the vendor-supplied SBOM. A discrepancy is itself a finding.
# Independently generate an SBOM from the delivered image (do not trust blindly) trivy image --format cyclonedx --output sbom.cdx.json vendor-x/app:1.4.2 # Compare component sets: vendor-supplied vs. independently generated # A delta — a package present in the image but absent from the vendor SBOM — # directly tests the claim "we don't use that package."
- Accuracy varies by ecosystem — statically linked, vendored, or stripped binaries can hide components.
- Presence ≠ exploitability — an SBOM lists Log4j; it does not say whether message-lookup is reachable.
- A vendor SBOM is a vendor assertion — trustworthy only when signed and independently corroborated.
- Backdoors evade it — XZ's malicious code lived inside a legitimate-looking component; the SBOM would have looked clean.
10 · VEX & Vulnerability Context
VEX — Vulnerability Exploitability eXchange — is the missing link between "a CVE is present" and "a CVE is exploitable." It is the machine-readable, signable form of the very claim vendors make verbally: "this vulnerability does not affect our product, and here is why."
VEX is a companion to the SBOM. Where the SBOM says a component is present, VEX states whether a known vulnerability in that component actually affects the product. It uses four status values, and — crucially — requires a justification when a product is declared not affected.
The Four VEX Status Values
Not Affected
No remediation required. Must carry a justification.
Affected
Action recommended; remediation needed.
Fixed
These versions contain a fix for the vulnerability.
Under Investigation
Not yet known whether the product is affected.
The "Not Affected" Justifications — This Is Where Vendor Claims Get Tested
When a vendor declares "not affected," VEX (in the CISA/OpenVEX and CSAF models) constrains them to a defined set of machine-readable justifications. This transforms a vague verbal excuse into a specific, checkable assertion:
| VEX Justification | Vendor is effectively claiming… | How you corroborate it |
|---|---|---|
component_not_present | "We don't ship that component at all." | Independent SBOM regeneration (Trivy/Syft); binary composition analysis. |
vulnerable_code_not_present | "The component is there but the vulnerable code path isn't included." | Version/build reconciliation; function-level analysis. |
vulnerable_code_not_in_execute_path | "The code exists but is never executed." | Reachability analysis + eBPF runtime confirmation (12). |
vulnerable_code_cannot_be_controlled_by_adversary | "An attacker can't reach the input that triggers it." | Architecture/exposure review; input-path analysis. |
inline_mitigations_already_exist | "A configuration or control already neutralizes it." | Configuration inspection; vendor advisory; runtime policy validation. |
VEX is the bridge between the customer's two stated concerns. It is simultaneously (a) the format in which a vendor must justify a "false positive" claim, and (b) the format in which the enterprise records its own verified decision. Insisting on signed VEX — rather than an email saying "don't worry about it" — is the single most practical upgrade to the vendor-claim process.
VEX Formats in This Estate
| Format | Steward / basis | Where it fits |
|---|---|---|
| CycloneDX VEX | OWASP (embedded in / alongside CycloneDX SBOM) | Primary internal format; travels with the SBOM. |
| OpenVEX | OpenSSF — minimal, standalone | Lightweight, ideal for automation and attaching via Cosign. |
| CSAF VEX | OASIS Common Security Advisory Framework | Vendor PSIRT advisories (e.g., Cisco publishes CSAF-compliant VEX). |
- It is still an assertion. A signed VEX from a compromised or careless vendor can be wrong. Corroborate the high-impact ones.
- Coverage is incomplete. Most vendors do not yet publish comprehensive VEX; absence is common, not proof of safety.
- It can be gamed. A vendor could over-use
not_affectedto suppress noise. Track vendor VEX accuracy over time as a trust metric. - Justifications need evidence. "not in execute path" is only as good as the analysis behind it — which is why 12 exists.
11 · How Enterprises Validate Vendor Claims
This is the heart of the framework and the customer's central question: when a vendor disputes a finding and you cannot see the source code, how do you actually verify the claim? The answer is a layered evidence model that progressively narrows uncertainty — from documents, to static analysis, to the ground truth of runtime behavior.
The Evidence Hierarchy
Not all evidence is equal. Vendor assertions sit at the bottom; observed runtime behavior sits at the top. The enterprise's job is to climb this ladder until residual uncertainty is acceptable for the workload's risk tier.
eBPF telemetry: is the module loaded? is the function called?"] E2["Tier 4 · Independent static analysis
Your own reachability / call-graph analysis"] E3["Tier 3 · Signed, verifiable evidence
Signed VEX + SLSA provenance + attestations"] E4["Tier 2 · Independent corroboration
Trivy/Syft SBOM regeneration; hash reconciliation"] E5["Tier 1 · Vendor assertion
'It's a false positive' (email / call)"] E5 --> E4 --> E3 --> E2 --> E1 classDef weak fill:#cc1f2d,stroke:#8e1420,color:#fff; classDef mid fill:#d98a1f,stroke:#9a5a08,color:#fff; classDef strong fill:#1f9d6b,stroke:#0b5a3c,color:#fff; class E5 weak; class E4,E3 mid; class E2,E1 strong;
Validating the Three Hardest Claims, Step by Step
Claim A — "It's a false positive"
Reconcile coordinates
Confirm the exact component, version, and PURL the scanner flagged. Many "false positives" are version-detection errors — verify against the image's package database and file hashes.
Regenerate independently
Run Trivy and a second tool (e.g., Prisma Cloud, or Syft for SBOM regeneration) on the image. Concurring tools strengthen the finding; a divergence may validate the vendor's point.
Demand a signed VEX
Require the vendor to express the false-positive claim as a signed VEX with a specific justification (e.g.,
component_not_present). A vendor unwilling to sign their own claim is a risk signal.Corroborate the justification
Test the justification against your independent SBOM and, where needed, escalate to reachability/runtime (Claims B/C).
Claim B — "We don't use that package"
This is the most directly verifiable claim, because presence is an observable property of the delivered binary — no source code required.
- Independently generate the SBOM from the image; search for the component by name, PURL, and file hash.
- Inspect image layers and the filesystem for the library/binary (e.g., the actual
.jar,.so, or module). - If present despite the denial, the claim is false on its face — and that is a material trust event, not a routine disagreement.
- If genuinely absent, capture this as a verified VEX
component_not_presentin your own records.
Claim C — "The vulnerable code isn't reachable / isn't executed"
This is the hardest claim to verify without source, and where most enterprises stop. It is also where this framework adds the most value, by combining static reachability with runtime observation (detailed in 12).
Request the vendor's reachability evidence
A credible vendor can supply call-graph or reachability analysis showing no path reaches the vulnerable function — expressed as VEX
vulnerable_code_not_in_execute_path.Run independent reachability analysis
Use binary/bytecode call-graph tooling to test whether the vulnerable symbol is referenced on any reachable path in the delivered artifact.
Confirm with runtime telemetry
Deploy to a representative pre-production environment and use eBPF (Falco/Tetragon) or Prisma Cloud runtime to observe whether the vulnerable module is loaded and the function called under realistic load. Runtime non-execution over a representative window is strong corroboration.
Record the residual
Reachability is probabilistic, not absolute — document the analysis window and assumptions so the residual risk is explicit in any exception.
Can You Verify Without Source Code? — The Honest Answer
Yes, strongly
- Component presence/absence
- Version & integrity (hashes)
- Signature & provenance validity
- Whether a module loads at runtime
- Whether a function executes at runtime
Partially
- · Static reachability (binary analysis is harder than source)
- · Whether config truly mitigates a flaw
- · Exploitability under all inputs (you observe a window, not all paths)
No / very hard
- Intentional logic bombs / dormant backdoors (XZ-style)
- Vulnerabilities triggered only by rare states
- Vendor's internal design intent
Additional Evidence to Request — The Vendor Evidence Pack
| Evidence | What it establishes | Tier where required |
|---|---|---|
| Signed image (Cosign / Notary v2) | Origin & integrity | 1, 2 |
| SLSA provenance attestation | Build integrity | 1 (L3 target), 2 (L2) |
| SBOM (CycloneDX / SPDX) per release | Composition | 1, 2 |
| Signed VEX with justifications | Exploitability rationale | 1, 2 (critical) |
| Reachability analysis report | Code-path exploitability | 1 (disputed criticals) |
| Security advisory / PSIRT reference | Vendor's formal position | 1, 2 |
| Remediation timeline / SLA commitment | Forward risk management | 1, 2 |
| Penetration test / SDLC attestation (SSDF) | Vendor's own hygiene | 1 |
Comparison of Validation Techniques
| Technique | What it proves | Source needed? | Confidence | Key limitation |
|---|---|---|---|---|
| Vendor SBOM | Declared composition | No | Medium | An assertion; accuracy varies |
| Independent SBOM (Trivy/Syft) | Actual composition of the binary | No | High | Misses statically-linked/vendored code |
| VEX | Exploitability rationale | No | Medium | Still an assertion unless corroborated |
| Static reachability | No code path to the flaw | Helps | Medium | Hard on binaries; dynamic dispatch/reflection |
| eBPF runtime monitoring | Module not loaded / not called | No | High* | Only proves behavior over the observed window |
| Provenance (SLSA) | Build was not tampered | No | High | Says nothing about malicious inputs |
| Signed attestation | Evidence is authentic | No | High | Trust depends on the signer |
| Runtime telemetry (exploit attempts) | Active exploitation / anomaly | No | High | Detective, not preventive |
No combination of these techniques would have reliably caught the XZ Utils backdoor at intake: it was deliberately dormant, obfuscated, and triggered only under specific conditions. This is the residual that justifies the final layer — continuous runtime monitoring and behavioral anomaly detection (13). Validation reduces uncertainty; it never eliminates it. Govern accordingly: assume breach, monitor always.
12 · Reachability & Runtime Exploitability
Most critical CVEs flagged in a vendor image are present but not exploitable in context. Reachability and runtime exploitability analysis are how the enterprise separates the genuine exposure from the noise — and how it independently tests the vendor's "not reachable" claim.
Two Complementary Questions
Static reachability
Does any call path in the artifact reach the vulnerable function? Answered by call-graph analysis of bytecode/binaries — before deployment. Conservative: if a path could exist, it is treated as reachable.
Strength: pre-deployment, no running workload needed.
Weakness: dynamic dispatch, reflection, and native code defeat precision; binary analysis is far harder than source analysis.
Runtime exploitability
Is the vulnerable module actually loaded, and is the vulnerable function actually called, when the workload runs realistically? Answered by eBPF instrumentation and runtime defense tooling.
Strength: observes ground truth; no source needed.
Weakness: only covers the observed window and exercised paths.
How Runtime Exploitability Resolves a Disputed Claim
eBPF — The Enabling Technology
eBPF (extended Berkeley Packet Filter) lets security tools attach programs to Linux kernel hooks and observe syscalls, network activity, file I/O, and process behavior across every container on a node — with low overhead and without source code. This is what makes runtime exploitability verification practical at scale on OpenShift.
| Tool | Model | Primary role here |
|---|---|---|
| Falco | eBPF + rules engine (CNCF) | Detect anomalous syscalls/behavior; alert on policy violations. |
| Tetragon (Cilium) | eBPF; applies policy & filtering in-kernel | Process/function-level observability and runtime enforcement. |
| Prisma Cloud (Defender) | Agent-based runtime defense | Models expected container behavior; flags drift & exploit attempts (integrated with the customer's existing stack). |
- Window-bound. Runtime proves what happened while you watched, not what could happen under an unobserved input.
- Coverage gaps. A code path not exercised in pre-prod may still execute in production — hence the standing production alert.
- Static imprecision. Reflection, dynamic class loading, and native interop reduce call-graph accuracy on binaries.
- Adversarial dormancy. Malicious code designed to stay dormant (XZ) will not reveal itself in benign runtime observation.
Use reachability as a prioritization and tie-breaking control, not a universal gate. Apply it specifically to disputed critical/high findings on Tier 1/2 workloads. When runtime confirms non-exploitation, do not simply close the finding — convert it into a monitored exception with a standing alert that fires if the vulnerable module ever loads in production.
13 · Runtime Monitoring & Drift Detection
Admission control is a point-in-time decision. Production is continuous. Because validation can never be complete — and because new vulnerabilities are disclosed daily — runtime monitoring is the layer that catches what intake could not, and confirms that what runs is still what was approved.
Drift Detection — Has the Running Workload Changed?
Drift is any divergence between the approved artifact and what is actually executing: an unexpected process, a binary that was not in the image, an outbound connection to an unknown host, a filesystem change. Drift detection treats the verified image as a baseline and flags deviation. Codecov-style tampering and post-deployment compromise both surface as drift.
baseline (digest +
expected behavior)"] --> RUN["Running container
on OpenShift"] RUN --> OBS["eBPF + Prisma Cloud
observe actual behavior"] OBS --> CMP{"Matches
baseline?"} CMP -->|Yes| OK["Normal — continue"] CMP -->|"No (drift)"| ALERT["Alert + SIEM"] ALERT --> RESP["Respond:
isolate / kill / investigate"] classDef ok fill:#1f9d6b,stroke:#0b5a3c,color:#fff; classDef bad fill:#cc1f2d,stroke:#8e1420,color:#fff; class OK ok; class ALERT,RESP bad;
Continuous Vulnerability Monitoring
The Log4Shell timeline is the canonical lesson: a component sitting safely in production for years became a CVSS 10.0 emergency overnight. The framework therefore re-evaluates already-admitted artifacts continuously:
- Registry re-scanning — Trivy, Prisma Cloud, and Nexus re-evaluate stored images against updated vulnerability and malware intelligence on a schedule, not just at push time.
- SBOM-driven impact analysis — when a new CVE drops, query stored SBOMs to instantly answer "which of our running images contain the affected component, and where?"
- VEX & advisory feeds — ingest vendor PSIRT advisories and VEX updates so a previously "not affected" status that changes to "affected" triggers re-assessment.
- Runtime exploit detection — eBPF/Prisma watch for active exploitation patterns against known-present components.
The Post-Deployment Monitoring Loop
/ VEX update"] --> B["Match against
stored SBOMs"] B --> C{"Affected images
in production?"} C -->|No| D["Record & close"] C -->|Yes| E["Reachability +
runtime triage"] E --> F{"Exploitable
in context?"} F -->|No| G["Document VEX
not_affected + monitor"] F -->|Yes| H["Remediation workflow:
patch / exception / replace"] H --> I["Re-validate & re-admit"] I --> A classDef ok fill:#1f9d6b,stroke:#0b5a3c,color:#fff; classDef warn fill:#cc1f2d,stroke:#8e1420,color:#fff; class G ok; class H warn;
Wire runtime detections and drift alerts into the enterprise SIEM and the incident-response runbook, and pre-define the containment action per severity. The value of detection is realized only if a fast, rehearsed response follows. For Tier 1 workloads, treat unexplained drift as a potential supply chain compromise until proven otherwise.
14 · License Governance
For a regulated insurer, an undetected copyleft obligation in a third-party image is a legal and intellectual-property exposure, not merely a hygiene issue. License governance rides on the same SBOM and registry machinery as security, and is enforced at the same gates.
Permitted
Permissive licenses (e.g., MIT, Apache-2.0, BSD) — auto-approved, recorded in the SBOM.
Review required
Weak copyleft (e.g., LGPL, MPL) — allowed with legal review of linkage/distribution context.
Restricted / denied
Strong copyleft (e.g., GPL/AGPL) in distributed artifacts, or unknown/missing licenses — blocked pending counsel.
License Controls in the Pipeline
- Detection — license metadata captured in the SBOM (SPDX excels here) during build and registry ingest.
- Policy enforcement — Nexus Repository Firewall and IQ policies block or warn on deny-listed licenses at the proxy boundary.
- Attribution & obligations — generate and retain attribution notices for distributed software to satisfy license terms.
- Continuous review — license changes between vendor releases are flagged the same way version changes are.
License detection is only as accurate as declared metadata. Dual-licensed, re-licensed, or undeclared components require human legal review — automation flags, counsel decides. "Unknown license" should be treated as restricted by default, not waved through.
15 · Policy as Code
Governance that lives in a PDF is advisory. Governance expressed as code is enforced automatically, consistently, and verifiably — the same policy evaluated identically for every artifact, with the decision logged. This is what makes the framework auditable rather than aspirational.
Where Policy as Code Executes
| Enforcement point | Engine | What it enforces |
|---|---|---|
| Registry ingest | Nexus Repository Firewall / IQ policy | Malware, CVE, license, age, integrity policies on inbound components. |
| CI/CD pipeline | Pipeline policy gates (Git-based CI/CD) | Fail builds on policy violations; require SBOM, signature, provenance. |
| OpenShift admission | OPA/Gatekeeper or Kyverno admission webhook | Reject pods whose images are unsigned, unverified, or non-compliant. |
| Cloud / runtime | Prisma Cloud policies | Posture and runtime policy across the OpenShift estate. |
Illustrative Admission Policy
The policy below is a representative pattern, not a named-company configuration. It shows how an OpenShift admission gate enforces signature verification and blocks unresolved criticals while honoring a verified VEX/exception.
# Kyverno-style admission policy (illustrative) apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: supply-chain-admission spec: validationFailureAction: Enforce rules: - name: require-trusted-signature match: { resources: { kinds: [Pod] } } verifyImages: - imageReferences: ["registry.internal/*"] attestors: # verify Cosign signature / identity - entries: [{ keys: { kms: "hashivault://supply-chain/cosign-pub" } }] required: true - name: block-unresolved-critical # unless a verified VEX/exception label is present match: { resources: { kinds: [Pod] } } validate: message: "Unresolved CRITICAL with no verified VEX/exception."
Keep policy in version control alongside application code, peer-reviewed and tested like any other code, with changes flowing through the same Git-based pipeline. Run policies in warn/audit mode first to measure impact, then promote to enforce. Store the resulting decisions immutably for audit (17).
16 · Risk Acceptance, Exceptions & Governance Boards
Some risk will always be accepted — the question is whether it is accepted knowingly, by the right person, with controls and an expiry date, or silently by an engineer under delivery pressure. The exception process exists to make the former the only sanctioned path.
The Supply Chain Risk Matrix
Every disputed or unresolved finding is scored on likelihood of exploitation (informed by reachability/runtime evidence) against business impact (informed by data sensitivity and exposure). The score sets the required approval authority.
(PII/claims, internet-facing)
Likelihood is adjusted downward by verified non-reachability/non-execution evidence and upward by known active exploitation (e.g., presence on the CISA Known Exploited Vulnerabilities catalog).
The Exception Decision Tree
on a vendor image"] --> Q1{"Malware or
integrity failure?"} Q1 -->|Yes| REJ["REJECT — no exception"] Q1 -->|No| Q2{"Fixed version
available?"} Q2 -->|Yes| FIX["Require fix —
no exception needed"] Q2 -->|No| Q3{"Verified non-exploitable?
(VEX + reachability + runtime)"} Q3 -->|Yes| MON["Monitored exception
+ standing runtime alert"] Q3 -->|Inconclusive| Q4{"Compensating
controls available?"} Q4 -->|No| REJ Q4 -->|Yes| Q5{"Risk score?"} Q5 -->|Low/Med| TEX["Time-boxed exception
(security lead)"] Q5 -->|High| BEX["Time-boxed exception
(governance board)"] Q5 -->|Critical| REJ classDef rej fill:#cc1f2d,stroke:#8e1420,color:#fff; classDef ok fill:#1f9d6b,stroke:#0b5a3c,color:#fff; class REJ rej; class FIX,MON,TEX,BEX ok;
Anatomy of a Valid Exception Record
| Field | Requirement |
|---|---|
| Finding & artifact | CVE(s), component (PURL), image digest, vendor, version. |
| Justification & evidence | Why accepted — linked VEX, reachability report, runtime telemetry. |
| Compensating controls | What reduces the residual risk (network policy, WAF, runtime alert, isolation). |
| Risk score & approver | Matrix score and the named individual/board at the correct authority level. |
| Expiry | Mandatory end date; auto-revokes and re-blocks at the registry on expiry. |
| Accountable owner | A named person who owns the residual risk — never "the team." |
| Audit reference | Immutable record ID linking to the decision and evidence. |
The Supply Chain Governance Board
A standing, cross-functional board owns the framework and adjudicates High-risk exceptions. Membership spans the customer's named stakeholder groups:
Security & Architecture
Security Architects and the CISO office — own risk standards and final security veto.
Engineering & Platform
DevSecOps, Platform, and Enterprise Architecture — own enforcement and feasibility.
Risk, Compliance & Legal
Own regulatory alignment, license risk, and the audit posture.
Cap exception duration (e.g., 90 days for High, 30 for time-sensitive criticals), forbid auto-renewal without re-evaluation, and publish an exception aging report to the board each cycle. A growing backlog of stale exceptions is the leading indicator that governance is decaying — track it as a board-level KPI.
17 · Continuous Compliance & Audit Trails
For an insurer, the framework must do more than reduce risk — it must demonstrate that risk was managed, to auditors, regulators, and the enterprise's own cyber-insurers. Continuous compliance means the evidence is generated as a by-product of the pipeline, not assembled in a panic before an audit.
Audit Trail — Every Decision, Immutable
Each artifact accumulates a verifiable chain of evidence and decisions, stored immutably (write-once, tamper-evident) and queryable:
- Who signed the image, and was the signature verified at admission.
- What provenance and attestations were present and validated.
- What the SBOM contained, and how the independent SBOM compared.
- What scanners reported, and what VEX statements applied.
- What admission decision was made, by which policy, at what time.
- What exceptions were granted, by whom, with what controls and expiry.
- What runtime events and drift alerts occurred post-deployment.
The Executive Compliance Dashboard
Governance is only as strong as leadership's visibility into it. The following dashboard pattern translates the framework's machinery into board-level signals.
The figures above are sample targets to show the shape of an executive dashboard, not measurements from any organization. In adoption, these become live KPIs sourced from Nexus, Prisma Cloud, the admission controller, and the exception register.
Recommended Governance KPIs
| KPI | What it tells leadership | Healthy direction |
|---|---|---|
| Signature verification coverage | Authenticity enforcement reach | → 100% for Tier 1/2 |
| Provenance attestation coverage | Build-integrity assurance | Increasing |
| Mean time to remediate (MTTR) criticals | Responsiveness to disclosure | Decreasing |
| Open exceptions & average age | Accumulated accepted risk | Low & stable |
| Vendor VEX accuracy | Trustworthiness of vendor claims | High per vendor |
| Firewall quarantine events | Threats stopped at the boundary | Tracked / triaged |
| Drift alerts & runtime detections | Post-deployment integrity | Low, fully triaged |
Regulatory & Standards Alignment
The framework maps cleanly onto the public baselines that increasingly shape expectations for regulated enterprises:
| Reference | Relevance |
|---|---|
| EO 14028 | Establishes SBOM definition and the federal push for software supply chain security; sets the direction the broader market follows. |
| NIST SP 800-218 (SSDF) | Secure Software Development Framework — the baseline against which to assess vendors; basis for the CISA secure-software attestation. |
| NIST SP 800-161 | Cyber supply chain risk management practices for the enterprise program itself. |
| SLSA | Build-integrity levels for provenance requirements. |
| ISO/IEC 5962 | Standardizes the SPDX SBOM format. |
Insurance supervision is jurisdiction-specific (for example, NYDFS Part 500 in New York, and operational-resilience regimes such as the EU's DORA for financial entities). This framework is designed to support such obligations through demonstrable third-party software due diligence and auditability, but mapping to a specific regulator's text should be confirmed with the enterprise's own compliance and legal functions.
18 · Reference Architecture
The framework mapped onto the customer's actual stack — Red Hat OpenShift, Sonatype Nexus & Repository Firewall, Prisma Cloud, Trivy, HashiCorp Vault, and Git-based CI/CD — showing where each control executes and where trust decisions are enforced.
(image + SBOM + VEX
+ signature + provenance)"] OSS["Public registries /
OSS dependencies"] end subgraph GATE["Ingress & Governance"] NXFW{{"Sonatype Repository Firewall
policy + quarantine"}} NEXUS["Nexus Repository
(proxy + hosted + staging)"] end subgraph CICD["Git-based CI/CD"] BUILD["Build & verify:
Trivy scan, SBOM gen,
Cosign verify, provenance"] VAULT[("HashiCorp Vault
signing keys + dynamic secrets")] end subgraph OCP["Red Hat OpenShift"] ADM{{"Admission control
OPA/Gatekeeper · Kyverno
(verify sig + policy)"}} WL["Workloads
(running containers)"] PRISMA["Prisma Cloud Defender
+ eBPF (Falco/Tetragon)"] end SIEM[("SIEM + Audit trail
+ Governance dashboard")] OSS --> NXFW VND --> NXFW NXFW -->|pass| NEXUS NXFW -->|fail| QUAR["Quarantine"] NEXUS --> BUILD VAULT -.-> BUILD VAULT -.-> ADM BUILD --> ADM ADM -->|admit| WL ADM -->|reject| BLK["Blocked"] WL --> PRISMA PRISMA --> SIEM ADM --> SIEM NXFW --> SIEM PRISMA -.->|new CVE / drift| NEXUS classDef bad fill:#cc1f2d,stroke:#8e1420,color:#fff; classDef vault fill:#15375f,stroke:#0b1f38,color:#fff; class QUAR,BLK bad; class VAULT,SIEM vault;
Control Placement Summary
| Stage | Component | Controls enforced |
|---|---|---|
| Ingress | Sonatype Repository Firewall | Malware/CVE/license/age/integrity policy; quarantine of violating components. |
| Storage | Nexus Repository | System of record; proxy/hosted/staging separation; vendor namespace isolation. |
| Build | Git-based CI/CD + Trivy | Independent SBOM generation, scanning, signature & provenance verification, policy gates. |
| Secrets & signing | HashiCorp Vault | Custody of Cosign keys; dynamic, short-lived CI secrets (limits CircleCI-style blast radius). |
| Admission | OpenShift + OPA/Gatekeeper or Kyverno | Reject unsigned/unverified/non-compliant pods; honor verified VEX/exception labels. |
| Runtime | Prisma Cloud + eBPF | Reachability/exploitability confirmation, drift detection, exploit-attempt detection. |
| Assurance | SIEM + audit store | Immutable decision log, KPIs, executive dashboard, continuous compliance evidence. |
Signature and policy verification are enforced at both the registry boundary and OpenShift admission. A registry-only check is bypassable by a workload that pulls an image directly to a node; an admission-only check trusts a registry that may have been populated out-of-band. Both gates, backed by the same Vault-anchored trust policy, provide defense in depth.
19 · How Leading Organizations Approach This
The patterns in this framework are not theoretical — they reflect approaches that major technology and regulated organizations have adopted and, in several cases, publicly documented. The summaries below are restricted to what each organization has stated publicly.
Technology-vendor practices (Google, Microsoft, Red Hat) are drawn from their own public documentation and are cited in Section R. For financial-services and insurance firms, detailed internal software-supply-chain implementations are generally not publicly disclosed; where this document discusses how such an enterprise might apply a control, it is explicitly marked "Illustrative enterprise example" and should not be read as a statement about that company's actual internal systems.
Publicly Documented Technology-Vendor Practices
Co-proposed SLSA with the OpenSSF (2021) as an end-to-end supply chain integrity framework. Internally enforces Binary Authorization for Borg (BAB), a deploy-time check ensuring production code is reviewed, checked in, and verifiably built. Offers Binary Authorization and SLSA-provenance verification on GKE/Cloud Build.
Microsoft
An engineer (Andres Freund) discovered the XZ Utils backdoor while investigating SSH latency — a real-world example of behavioral anomaly detection. Microsoft open-sourced its SBOM generation tool, producing SPDX-format SBOMs from internal build practice.
Red Hat
Signs its container images and publishes machine-readable security data: CSAF VEX documents (generally available since 2023) and per-CVE VEX files in CSAF format via the Customer Portal — a working model of vendor-published, machine-readable exploitability data.
Open-Source Governance Heritage in Financial Services
Capital One — governance-as-code
Capital One created and open-sourced Cloud Custodian (now a CNCF project), a policy-as-code engine for cloud governance. While focused on cloud-resource policy rather than image supply chain specifically, it publicly demonstrates a financial institution's embrace of policy-as-code — the same principle this framework applies at 15.
Insurers & banks — sector posture illustrative
Large insurers and banks (e.g., Allianz, AXA, Zurich, MetLife, Prudential, JPMorgan Chase) operate under stringent third-party risk regulation and commonly participate in sector information-sharing (such as FS-ISAC). Specific internal supply-chain tooling is generally not publicly disclosed; the controls in this framework are presented as how such a regulated enterprise can meet those obligations, not as a description of any one firm's systems.
Common Threads Across Mature Programs
- Provenance and build integrity are treated as first-class, not optional (SLSA, BAB).
- Machine-readable security data (SBOM, VEX/CSAF) is produced and consumed programmatically, not via email (Red Hat, Microsoft).
- Policy-as-code turns governance into enforced, auditable automation (Capital One / Cloud Custodian).
- Behavioral/runtime signals catch what intake checks miss (the XZ discovery).
20 · Consultant Recommendations & Adoption Roadmap
A framework is only valuable if it can be adopted without halting delivery. The following phased roadmap sequences the controls by risk-reduction leverage and implementation effort, mapped to the customer's existing tooling so that most phases extend — rather than replace — what is already in place.
Phased Adoption Roadmap
| Phase | Focus | Key actions | Outcome |
|---|---|---|---|
| 0 — Baseline 0–1 mo | See what you have | Inventory vendor images; turn on Trivy + Prisma scanning everywhere; confirm Repository Firewall quarantine is enabled for malicious components. | Visibility & a malware floor. |
| 1 — Authenticity 1–3 mo | Layer 1 | Stand up Cosign verification with keys in Vault; enforce signatures at the OpenShift admission webhook for Tier 1; register vendor signing identities. | No unsigned Tier 1 image runs. |
| 2 — Evidence as contract 2–4 mo | Onboarding | Codify SBOM/VEX/provenance as onboarding deliverables; deploy the tiering model; require signed VEX for disputed findings. | Burden of proof shifts to vendors. |
| 3 — Composition & context 3–6 mo | Layers 3–4 | Independent SBOM regeneration & reconciliation; ingest VEX into scan triage; SBOM-driven CVE impact queries. | Noise reduced; faster Log4Shell-style response. |
| 4 — Provenance 4–8 mo | Layer 2 | Verify SLSA provenance / in-toto attestations at admission; push Tier 1 vendors toward Build L3. | Defense against build-system compromise. |
| 5 — Exploitability 6–10 mo | Layer 5 | Reachability analysis for disputed criticals; eBPF runtime confirmation (Falco/Tetragon) integrated with Prisma Cloud. | Vendor "not reachable" claims independently verifiable. |
| 6 — Continuous assurance ongoing | Layers 6–7 | Policy-as-code in enforce mode; drift detection; exception register; executive dashboard & audit trail. | Self-sustaining, auditable governance. |
Ten Recommendations for Leadership
1. Make evidence contractual
Require signature, SBOM, VEX, and provenance at onboarding — not during incidents.
2. Never accept "false positive" verbally
Demand a signed VEX with a justification you can corroborate.
3. Verify at two choke points
Enforce trust at both the Repository Firewall and OpenShift admission.
4. Treat the SBOM as one layer
Pair it with provenance, VEX, reachability, and runtime — never alone.
5. Use runtime as the tie-breaker
eBPF telemetry resolves disputed "not reachable" claims with ground truth.
6. Custody signing keys in Vault
Own the trust anchor; use dynamic, short-lived CI secrets.
7. Time-box every exception
Named owner, compensating controls, expiry, board approval for High.
8. Assess the vendor's supply chain
3CX proves vendor trust is transitive — assess their hygiene (SSDF).
9. Monitor forever
Re-scan, watch advisories, and detect drift — admission is not the end.
10. Make it auditable by design
Generate immutable evidence as a by-product of the pipeline.
The enterprise will never own the source code of its vendors — and it does not need to. What it needs is a disciplined system that converts every claim into a verifiable evidence requirement, enforces trust decisions automatically, and watches continuously for the residual it cannot eliminate. That system is the difference between hoping a vendor image is safe and being able to demonstrate, to a regulator or an auditor, exactly why it was trusted — or why it was not.
A · Appendices
Appendix A — Admit / Reject Quick-Reference
Reject outright (no exception)
- Confirmed malware / backdoor indicators
- Invalid or missing signature (Tier 1)
- Hash / integrity mismatch vs. declared digest
- Failed provenance where tier requires it
- Prohibited license in a distributed artifact
- Expired exception, not renewed
Admit (with conditions)
- Signed, provenance-verified, clean scan
- Findings resolved by fixed version
- Verified non-exploitable (VEX + reachability + runtime) → monitored
- Board-approved, time-boxed exception with controls
Appendix B — Evidence Requirements by Vendor Tier
| Evidence | Tier 1 (Critical) | Tier 2 (Important) | Tier 3 (Standard) |
|---|---|---|---|
| Signed image | Required | Required | Preferred |
| SLSA provenance | Required (L3) | Required (L2) | Optional |
| SBOM per release | Required | Required | On request |
| Signed VEX | All crit/high | Criticals | On dispute |
| Reachability report | Disputed criticals | On request | — |
| PSIRT / advisory feed | Required | Required | Optional |
| SSDF / SDLC attestation | Required | Preferred | — |
Appendix C — Glossary
| Term | Definition |
|---|---|
| Attestation | A signed, machine-readable statement (predicate) about an artifact (subject), e.g., in-toto. |
| CSAF | Common Security Advisory Framework (OASIS) — a standard for machine-readable security advisories, with a VEX profile. |
| Cosign | Sigstore tool for signing/verifying OCI artifacts; supports keyed and keyless signing. |
| CycloneDX | OWASP SBOM standard (ECMA-424) with native VEX and security extensions. |
| Drift | Divergence between an approved artifact's baseline and its actual runtime behavior. |
| eBPF | Extended Berkeley Packet Filter — Linux kernel technology for low-overhead observability and security enforcement. |
| Fulcio / Rekor | Sigstore components: Fulcio issues short-lived signing certificates; Rekor is the signature transparency log. |
| in-toto | Framework defining a standard signed attestation format for supply chain steps. |
| Notary v2 (notation) | OCI-native, X.509-based artifact signing specification. |
| Provenance | Verifiable metadata describing how, where, and from what an artifact was built. |
| PURL | Package URL — a standardized identifier for a software package (name, version, ecosystem). |
| Reachability analysis | Determining whether a vulnerable code path can actually be invoked in a given artifact. |
| SBOM | Software Bill of Materials — a formal inventory of components and their relationships. |
| SLSA | Supply-chain Levels for Software Artifacts — a build-integrity framework with incremental levels. |
| SPDX | Software Package Data Exchange — Linux Foundation SBOM standard (ISO/IEC 5962:2021). |
| SSDF | Secure Software Development Framework (NIST SP 800-218). |
| VEX | Vulnerability Exploitability eXchange — machine-readable statement of whether a vulnerability affects a product. |
R · References & Sources
All technical standards, incidents, and named-company practices in this document are drawn from the public primary sources below. Content from these sources has been paraphrased and summarized for compliance with licensing restrictions.
Standards & Frameworks
- SLSA — Supply-chain Levels for Software Artifacts, security levels & build track. slsa.dev/spec
- Sigstore / Cosign signing documentation. docs.sigstore.dev/cosign
- OASIS CSAF & CSAF VEX examples. github.com/oasis-tcs/csaf
- OpenVEX / OpenSSF; CISA VEX status & justification guidance.
- OWASP CycloneDX; SPDX (ISO/IEC 5962:2021).
- NIST — EO 14028 SBOM guidance; SP 800-218 (SSDF); SP 800-161. nist.gov
- NIST National Vulnerability Database (NVD) — CVE-2021-44228, CVE-2024-3094.
Incidents (primary / authoritative reporting)
- SolarWinds / SUNBURST — FireEye/Mandiant & Google Cloud Threat Intelligence.
- Log4Shell (CVE-2021-44228) — Apache Software Foundation; NIST NVD; IBM X-Force.
- XZ Utils backdoor (CVE-2024-3094) — NIST NVD; Openwall mailing-list disclosure; vendor analyses (Tenable, Sysdig, Wiz).
- 3CX cascading compromise — Mandiant / Google Cloud; MITRE ATT&CK Campaign C0057; Unit 42.
- Codecov Bash Uploader — Codecov post-mortem; Rapid7; CISA/CCCS advisories.
- CircleCI incident (Jan 2023) — CircleCI incident report & security alerts.
- npm event-stream / flatmap-stream — npm security advisory; Snyk post-mortem.
Tooling & Vendor Documentation
- Sonatype — Repository Firewall Audit & Quarantine documentation. help.sonatype.com
- Falco (CNCF) & Cilium Tetragon — eBPF runtime security documentation.
- Google — SLSA introduction (Google Security Blog); Binary Authorization for Borg. cloud.google.com
- Microsoft — open-source SBOM tool (SPDX). github.com/microsoft/sbom-tool
- Red Hat — CSAF VEX documents & per-CVE VEX data. redhat.com/security
- Capital One — Cloud Custodian (open-source policy-as-code; CNCF).
Every factual claim in this document was verified against the public sources listed above at the time of authoring. Where a fact could not be publicly verified for a specific named organization — particularly internal implementations at insurance and banking firms — it is labelled "Illustrative enterprise example" rather than presented as fact. Source content has been paraphrased; no extended verbatim text is reproduced.