SBOMs in 2026: revisit Syft, cdxgen and Dependency-Track before you hand another customer an SBOM nobody tracks

Many product teams have lived this week. A large customer’s security questionnaire asks for “an SBOM for the current release”. Someone runs a tool on the release branch and emails a few megabytes of JSON. Three months later a serious advisory lands for a common library, and the same customer asks: “Are you affected, and in which versions?” Nobody can answer quickly, because the SBOM was a one-time attachment, never stored against a version and never read again.

Producing an SBOM takes one command. The hard part is treating it as a living record: generated the same way on every build, stored against the exact version that shipped, checked again as new vulnerabilities appear, and shared with a clear statement of what affects your product.

This post revisits three open-source tools that cover that whole path: Syft from Anchore and cdxgen from OWASP for producing SBOMs, and OWASP Dependency-Track for storing them and tracking them over time. Vulnerability scanners come up only as contrast. The site already has a separate comparison of Trivy, Grype and OSV-Scanner.

The short version

  • Syft: Apache-2.0 licence, built and sponsored by Anchore. A Go CLI and library that catalogues packages in container images, directories, files and archives, and writes SPDX, CycloneDX or its own Syft JSON. Best fit when you want one fast, predictable generator for images and file systems, especially if Grype is already in your pipeline.
  • cdxgen: Apache-2.0 licence, now an OWASP project in its own cdxgen GitHub organisation (it lived under the CycloneDX organisation before December 2025). A Node.js CLI, library and server that builds CycloneDX BOMs from source code, lock files and container images, with SPDX 3.0.1 export. Best fit for polyglot source repositories where you want dependency trees, evidence and extra BOM types such as CBOM or AI-BOM.
  • Dependency-Track: Apache-2.0 licence, an OWASP project. A server platform that ingests CycloneDX SBOMs per project version, matches components against vulnerability sources on a schedule, applies policies and exports VEX and VDR documents. Best fit when you need a system of record for all your SBOMs, not one more file in an artefact store.

What job is actually being done

“Do SBOMs” hides five separate jobs.

  • Produce. Generate an SBOM for each build from the right input. A source tree, a lock file and a final image can give different answers.
  • Choose a format. SPDX or CycloneDX, decided by your consumers and tools.
  • Store. Keep each SBOM tied to the exact version, commit and image digest that shipped, for as long as you support that version.
  • Track. Check stored SBOMs against new vulnerability data daily, not only at build time.
  • Communicate. Tell customers what actually affects them. A VEX document says “this CVE is in a component we ship, but our product is not affected, and here is why”.

A scanner in CI covers a slice of “track”, only at build time. Most real questions arrive after release.

Why this matters more in 2026

European Union: Cyber Resilience Act

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its reporting obligations under Article 14 have applied since 11 September 2026, so manufacturers must report actively exploited vulnerabilities in their products. The main obligations, including Annex I, apply from 11 December 2027. Annex I Part II asks manufacturers to identify and document the components in their products, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies. You need not publish it, but you cannot report on time without knowing which products contain the affected component.

United States: EO 14028, CISA minimum elements and OMB

Executive Order 14028 (May 2021) pushed SBOMs into US federal buying, and NTIA published the first minimum elements in July 2021. On 29 July 2026, CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials, which replaces the NTIA document. New fields include author signature, format name and version, generation context, tool name and version, component hash and component licence. Separately, OMB memo M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Agencies no longer must collect the common attestation form, but may still require a current SBOM on request, covering the runtime production environment for cloud services.

India: CERT-In technical guidelines

CERT-In has published Technical Guidelines on SBOM, with version 2.0 dated 9 July 2025 extending them to QBOM and CBOM, AIBOM and HBOM. The document lists minimum data fields for an SBOM, recommends SPDX or CycloneDX as formats, and describes VEX for communicating vulnerability status. It is aimed at the public sector, government, essential services and software exporters. Read it as guidance that such buyers may copy into procurement templates, not as a law with penalties.

SPDX or CycloneDX

