CycloneDX 1.7 and SPDX 3.0 now anchor modern SBOM programs. Use this DevSecOps 2026 cheat sheet to automate generation, VEX, and fixes. Read now.
Pick One Format, Then Standardize Generation
CycloneDX 1.7 and SPDX 3.0 are the two formats that now anchor modern SBOM programs. Both describe components, dependencies, licenses, and provenance so security and compliance tools can consume the same inventory. You do not need both in every pipeline. Choose the format your scanners, registries, and customer contracts already expect, document that choice, and generate it the same way for every build artifact.
Automate generation at build time, not as a manual export after release. Hook your package manager or container build so each image, library, and service binary gets an SBOM as a first-class build output. Store it next to the artifact, sign it if you already sign releases, and treat a missing SBOM as a failed quality gate. That habit matters more than which of the two formats you picked on day one.
Use VEX to Separate Real Risk From Noise
An SBOM lists what is present. VEX states whether a known vulnerability in that inventory actually affects your product and why. Without VEX, every match against a vulnerability database becomes a ticket—even when the vulnerable code path is unused, the feature is disabled, or you already ship a fixed configuration. With VEX, triage becomes a decision record: affected, not affected, fixed, or under investigation, plus a short justification someone can audit later.
Keep VEX close to the SBOM and update both when the product changes. Generate VEX from the same pipeline that builds and tests the release so status tracks the exact version customers run. Prefer machine-readable status over free-text ticket comments; tools can then suppress false positives and escalate only confirmed exposure.
Remediation Loop: Prioritize, Patch, Prove
Remediation works best as a short, repeatable loop rather than a one-off scramble. Start from confirmed-affected findings (SBOM + VEX), not from raw scanner volume. Prefer upgrading the direct dependency when a fixed version exists; if you must stay on a major line, pin a patched minor and re-scan. For containers, rebuild from a current base and regenerate the SBOM so the inventory and the binary stay aligned.
- Rank by exploitability and blast radius: internet-facing services and privileged components first.
- Fix at the earliest controlled layer: your app deps before inherited base images when both are options.
- Re-run generation and VEX after the fix so “fixed” is proven in artifacts, not only in a ticket.
- Record residual risk when a fix is delayed—who accepted it, until when, and what compensating control applies.
DevSecOps 2026 Cheat Sheet Checklist
Wire SBOM generation into CI for every release candidate. Emit CycloneDX 1.7 or SPDX 3.0 consistently, attach VEX for known CVEs that touch your inventory, and fail the pipeline when generation or signing steps fail. Publish SBOMs where operators and customers can retrieve them without a support thread. Feed confirmed-affected items into the same backlog you use for production defects so fixes compete fairly with features.
Review the loop quarterly: which components still lack owners, which VEX statuses are stale, and which base images drag in avoidable noise. A useful SBOM program is not a one-time export—it is automated generation, honest VEX, and remediation that leaves evidence in the next build.