sbom

23 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

SBOM generation timing and placement

Generate SBOMs during the build process, after dependency resolution but before packaging. This captures exact resolved dependencies and metadata. Do not generate SBOMs ad-hoc outside the build pipeline.

Standard SBOM formats to use

Use CycloneDX or SPDX as the standard formats for SBOMs. CycloneDX is lightweight and widely supported in SCA tools and Dependency-Track. SPDX is rich and common in compliance and legal workflows. Publish at least one machine-readable SBOM per release.

Minimum SBOM elements to capture

Capture at minimum: (1) Component name and version (canonicalized), (2) Unique package identifiers (purl/package URL) where available, (3) Package type/ecosystem (npm, maven, pypi, deb, rpm, apk, OS image), (4) Checksum(s) with SHA256 preferred of the package or artifact, (5) Component supplier/origin (URL or VCS) where known, (6) License information if available, (7) Timestamps (generation time) and build identifiers (CI run ID), (8) Relationship edges showing direct vs transitive dependency, (9) SBOM generator metadata including tool, version, and command.

Sign and attest SBOMs to artifacts

Use Cosign, Sigstore, or in-toto to sign both the artifact and SBOM in the same CI job. This binds the SBOM to the built artifact to prevent tampering and proves they come from the same trusted build. Unsigned SBOMs can be forged.

SBOM generation tools

Use Syft, CycloneDX CLI, SPDX tools, or ecosystem-specific exporters to generate SBOMs. Run these in the build container or CI agent. Configure the build to fail if SBOM generation fails.

Syft command to generate SPDX JSON SBOM

Run the command: syft packages dir:. -o spdx-json > sbom-spdx.json

CycloneDX CLI command to generate BOM from artifact

Run the command: cyclonedx-bom -o bom.xml --input-pkg target/my-app.jar

SBOM generation points in software lifecycle

Generate SBOMs at multiple points: (1) During build (after dependency resolution, before packaging) for exact versions and metadata, (2) Local/dev for early validation on a best-effort basis, (3) At container image build-time and during image scans to catch injected content, (4) At runtime/deployment via telemetry to validate what executes in production.

Tools for SBOM signing and attestation

Use Cosign, Sigstore, or in-toto to sign and attest SBOMs. These tools bind the SBOM to the artifact and provide provenance evidence.

Tools for SBOM vulnerability scanning and enrichment

Use tools such as Grype, OSS Index, Snyk, or commercial vulnerability feeds to map CVEs to SBOM components and enrich SBOMs with vulnerability data.

SBOM storage and management systems

Store and analyze SBOMs in Dependency-Track, dedicated SBOM managers, or registries with SBOM support. Centralize SBOMs for management at scale.

Version and retain SBOMs for audit and incident response

Version and store SBOMs in a trusted artifact store or SBOM management system like Dependency-Track. Retain historical SBOMs like code for audit trails and incident response.

VEX document usage for vulnerability exploitability

Use Vulnerability Exploitability eXchange (VEX) documents to determine whether a known vulnerability actually affects a given product or component, and under what conditions. Suppliers or tooling may provide VEX documents indicating if a CVE is relevant, non-exploitable, or has available mitigations.

Vulnerability triage workflow using SBOM

Map CVE to SBOM component(s) to see direct vs transitive exposure. Use VEX to understand exploitability. Prioritize direct dependencies and high-severity runtime libraries. Patch, upgrade, isolate, or apply runtime controls as needed. Track issues in the system with SBOM and VEX evidence (component, version, digest, exploitability status). Verify by regenerating SBOM to confirm the vulnerable component is removed.

Handling transitive dependencies in vulnerability management

Visualize transitive dependencies with dependency graphs to show why a vulnerable package is included. Prefer explicit direct upgrades where possible (bump direct dependency to a version that pulls a fixed transitive release). Consider mitigation patterns such as dependency replacement, patching if legal and feasible, or runtime limitations. For long-lived third-party binaries, include policy to monitor and re-evaluate older dependencies that receive no updates.

SBOM common pitfalls and how to avoid them

Pitfalls and solutions: (1) Incomplete generation — generate SBOM in build after dependency resolution. (2) Missing metadata — always include timestamps, checksums, and tool info. (3) Inconsistent formats — stick to SPDX/CycloneDX and use extensions sparingly. (4) Unsigned SBOMs with no provenance — sign and attest artifacts. (5) No versioning or archival — retain historical SBOMs for audit and incident response.

SBOM policy minimum elements

A minimum SBOM policy should define: (1) Required formats (CycloneDX vX or SPDX vY) and acceptable alternates, (2) Required fields (see minimum elements list), (3) Where to store (artifact registry, SBOM manager) and retention policy, (4) Signing and attestation requirement (e.g., all public releases must be signed), (5) SLA for vulnerability response based on severity and impact, (6) Supplier SBOM acceptance rules (e.g., third-party vendors must supply SBOMs in a supported spec), (7) Access controls for SBOMs containing sensitive metadata to avoid leaking internal repository URLs.

GitHub Actions SBOM generation workflow example

Example workflow steps: (1) Checkout code with actions/checkout@v4, (2) Build with ./gradlew assemble, (3) Generate SBOM with syft packages dir:./build/libs -o cyclonedx-json > sbom.json, (4) Upload SBOM as artifact with actions/upload-artifact@v4, (5) Sign artifact and SBOM with cosign using cosign sign --key secret and cosign sign-blob --key secret --output-signature sbom.json.sig sbom.json, (6) Push image with ./push-image.sh.

CI/CD SBOM generation fail-fast strategy

In CI pipelines, fail the build if SBOM generation fails. However, avoid failing builds on non-actionable low-severity vulnerability findings. Instead, surface vulnerability results to triage dashboards for review.

Supplier SBOM intake workflow

Vendor provides signed SBOM to your organization. Ingest SBOM into Dependency-Track or similar management system. Auto-enrich with vulnerability data. If critical CVE is found, create ticket and notify procurement and security teams.

Internal release SBOM workflow

CI builds artifact and generates SBOM. Sign both and push to registry. SBOM is ingested to Dependency-Track. Scheduled scan enriches with vulnerability and license data. Policy engine flags high-severity vulnerabilities or forbidden licenses. Create PR or issue to remediate.

Normalize and deduplicate package IDs across SBOM suppliers

When managing SBOMs at scale, normalize and deduplicate package identifiers (purl) across different suppliers to create a unified view of dependencies.

Enrich SBOMs with vulnerability, license, and policy data

Automatically enrich SBOMs with vulnerability information, license data, and apply organizational policies for automated triage and decision-making.

Give your agent this brain