SBOM Standards & Remediation Cheat Sheet [DevSecOps 2026]

SBOM work in 2026 is less about producing one file and more about wiring standards, attestations, and fix loops into CI. The reference set has stabilized around CycloneDX 1.7, SPDX 3.0, and VEX documents for “affected or not affected” decisions, while tooling now expects machine-readable JSON, signed artifacts, and automated re-locking. Use this cheat sheet to choose the right format, memorize the commands, and operationalize remediation without turning every build into a manual security review.

Standards Map

As of May 13, 2026, the safest baseline is straightforward: use CycloneDX for broad tooling interoperability, keep SPDX for exchange and policy-heavy environments, and layer VEX on top for exploitability decisions.

What changed recently

• CycloneDX 1.7 is the current spec version and its official predicate type is https://cyclonedx.org/bom.
• SPDX 3.0 is the current SPDX specification listed by SPDX.
• CISA’s 2025 draft minimum elements add component hash, license, tool name, and generation context.
• The September 3, 2025 CISA/NSA/international guidance pushes harmonized, automated SBOM use across borders.

Format chooser

• Choose CycloneDX JSON when your pipeline centers on application security, OCI workflows, and rich dependency relationships.
• Choose SPDX JSON when downstream consumers care about procurement, licensing, or existing SPDX-based policy engines.
• Emit both when you have mixed consumers and want to avoid format conversion in the hot path.
• Use VEX to express exploitability and product impact, not to replace the SBOM itself.

Live Search Filter

Type B reference pages benefit from instant filtering. The snippet below wires an input box to any command card that exposes searchable text through a data-cmd attribute, and adds fast keys for focus and reset.

<input id="sbom-filter" type="search" placeholder="Filter commands, flags, formats..." />

<script>
const input = document.getElementById('sbom-filter');
const cards = [...document.querySelectorAll('[data-cmd]')];

function applyFilter(value) {
  const q = value.trim().toLowerCase();
  for (const card of cards) {
    const haystack = (card.dataset.cmd || '').toLowerCase();
    card.hidden = q ? !haystack.includes(q) : false;
  }
}

input?.addEventListener('input', (e) => applyFilter(e.target.value));

document.addEventListener('keydown', (e) => {
  if (e.key === '/' && document.activeElement !== input) {
    e.preventDefault();
    input?.focus();
  }
  if (e.key === 'Escape' && document.activeElement === input) {
    input.value = '';
    applyFilter('');
    input.blur();
  }
});
</script>

Use stable tokens in data-cmd such as tool name, format, language, and key flags. For example: data-cmd='syft cyclonedx spdx image filesystem --scope all-layers'.

Keyboard Shortcuts

These shortcuts keep a long cheat sheet usable on laptops and during incident triage.

Commands by Purpose

Generate SBOMs

• Syft is the practical default for container images and filesystems.
• cdxgen is useful for recursive monorepos, Git URLs, and CycloneDX-centric workflows.
• Emit machine formats first; human tables are secondary.

# Syft: emit both standards in one run
syft alpine:latest \
  -o table \
  -o spdx-json=alpine.spdx.json \
  -o cyclonedx-json=alpine.cdx.json

# Syft: include all image layers
syft <image> --scope all-layers

# cdxgen: current repo
cdxgen -o bom.json .

# cdxgen: recursive monorepo scan
cdxgen -r -o bom.json

# cdxgen: force an older spec version for compatibility
cdxgen -r -o bom.json --spec-version 1.6

Scan existing SBOMs

• Trivy scans SBOM files directly for vulnerabilities and licenses.
• OSV-Scanner can scan source trees, lockfiles, and recognized SBOM filenames.
• Prefer SBOM scanning when build agents cannot reproduce the original environment.

# Trivy: scan an SBOM file
trivy sbom /path/to/sbom_file

# Trivy: scan only licenses
trivy sbom --scanners license /path/to/sbom_file

# OSV-Scanner: scan a source tree recursively
osv-scanner scan source -r ./my-project-dir/

# OSV-Scanner: scan a specific SBOM
osv-scanner scan source -L /path/to/your/sbom.spdx.json

# OSV-Scanner: JSON output
osv-scanner scan -L package-lock.json --format json

