[ANN] PkgToSoftwareBOM.jl: Generate an SBOM of your environment


This package produces a Software Bill of Materials (SBOM) describing your Julia environment. At this time, the SBOM produced is in the (SPDX) format. Contributions to support other SBOM formats are welcome.

I created PkgToSoftwareBOM.jl to help the Julia ecosystem get prepared for the emerging future of software supply chain security. If we want to see Julia adoption to continue to grow, then we need to be able to easily create SBOMs to supply to the organizations using Julia packages.

PkgToSoftwareBOM interfaces with the standard library Pkg to fill in the SBOM data fields. Information filled out today includes a complete dependency list, versions in use, where the package can be downloaded from, and a checksum. Future versions may be able to fill in additional fields including copyright text and software license.

PkgToSoftwareBOM defaults to using the General registry but can use other registries and even mutiple registries as the source(s) of package information.

Link to repository

What is an SBOM?

An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships. These inventories should be comprehensive – or should explicitly state where they could not be. SBOMs may include open source or proprietary software and can be widely available or access-restricted.

For a further information about SBOMs, their importance and how they can be used please see the Software Bill of Materials website maintained by the National Telecommuications and Information Administration

Why do you care about SBOMs?

SBOMs are an important component of developing software security practices. US Presidential Executive Order EO 14028 established SBOMs as one method by which the federal government will establish the provenence of software in use. Commercial organizations are also using SBOMs for the same reason.

What does an SBOM look like?

The file PkgToSoftwareBOM.spdx.json at the root of this package is a Developer SBOM of this package.

See examples of User Environment SBOMs in the folder examples


Shouldn’t the package try to provide the licence of the dependent files from the LICENCE file in the repository instead of generating “NOASSERTION” ?

Identifying the license is on my TODO list. Either queries to GitHub API or using licensecheck.jl most likely.

1 Like