DOMAIN:SUPPLY_CHAIN:SBOM¶
OWNER: julian, pol
ALSO_USED_BY: koen, victoria, ashley
UPDATED: 2026-03-26
SCOPE: Software Bill of Materials for all projects and client deliverables
OVERVIEW¶
An SBOM is a formal record of all components in a software product.
EU CRA mandates SBOM for products with digital elements from Dec 2027.
NIS2 mandates supply chain security (not SBOM explicitly) for regulated entities.
SBOMs are becoming a baseline requirement for enterprise software sales.
STANDARDS¶
CycloneDX (OWASP / ECMA)¶
FOCUS: security — native VEX support, vulnerability correlation, licence, services
FORMAT: JSON, XML, Protobuf
CURRENT_VERSION: 1.6 (ratified as ECMA-424, Jun 2024)
MINIMUM_FOR_CRA: CycloneDX 1.6+ (per BSI TR-03183-2 v2.1.0, Aug 2025)
TOOL_SUPPORT: broad — Syft, Trivy, cdxgen, GitLab all output natively
RECOMMENDATION: preferred for CRA compliance and security use cases
SPDX (Linux Foundation / ISO)¶
FOCUS: licence compliance — comprehensive licence expression language
FORMAT: JSON, RDF, tag-value, XML
CURRENT_VERSION: 3.0.1
MINIMUM_FOR_CRA: SPDX 3.0.1+ (per BSI TR-03183-2)
TOOL_SUPPORT: limited for 3.0.1 — only Microsoft sbom-tool has meaningful support (early 2026)
LEGACY: most tools still output SPDX 2.3, which does NOT meet BSI TR-03183-2 threshold
RECOMMENDATION: use for licence compliance if required; prefer CycloneDX for security
FORMAT INTEROPERABILITY¶
TOOLS: OpenSSF Protobom and BomCTL enable lossless translation between formats
STRATEGY: generate CycloneDX as primary, convert to SPDX if client requires it
BSI TR-03183-2 (v2.1.0, Aug 2025)¶
WHAT: German Federal Office for Information Security (BSI) guidance for CRA SBOM
STATUS: non-binding formally, but closest to a technical standard until CEN/CENELEC harmonised standards
MINIMUM_FORMATS: CycloneDX 1.6+ or SPDX 3.0.1+ in JSON or XML
CONTENT: defines required fields, minimum metadata, update cadence
GENERATION TOOLS¶
syft (Anchore)¶
TYPE: multi-ecosystem SBOM generator
SUPPORTS: npm, pip, Go, Java, .NET, container images, file systems
OUTPUT: CycloneDX and SPDX
USAGE: syft <source> -o cyclonedx-json > sbom.json
CI_INTEGRATION: GitHub Actions, GitLab CI, Jenkins
RECOMMENDED_FOR: primary SBOM generation in CI/CD
trivy (Aqua Security)¶
TYPE: comprehensive scanner — SBOM generation is one feature
SUPPORTS: container images, file systems, git repos, k8s
OUTPUT: CycloneDX and SPDX
BONUS: combined SBOM + vulnerability scanning in single tool
USAGE: trivy image --format cyclonedx -o sbom.json <image>
NOTE: Trivy was compromised in Mar 2026 supply chain attack — verify version and provenance
npm sbom (npm 9+)¶
TYPE: built-in SBOM generation for Node.js projects
OUTPUT: CycloneDX or SPDX
USAGE: npm sbom --sbom-format cyclonedx
LIMITATION: npm ecosystem only — not usable for container-level SBOM
USEFUL_FOR: application-layer SBOM alongside container-layer SBOM from syft/trivy
cdxgen (CycloneDX generator)¶
TYPE: specialised CycloneDX generator
SUPPORTS: npm, pip, Go, Java, .NET, Rust, PHP, Swift
OUTPUT: CycloneDX (native)
STRENGTH: deep ecosystem support, good transitive dependency detection
SBOM LIFECYCLE¶
GENERATION¶
WHEN: at every build (CI/CD pipeline)
SCOPE: application dependencies + container base image + system packages
FORMAT: CycloneDX 1.6 JSON (primary)
STORAGE: alongside build artifacts — same registry/storage as container image
ENRICHMENT¶
AFTER generation, enrich SBOM with:
- vulnerability data (link to VEX — see vulnerability-management.md)
- licence information (verify completeness)
- supplier information (map to known CPE/PURL identifiers)
- build provenance (link to SLSA attestation — see provenance.md)
DISTRIBUTION¶
TO_CLIENTS: provide SBOM as part of deliverable (CRA requirement from 2027)
TO_AUTHORITIES: available on request to market surveillance authorities
FORMAT: machine-readable (JSON/XML), not PDF
DELIVERY: alongside software release, not as afterthought
MONITORING¶
CONTINUOUS: match SBOM components against vulnerability databases
TOOLS: Grype (Anchore), trivy, Snyk, Dependabot
FREQUENCY: at least daily for production systems
ALERT: new CVE affecting SBOM component → trigger assessment
UPDATE¶
TRIGGER: any dependency change, any new build
VERSIONED: SBOM version tracks software version
RETAINED: for product lifetime or minimum 10 years (CRA Art. 13(13))
ARCHIVE: immutable storage for historical SBOMs
CONSUMER vs PRODUCER RESPONSIBILITIES¶
SBOM PRODUCER (GE / client as software supplier)¶
MUST: generate accurate, complete SBOM at each release
MUST: include all components (direct + transitive dependencies)
MUST: update SBOM when vulnerabilities discovered
MUST: retain SBOM for 10 years or product support lifetime (whichever longer)
MUST: make available to market surveillance authorities on request
SBOM CONSUMER (client's clients, enterprise buyers)¶
SHOULD: validate SBOM completeness upon receipt
SHOULD: monitor SBOM components against vulnerability databases
SHOULD: verify SBOM matches actual deployed software
SHOULD: incorporate SBOM data into their own risk management
CRA SBOM REQUIREMENTS (from Dec 11, 2027)¶
WHAT CRA REQUIRES¶
- SBOM mandatory for "products with digital elements" placed on EU market
- includes software (standalone software, embedded software, firmware)
- must contain: component name, version, supplier, known vulnerabilities
- must be current throughout product lifetime (minimum 5 years)
- available to market surveillance authorities on request
WHAT CRA DOES NOT REQUIRE¶
- SBOM does NOT need to be public (only to authorities on request)
- SBOM must NOT contain vulnerability information — use VEX/CSAF separately
- no specific format mandated (but "commonly used and machine-readable" required)
- no specific tool mandated
CRA vs NIS2¶
CRA: product-level — SBOM for the software you build
NIS2: organisation-level — supply chain security for your operations
BOTH may apply to same entity from different angles
STANDARDISATION TIMELINE¶
APR 2025: CRA Standardisation Request accepted by CEN, CENELEC, ETSI
MID-2026: CEN/CENELEC PT3 European standard expected
OCT 2026: product-specific standards targeted for publication
DEC 2027: full CRA compliance required
PENALTIES¶
NON_COMPLIANCE: up to EUR 15M or 2.5% global annual turnover
MARKET_SURVEILLANCE: authorities can withdraw non-compliant products from market
CI/CD INTEGRATION¶
RECOMMENDED PIPELINE¶
1. BUILD: compile/bundle application
2. SBOM_GENERATE: syft or cdxgen → CycloneDX 1.6 JSON
3. SBOM_SCAN: grype or trivy → check against vulnerability databases
4. SBOM_SIGN: cosign → sign SBOM alongside container image
5. SBOM_STORE: push to OCI registry alongside image
6. SBOM_VERIFY: verify signature at deploy time
GITHUB ACTIONS EXAMPLE¶
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
format: cyclonedx-json
output-file: sbom.cyclonedx.json
- name: Scan SBOM
uses: anchore/scan-action@v4
with:
sbom: sbom.cyclonedx.json
fail-build: true
severity-cutoff: high
QUALITY GATES¶
FAIL_BUILD_IF: critical or high vulnerability with known exploit (KEV-listed)
WARN_IF: high vulnerability without known exploit
REPORT: all vulnerabilities in SBOM scan results
EXCEPTION: documented risk acceptance for false positives or non-reachable vulns
SBOM COMPLETENESS¶
WHAT MUST BE INCLUDED¶
CHECK: all direct dependencies (package.json, requirements.txt, go.mod, etc.)
CHECK: all transitive dependencies (full dependency tree)
CHECK: container base image and its packages
CHECK: system libraries (if deployed as container or binary)
CHECK: build tools (if they end up in production artifact)
CHECK: vendored/bundled dependencies (not just package-managed ones)
COMMON GAPS¶
TRAP: SBOM generated from lock file only — misses system packages in container.
TRAP: container-level SBOM misses application dependencies (need both layers).
TRAP: vendored code (copied into repo) not detected by package manager tools.
TRAP: native extensions (e.g., node-gyp bindings) not captured.
TRAP: SBOM generated at wrong stage — pre-build vs post-build differences.
RECOMMENDATION: generate at container image level (syft/trivy on final image) for most complete SBOM.
READ_ALSO: domains/supply-chain/index.md, domains/supply-chain/dependency-management.md, domains/supply-chain/vulnerability-management.md