Sign and attest outputs

• Use Cosign for blob signing when the SBOM is distributed as a file.
• Use Cosign attest when the SBOM must travel with a container image and be enforced in policy.
• Prefer attestations over legacy SBOM attachments for new workflows.

# Sign an SBOM file as a blob
cosign sign-blob sbom.spdx.json --bundle sbom.sigstore.json

# Verify the signed SBOM blob
cosign verify-blob sbom.spdx.json \
  --bundle sbom.sigstore.json \
  --certificate-identity=name@example.com \
  --certificate-oidc-issuer=https://accounts.example.com

# Attach an SPDX SBOM attestation to an image
cosign attest --yes --type https://spdx.dev/Document \
  --predicate sbom.spdx.json \
  --key cosign.key \
  ${IMAGE}

Fix and re-lock dependencies

• OSV-Scanner fix is designed to produce a small number of actionable remediation paths.
• Its guided remediation flow can edit manifests and lockfiles.
• Run it only on trusted repositories because package manager execution can have side effects.

# Guided remediation for npm-style manifests
osv-scanner fix -M path/to/package.json -L path/to/package-lock.json

# Save scan output to a file before remediation
osv-scanner scan -L package-lock.json --output-file scan-results.txt

Configuration

Put defaults in config so your CI commands stay short and reproducible. Keep policy in version control, not in shell history.

Syft

# .syft.yaml
output:
  - "cyclonedx-json=sbom.cdx.json"
  - "spdx-json=sbom.spdx.json"
scope: "squashed"

Trivy

# trivy.yaml
format: "table"
severity:
  - HIGH
  - CRITICAL
scan:
  scanners:
    - vuln
    - secret
  skip-dirs: []
vulnerability:
  ignore-unfixed: true

OSV-Scanner

# osv-scanner.toml
[[IgnoredVulns]]
id = "GO-2022-0968"
reason = "Documented and accepted in this runtime profile"

[[PackageOverrides]]
name = "axios"
ecosystem = "npm"
group = "dev"
ignore = true
reason = "Dev-only package excluded from production artifact"

If you share SBOMs outside your engineering boundary, scrub usernames, internal paths, hostnames, or accidental secrets first. That is exactly the kind of cleanup a security team can do quickly with TechBytes’ Data Masking Tool.

Advanced Usage

Recommended automated remediation workflow

1. Generate the SBOM during build, not after deployment.
2. Store the SBOM next to the build artifact and sign or attest it immediately.
3. Scan the SBOM, not just the source tree, so downstream consumers can reproduce results.
4. Use VEX for “not affected” decisions instead of piling up local ignore rules.
5. When a fix is accepted, re-lock, rebuild, regenerate SBOMs, and re-attest the image.

# 1) Generate SPDX and CycloneDX
syft ${IMAGE} \
  -o spdx-json=sbom.spdx.json \
  -o cyclonedx-json=sbom.cdx.json

# 2) Scan the SBOM
trivy sbom sbom.spdx.json

# 3) Run guided remediation where applicable
osv-scanner fix -M package.json -L package-lock.json

# 4) Rebuild image, regenerate SBOM, then attest
cosign attest --yes --type https://spdx.dev/Document \
  --predicate sbom.spdx.json \
  --key cosign.key \
  ${IMAGE}

VEX-aware triage

• Use VEX when the vulnerable component is present but the product is not affected, fixed, or otherwise non-exploitable in your shipping context.
• Keep VEX as a separate decision artifact so you can update impact status without regenerating the full SBOM.
• Trivy’s configuration surface includes --vex and vulnerability.vex, which is the direction mature pipelines are moving.

Interoperability notes that save time

• OSV-Scanner auto-detects recognized SBOM filenames such as bom.json, *.cdx.json, and *.spdx.json.
• Trivy’s docs explicitly note that CycloneDX XML is not supported as SBOM input; prefer JSON for portable automation.
• When you need a broad compatibility floor, cdxgen --spec-version 1.6 is often easier than debugging an older downstream parser.
• Use SPDX for attestation examples and procurement flows, and CycloneDX for rich appsec pipelines and ecosystem tooling.