Helpful first: CI/CD trust boundaries: writing code vs promoting to production · Threat, vulnerability, and risk: the core equation
Key points
- Verify that an SBOM inventory is bound to the exact build and digest running in the target environment
- Combine SBOM component records with VEX / runtime condition evidence before declaring a service safe or compromised
- The inventory connects to the build that production runs. An owner decision is separate from a deployed fix.
An SBOM describes a specific build artifact, not a service name
When a high-profile vulnerability advisory drops (AD17 targeting parse-), executives immediately ask: "Are we affected?" At Meridian Space & Robotics (chronos.), Principal Security Architect Vera Vance teaches the team to answer with provenance records rather than guesswork, using a Software Bill of Materials (SBOM) generated in CycloneDX or SPDX format at build time.
The critical mistake teams make is treating an SBOM as a timeless label for an application name. If your CI pipeline generated SBOM SB42 for build B42 (digest D42), that document proves what was compiled into B42/. If the production cluster is actually still running an older build B41 (digest D41), then SB42 cannot tell you what components or conditions exist inside the running B41 pods! You can practice this exact investigation workflow in the [SBOM Decision Lab](Defer with a date, or patch for a reason).
| Evidence Rung | Verification Question | Artifact / Record Checked | What Remains Unproven If It Fails |
|---|---|---|---|
| 1. Advisory Match | Does the SBOM list the vulnerable package and version? | SBOM SB42 (direct: cart-, nested: parse-) vs Advisory AD17 | Whether SB42 is the artifact actually executing in production |
| 2. Build-to-Runtime Binding | Does the SBOM’s build digest match the running production container digest? | SBOM subject Build B42 · digest D42 vs cluster runtime Runs B42 · D42 (or mismatch B41 · D41) | If production runs B41 · D41, B42 records cannot prove B41 conditions |
| 3. Runtime Conditions & Exploit Evidence | Are the vulnerable code path or configuration conditions active, and is there exploit telemetry? | Condition record E9 and telemetry (Exploit evidence: unknown) | Absence of exploit alerts (unknown) never proves a vulnerable build is safe |
| 4. Owner Decision vs Remediation | Has an accountable owner logged a dated remediation ticket, or has the patched build actually shipped? | Decision DEC9 (Maya · Oct 1, 14:00 UTC, Test fix 1.) vs Fix: not deployed | A scheduled plan (Planned is not patched) leaves runtime risk open until 1. is deployed |
Walking the SBOM decision ladder step by step
Trace both tracks in the interactive figure below. In the primary track, SBOM SB42 for Build B42 · digest D42 shows Direct: cart- and Nested: parse-, which matches advisory AD17 (Version: 1.). Next, we check runtime binding: production Runs B42 · D42, so the inventory matches the running workload, and evidence E9 confirms the vulnerable condition is present while Exploit evidence: unknown remains open.
Now watch the final two steps carefully. Engineering owner Maya records decision DEC9 (Maya · Oct 1, 14:00 UTC) to Test fix 1. on ticket J77. Recording an owner, an action, and a deadline is essential governance, but Planned is not patched and Fix: not deployed. Now switch to the alternate variant where production Runs B41 · D41: even though SB42 exists in the repository, B42 evidence cannot establish B41 conditions: unknown, leaving Risk still unresolved until the team retrieves Get SB41 + evidence.
COMPARE THE BUILD RECORDS
SBOM: inventory, then evidence
Which build does this inventory describe? Compare evidence before making the call.
SB42 describes B42. Chronos Hub directly includes hub-core, which includes parse-lite. The running build is a separate record.
More about this step
SB42 keeps B42/D42, hub-core 2.3.0 and nested parse-lite 1.4.0. The advisory and deployment comparison and owner call are pending.
Chapter 1 of 6
Synthetic records, not a live scanner or a complete SBOM file. D42 and D41 name artifact digests; they are not hash bytes. AD17 has no real CVE or KEV lookup. Unknown exploit evidence does not mean safe. An owner plan is not an installed or verified fix.
Read all chapters
Nothing plays on its own. Watch all runs one overview. Replay this step stops on the selected chapter; Pause and Resume keep your place. Scrub or choose a chapter to inspect. Opening detail, leaving the picture, or hiding the tab pauses playback. Reduced motion shows still chapters with no travel.
Build matches
- SB42 describes B42. Chronos Hub directly includes hub-core, which includes parse-lite. The running build is a separate record.SB42 keeps B42/D42, hub-core 2.3.0 and nested parse-lite 1.4.0. The advisory and deployment comparison and owner call are pending.
- AD17 names parse-lite versions 1.0.0 to 1.4.9. Its identity and range match the SB42 entry for 1.4.0.The supplier identity matches; 1.4.0 falls inside AD17’s 1.0.0 to 1.4.9 range. Fix 1.5.0 is available, not deployed.
- The deployment record is B42/D42. Both the build and artifact digest match SB42; this inventory belongs to the running artifact.Running B42/D42 matches inventory B42/D42. This binds the recorded components to this artifact, not to every deployment.
- Evidence E9 for B42 confirms legacy parsing accepts untrusted input, the conditions in AD17. Exploit evidence remains unknown.E9 for B42 confirms the advisory conditions in this fixture. Exploit evidence remains unknown, without a safe or wait verdict.
- Checkout is critical. Maya records a plan to test the 1.5.0 fix by Oct 1, 14:00 UTC, even with exploit evidence unknown.Owner Maya, record DEC9: test fix 1.5.0; due Oct 1, 14:00 UTC. Running B42 and parse-lite 1.4.0 stay unchanged.
- B42 is still running parse-lite 1.4.0. A planned test of 1.5.0 has not installed or verified the fix.Build matches: evidence supports investigating and testing a fix. DEC9 is a plan; the running component is still 1.4.0.
Different build
- SB42 describes B42. Chronos Hub directly includes hub-core, which includes parse-lite. The running build is a separate record.SB42 keeps B42/D42, hub-core 2.3.0 and nested parse-lite 1.4.0. The advisory and deployment comparison and owner call are pending.
- AD17 names parse-lite versions 1.0.0 to 1.4.9. Its identity and range match the SB42 entry for 1.4.0.The supplier identity matches; 1.4.0 falls inside AD17’s 1.0.0 to 1.4.9 range. Fix 1.5.0 is available, not deployed.
- The deployment record is B41/D41. SB42 describes B42/D42, so its component list cannot establish what runs here.Running B41/D41 differs from inventory B42/D42. The B42 inventory stays valid for B42; B41 components remain unknown.
- E9 tested B42, not the running B41. B41 applicability stays unknown. Missing exploit evidence gives no all-clear.E9’s B42 conditions cannot establish B41 applicability. Unknown exploit evidence is retained, not painted as safe.
- Maya requests SB41 and matching condition evidence by Oct 1, 14:00 UTC. Checkout matters; the risk remains unresolved.Owner Maya, record DEC9: request SB41 and matching evidence; due Oct 1, 14:00 UTC. Running B41 is unchanged and risk is unresolved.
- B41 is still running. The owner has requested evidence, not declared safety or deployed a fix.Different build: inventory and version match remain valid for B42. Running B41 still needs its own inventory and condition evidence.
Show as a table
SB42 lists components for B42/D42. Match the advisory identity and version range, then bind the inventory to the running artifact. E9 and DEC9 are separate evidence and decision records. A different running build needs its own evidence. Neither path installs a fix.
| Record or check | Evidence in this example | What remains open |
|---|---|---|
| Inventory SB42 | Author Chronos Hub build job J77 assembled SB42 on 2026-09-30 at 09:00 UTC for build B42, artifact digest reference D42. | This is a selected teaching inventory, not a complete conforming SBOM or proof that every component was discovered. |
| Component identity | Supplier Chronos Hub: hub-core 2.3.0, component reference P44. Supplier ParseWorks: parse-lite 1.4.0, reference P45. These are namespaced fictional identities in SB42. | A name or a document-local reference alone cannot resolve every real package ecosystem; reconcile supplier and unique identifiers with the advisory. |
| Dependency relationships | B42 directly includes hub-core P44. hub-core P44 includes parse-lite P45, so parse-lite is a transitive dependency of B42. | Listed or nested does not by itself prove that vulnerable code executes or that runtime configuration enables it. |
| Supplier advisory AD17 | The fictional ParseWorks advisory affects parse-lite versions 1.0.0 through 1.4.9 inclusive, with a fix in 1.5.0. SB42 lists the same supplier/component at 1.4.0. | The advisory requires legacy parsing enabled and untrusted input reaching that parser. Version matching is a candidate, not a complete risk decision. |
| Artifact binding | A separate deployment record identifies checkout-prod as B42/D42 in Build matches, or B41/D41 in Different build. Both build and digest references are compared. | D42 and D41 stand for already-recorded artifact digests, not live hash checks. This lesson assumes the records are credible; obtain and validate trustworthy records in practice. |
| Conditions and scope E9 | Synthetic evidence E9 for B42 confirms legacy parsing enabled and a controlled test of untrusted input reaching the parser. It is scoped to B42/D42. | E9 does not establish B41 conditions. B41 needs matching inventory and evidence. No production exploit is run by this animation. |
| Exploit evidence | Exploit evidence is unknown on both paths. AD17 is fictional and has no assigned CVE or live KEV result. | Unknown or absent KEV evidence is not an all-clear and does not automatically mean Watch. Relevant exploitation evidence is one prioritization input. |
| Business context and ownership | The separate asset record identifies checkout-prod as critical to checkout and assigns Maya as its owner. The SBOM does not supply this operational judgment. | Organizations consider exposure, impact, available mitigations, constraints, and policy. These checks illustrate one assessment, not a mandatory universal sequence. |
| Decision DEC9: Build matches | Maya records testing parse-lite 1.5.0 by 2026-10-01 at 14:00 UTC, based on B42 applicability and critical checkout. Unknown exploit evidence is retained. | The plan has not changed B42 or installed 1.5.0. Acquire, test, deploy and verify the fix, or document another supported response. |
| Decision DEC9: Different build | Maya requests SB41 and condition evidence for B41/D41 by the same deadline. The B42 inventory and advisory match remain valid for B42. | Risk on B41 remains unresolved. Requesting evidence neither proves safety nor replaces any urgent containment required by the situation. |
| Outcome and continuing inventory | Build matches still runs B42 with parse-lite 1.4.0. Different build still runs B41 with components and applicability not established by SB42. | An SBOM file, accepted assessment, or owner decision is not remediation. Regenerate and bind the inventory when the artifact changes. |
Scene checked 2026-09-30.
Why "exploit unknown" and "ticket opened" never close the risk
Auditors and incident commanders frequently encounter two dangerous shortcuts in vulnerability management dashboards. First, teams see zero SIEM alerts for a newly announced vulnerability and mark the service "safe." In reality, Exploit evidence: unknown simply means no alert has fired yet - it does not patch the vulnerable parser.
Second, teams auto-close security findings the moment a Jira ticket (J77) or VEX note is created. Until the patched dependency (parse-) is compiled into a new digest, verified in staging, and promoted to replace the running pods in production, Fix: not deployed remains the ground truth.
CHECK YOUR JUDGMENT