Both formats are mature standards. SPDX 2.2.1 is ISO/IEC 5962:2021, and the current SPDX release is 3.0.1 (17 December 2024), with a 3.1 release candidate published in January 2026. CycloneDX 1.7 is published by Ecma as ECMA-424 second edition (December 2025), and the latest CycloneDX tag is 1.7.2 (17 September 2026).

  • SPDX has deep roots in licence compliance. CycloneDX started in security, with native structures for vulnerabilities, VEX, services and cryptographic assets.
  • Dependency-Track accepts only CycloneDX for upload. If it is your tracking platform, CycloneDX is your working format and SPDX becomes a second output from your generator.
  • Conversion between the two loses data. Syft’s own documentation recommends keeping Syft JSON as the source and converting from it, rather than chaining SPDX to CycloneDX conversions.

A small Indian example

Take a forty-engineer product company in Chennai selling a plant monitoring platform: a Java backend, a React frontend, a Python analytics service and an edge gateway image on customer sites. A German machinery maker will need CRA paperwork, and an Indian public sector utility has copied CERT-In SBOM language into its tender. Today someone runs a generator by hand before each release and saves the output to a shared drive. When a popular library gets a critical CVE, the support lead spends two days rebuilding old tags to find affected customer versions.

Syft: a fast generator for images and file systems

History and licence

Syft lives at anchore/syft on GitHub. The repository was created in May 2020 and the licence is Apache-2.0. The README says development is sponsored by Anchore, which also builds the Grype scanner. The latest release at the time of writing is v1.57.0, published on 6 November 2026 (2:16 AM IST). Recent releases are marked immutable on GitHub, and the project ships often (v1.56.0 came four days earlier).

How it works

Syft takes a target and runs a set of catalogers on it. Targets include images from Docker, Podman, containerd or a registry, OCI archives, directories, files and archives. For a multi-arch image tag, it analyses the linux/amd64 manifest by default unless you pass --platform. Output is chosen with -o, and you can write several formats in one run, for example -o spdx-json=sbom.spdx.json -o cyclonedx-json=sbom.cdx.json. Format versions can be pinned with @, such as CycloneDX 1.2 to 1.7 or SPDX JSON 2.2, 2.3 and 3.0.

Two more features matter for the full path. syft convert turns a stored SBOM into another format, and syft attest creates a signed in-toto attestation with the SBOM as the predicate, keyless through Sigstore or with your own cosign key. Both are marked experimental in the docs. For GitHub Actions, Anchore maintains anchore/sbom-action (v0.24.3, 2 October 2026, 9:05 PM IST).

Where it is strong

  • One binary, quick to add to any CI image.
  • Very good at what is inside a built image: OS packages from apk, dpkg and RPM, plus language packages and many binaries.
  • Clear format choice and version pinning, which helps when a customer asks for one exact schema version.

What to watch

  • An image SBOM shows what ended up in the image, not your full dependency tree with scopes. For source-level detail, scan the lock files or pair Syft with a source-focused tool.
  • Conversion loses data. The docs list image layers, file locations and package-manager metadata among the fields that may not survive. Keep the Syft JSON if you might need it later.
  • Attestation needs registry write access and cosign, and the feature is still experimental.

cdxgen: source-aware BOMs with evidence

History and licence

cdxgen is at cdxgen/cdxgen on GitHub, with an Apache-2.0 licence. The repository dates from December 2019. Old AppThreat/cdxgen and CycloneDX/cdxgen URLs now redirect to it. According to the project’s notice, OWASP promoted cdxgen to production project status, and the repository moved to the new cdxgen organisation in December 2025. The OWASP project page lists Prabhu Subramanian as project leader.

Two release lines are active. v13.0.0 (13 August 2026) was a major release: the npm package was renamed from @cyclonedx/cdxgen to @cdxgen/cdxgen, container images moved to ghcr.io/cdxgen, the Node.js minimum became 24, and generating CycloneDX 1.4 or 1.5 from the CLI was dropped. The latest release is v13.7.0, published on 8 November 2026 (5:08 AM IST). The 12.x line still gets fixes, most recently v12.9.1 on 6 November 2026 (10:31 AM IST).

How it works

cdxgen reads project files across many ecosystems and builds a CycloneDX JSON document, with SPDX 3.0.1 JSON-LD export through cdxgen --format spdx or cdx-convert. The default CycloneDX version is 1.7, and v13.7.0 adds a preview of CycloneDX 2.0 behind --spec-version 2.0 while that version awaits ratification. Beyond SBOMs, it produces CBOM, OBOM, SaaSBOM, AI-BOM and HBOM through separate commands. Companions include evinse for evidence and reachability, cdx-validate (v13.7.0 adds a CISA 2026 minimum elements rule set) and cdx-sign. It can run as a server and submit BOMs straight to Dependency-Track with --server-url.

