Sbom Management

SBOM management

A software bill of materials (SBOM) is the ingredient list for what you shipped. Without one, the day a critical advisory lands you are grepping lockfiles across repos and guessing what is actually deployed. Generated right and kept current, an SBOM turns that scramble into a query.

Method

1. Generate from the built artifact, not the source tree. Run syft against the final container image or binary: syft my-image:1.4 -o cyclonedx-json. Scanning source misses vendored code, build-time injections, and base-image packages, so the SBOM must describe what actually left the build.
2. Pick one format and hold it. CycloneDX and SPDX are both machine readable; CycloneDX carries dependency graph and VEX in one document, SPDX is common for license and compliance work. Convert on demand with cyclonedx-cli convert rather than maintaining two source formats.
3. Include the NTIA minimum elements. Every component needs supplier, name, version, a unique identifier (a PURL like pkg:npm/lodash@4.17.21 or a CPE), dependency relationships, plus author and timestamp. An SBOM with no PURLs cannot be matched to an advisory feed and is decoration.
4. Sign the SBOM and bind it to the artifact digest. Attach it as an attestation with cosign attest --predicate sbom.json --type cyclonedx so a consumer can confirm the SBOM belongs to that exact image and was not swapped. An unsigned SBOM is a claim, not evidence.
5. Consume continuously, not once. Feed stored SBOMs to grype sbom:./sbom.json or load them into Dependency-Track, which re-evaluates every stored SBOM as new CVEs arrive. The point is that a fresh advisory flags an old release without anyone rebuilding it.
6. Emit VEX to kill the false positives. Publish an OpenVEX or CycloneDX VEX statement marking unreachable findings not_affected with a justification like vulnerable_code_not_in_execute_path, so consumers and your own dashboard stop paging on a CVE you already triaged.
7. Track coverage and freshness. Require an SBOM for every deployed artifact and regenerate it each release. A stale SBOM from three releases back answers "are we affected" confidently and wrongly.

Checks

• Can you list every running service that contains log4j-core 2.14 from stored SBOMs in minutes, without rebuilding anything?
• Does each release ship a signed SBOM whose component set matches what the image actually contains?
• When a new CVE publishes, does something re-scan existing SBOMs automatically, or only the next build?

Boundaries

This skill covers producing and consuming the inventory. Hardening the pipeline that builds and signs artifacts belongs to supply-chain-defense, and gating or removing an individual risky package belongs to dependency-auditing. Format mandates from a specific regulator defer to that program's own requirements.