A software bill of materials is a machine readable list of what a program contains. Research software should ship one because it lets anyone scan the code for known vulnerabilities years later, without rebuilding the environment. CycloneDX and SPDX are the two common formats, and either works.
What it is and why it helps
An SBOM lists components, their versions and how they relate. It is an inventory, not a verdict. It does not say the software is safe. It says what to check.
For research code, the benefit is time. A paper's software may be reused for a decade. When a new advisory appears, an SBOM stored with the release lets a reader or a lab check the old version in minutes instead of reconstructing it.
The two formats
CycloneDX describes itself as a highly modular and extensible framework for representing supply chain information. Its current version on the project site is 1.7, released 2025-10-21, and it is published as ECMA-424. It can express components, services, dependencies and vulnerabilities, and the site says it suits vulnerability disclosure and VEX, the exchange format that records whether a vulnerability is actually exploitable in a given product.
SPDX is the other widely used format. Spack, a package manager built for large supercomputing centers, documents that every installation produces an SBOM in SPDX 2.3 format, stored in a .spack/sbom directory under the package prefix. The page notes that more formats are planned.
| Question | CycloneDX | SPDX |
|---|---|---|
| Machine readable | Yes | Yes |
| Seen in research computing tools | Python audit tools can emit it | Spack emits it |
| Choose when | Your tooling already writes it | Your tooling already writes it |
Pick whichever your build tooling produces natively. Converting later is possible, but starting with the native format avoids losing detail.
How to produce one
- Python projects: pip-audit can write CycloneDX JSON or XML from an environment or requirements file.
- Spack builds: read the SBOM that each install already contains.
- Containers: generate the SBOM from the built image, not from the source tree alone, so operating system packages are included.
What to store with it
Keep the SBOM next to the release, with the date it was generated. Link it from the README. If you archive the project in a repository such as an institutional or domain archive, include it in the deposit.
Limits to state honestly
An SBOM from your source tree may miss packages added at build time. One generated from a lock file reflects the lock file, not whatever a user installed afterwards. Say how yours was produced.
A note on privacy and sharing
An SBOM lists packages and versions, not your data, so it is generally safe to publish with a release. Check it for internal paths, usernames or private package names before you do, since some tools record the build location. If a dependency is private or proprietary, decide whether to list it by name, and note the choice in the README so readers know the inventory is complete or deliberately partial.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies against known vulnerabilities, and it can keep checking a stored inventory as new advisories arrive.
Try it yourself
Open the inventory demo and look at how components and versions are listed. That is the same information an SBOM carries.
Click through it at your own pace, or open it full screen.
Quick check
Does an SBOM prove my software is secure?
No. It lists what is inside. You still need to match it against vulnerability data and act on the result.
Do I need both formats?
Usually not. Publish the one your tooling writes, and convert only if a recipient asks.
Sources
Last reviewed: 19 October 2026.