Where it is strong

  • Source-level depth: dependency trees for supported manifests, scopes, and --required-only to keep only production dependencies.
  • Evidence on components, so a reviewer can see where a dependency is actually used.
  • Validation against compliance profiles before an SBOM leaves the building.
  • Newer BOM types, useful as CBOM or AIBOM requests appear.

What to watch

  • Outside secure mode, cdxgen may install packages and run the project’s own build tools to resolve dependencies. On untrusted code, use the cdxgen-secure command or the ghcr.io/cdxgen/cdxgen-secure image, which keeps installs off. The v12.9.1 notes describe four fixes for cases where a scanned repository could influence what cdxgen did, including a config file that could run commands. If you scan pull requests from forks, stay current.
  • A missing toolchain or lock file gives a thinner SBOM. --profile introspect grades completeness in CI.
  • Licence lookup from public registries is off by default and is turned on with FETCH_LICENSE=true. Without it, licence fields can be sparse.
  • The v13 rename changes package names, image paths and the tool PURL in metadata.tools. Update pipelines and any consumer that matches on the old strings.

Dependency-Track: the system of record

History and licence

Dependency-Track lives at DependencyTrack/dependency-track, Apache-2.0, an OWASP project with a repository dating from July 2013. 2026 brought its biggest change in years. v5.0.0 reached general availability on 7 June 2026 (9:02 PM IST), and the separate Hyades incubator repository is now archived. The latest releases are 5.2.1 and 4.14.6, both published on 25 October 2026 (4:43 PM and 4:41 PM IST). The README says v4 is in maintenance mode and will reach end of life in December 2026.

How it works

You create a project per application and version, and upload a CycloneDX BOM through the UI or a POST to /api/v1/bom, usually from CI with a service account. Each upload starts vulnerability analysis and policy evaluation. The upload returns a token that a later pipeline step can poll. Analysis also runs on a schedule, and the instance mirrors NVD, GitHub Advisories, OSV and EPSS data daily by default. Optional analyzers include OSS Index, Snyk and a separate Trivy server.

v5 is an extensive refactor, not a rewrite. PostgreSQL 14 or later is the only database, and background work runs on durable PostgreSQL-backed queues that resume after a crash. Policies and notification filters use CEL expressions. Component integrity checks flag hashes that differ from what the upstream registry publishes. Retention policies expire old project versions and metrics.

Where it is strong

  • It answers “which of our shipped versions contain this component?” across the whole portfolio, today, without a rebuild.
  • VEX in both directions: export your analysis decisions as CycloneDX VEX, or apply a VEX document to findings in bulk. VDR export adds services and the dependency graph.
  • Policies for licences, versions and vulnerabilities, with notifications.

What to watch

  • CycloneDX only. SPDX producers need a CycloneDX output path.
  • Moving from v4 to v5 is a manual migration. The source v4 instance must be on 4.14.2 or later and offline during the upgrade. H2, MySQL and SQL Server support is gone, v5 ships as container images only (no WAR, no bundled image), and the notification schema and parts of REST API v1 have changed. At 5.0.0 the release notes said the official Helm chart was not yet compatible, so check its current status before you plan a Kubernetes upgrade.
  • v5 removed Lucene fuzzy matching and the /mirror/nvd endpoint.
  • It is a service to run: PostgreSQL, backups, upgrades and access control. Anonymous telemetry is sent once a day by default, and the docs show how to opt out.

Side by side, without a table

  • Role. Syft and cdxgen produce SBOMs. Dependency-Track stores, tracks and communicates. They complement each other rather than compete.
  • Best input. Syft: built images and file systems. cdxgen: source trees and lock files, plus images. Dependency-Track: any CycloneDX BOM.
  • Formats. Syft: SPDX, CycloneDX and Syft JSON, with pinned versions. cdxgen: CycloneDX first, SPDX 3.0.1 export. Dependency-Track: CycloneDX in, CycloneDX BOM, VEX and VDR out.
  • Trust and integrity. Syft: in-toto attestation through cosign (experimental). cdxgen: cdx-sign and cdx-verify. Dependency-Track: component integrity checks against upstream registries.
  • Main risk. Syft: thin source context. cdxgen: running build tools on untrusted code if secure mode is off. Dependency-Track: an upgrade project in 2026 for anyone still on v4.

How to choose

  • If you ship container images and want something simple today, start with Syft on the final image, write CycloneDX and SPDX in one run, and keep the Syft JSON.
  • If most of your risk sits in application dependencies across several languages, or a customer asks for dependency trees and licences, use cdxgen on the source in secure mode, and validate the result before release.
  • If customers or regulators will ask “are you affected?”, you need a tracking platform. Dependency-Track is the open-source default, and new installs should start on v5.
  • Many teams use both generators: cdxgen for the application, Syft for the image, uploaded as separate or child projects rather than merged by hand.

For the Chennai team, a sensible setup is cdxgen on each service repository, Syft on the edge gateway image, both uploading to Dependency-Track v5 with project names and versions that match release tags. CRA and CERT-In questions then become a portfolio search plus an exported VEX, not two days of rebuilding old tags.

Common mistakes

  • One-off SBOMs. Generated by hand once a quarter and attached to an email. They are out of date before the reply arrives.
  • Wrong input. Scanning source when the customer runs the image, or the reverse, and calling it complete.
  • No version identity. Without version, commit or digest, an SBOM cannot say which release is affected.
  • Chained conversions. CycloneDX to SPDX and back, losing data at each step.
  • Treating a scanner report as an SBOM. A findings list is not an inventory.
  • Sharing raw findings instead of VEX. Customers then chase CVEs that do not affect your product.

What to start this week

  1. Pick one product and name a person who owns its SBOMs.
  2. Add SBOM generation to the release pipeline: cdxgen in secure mode on the source, Syft on the final image, with tool versions pinned.
  3. Name every SBOM with product, version and commit or image digest, and store it next to the release artefacts.
  4. Bring up Dependency-Track v5 from the quickstart in a test environment, change the default password, create a service account and upload the last three releases.
  5. Run cdx-validate against the CISA 2026 minimum elements profile and note which fields are missing, such as supplier, licence or hashes.
  6. Triage the findings for one release, record the decisions in Dependency-Track and export a VEX.

A short checklist

  • SBOMs generated automatically on every release build, not by hand.
  • Each SBOM tied to version, commit and image digest, and kept for the support period.
  • A working format chosen (CycloneDX if Dependency-Track is the platform) and conversions done from the richest source.
  • All supported versions uploaded to a tracking platform with scheduled analysis.
  • VEX decisions recorded and exportable for customers.
  • Generators run in secure or sandboxed mode on untrusted code.
  • Upgrade plan in place for any Dependency-Track v4 instance before end of life in December 2026.

No hands-on drill

No hands-on drill was run for this post, and nothing was installed or tested. The facts come from each project’s repository, licence, releases and official documentation, and from the regulator pages listed below, read on 8 November 2026, with release dates converted to IST.

Closing

The revisit is moving from a file to a habit. Learn what each tool actually sees, unlearn the idea that an SBOM is a one-time compliance attachment, re-learn the format and VEX basics, practise on one product with real release history, and apply the same pipeline across the portfolio. The goal is simple: when the next big advisory lands, you should answer your customer from a search, not from a rebuild.

Sources

comments powered by Disqus

Releted Posts

Kubernetes multi-tenancy in 2026: revisit vCluster, Capsule and Kamaji before you hand another team its own cluster

Sooner or later a platform team gets the same request again. A product squad wants “its own cluster” because it needs to install an operator with cluster-scoped CRDs, a data team wants admin rights to try a new scheduler, and a customer-facing team asks for hard isolation because an auditor said so.

Read more

ML experiment tracking in 2026: revisit MLflow, Aim and ClearML before you buy another hosted tracker seat

Many ML and LLM teams still treat a hosted experiment tracker as the adult default. A few notebook charts feel messy, someone pastes a Weights & Biases or Neptune signup link into Slack, and the team buys another seat before anyone asks where the run history, artefacts and model lineage must live.

Read more

Self-hosted remote development in 2026: revisit Coder, DevPod and Eclipse Che before you buy another cloud IDE seat

Many teams still treat the laptop as the only place code can live. When that breaks, the next habit is to buy another managed cloud IDE seat, copy the team into a hosted workspace product, and hope the bill and the data residency story stay quiet.

Read more