Tools overall analysis

List of SBOM generation tools


  Some of the features we used to analyze the SBOM generation tools were based on the framework for Evaluating SBOM Tools in fossa, such as:

  1. What standards it supports (SPDX, Cyclone DX)
  2. Compliance with the Cyber Security Executive Order
  3. Data Field Coverage
  4. Automation Support
  5. Programming Language Support
  6. Dependency Recognition Depth

We classified the tools following the SBOM Tool Classification Taxonomy document by the NTIA SBOM Formats & Tooling Working Group.

Syft

Feature Description
Logo
Version 0.83.1
License Apache License 2.0
Language Go
Classification Author after Creation (Audit tool)
Functionality Generates SBOMs for container images, filesystems, archives, and more to discover packages and librariesSupports OCI, Docker and Singularity image formatsLinux distribution identificationWorks seamlessly with Grype (a fast, modern vulnerability scanner)Able to create signed SBOM attestations using the in-toto specificationConvert between SBOM formats, such as CycloneDX, SPDX, and Syft’s own format.
Locations https://github.com/anchore/syft
Automation support Yes
Data Fields This tool assumes project metadata from the repo including name and license. It does identify find project version.
Package Depth This tool identifies dependencies between packages at the top level.
Relationships The tool could identify relationships between the packages and their metadata files. Still, it could not assign the correct relationship type for the dependencies and instead assiged the type other between all packages and files.
Support Specifications SPDX
Versions: 2.2, 2.3
Formats: JSON, tag-value
CycloneDX
Versions: 1.4
Formats: JSON, XML
How to use Container Images:
$ syft {image} -o {format}={output-file}
Directories:
$ syft {package-dir} -o {format}={output-file}
Installation Instructions: https://github.com/anchore/syft#installation
It requires sudo: No
It was installed: Yes
Testing It was tested: Yes
Comments:

Tern

Feature Description
Logo
Version 2.12.0
License BSD-2-Clause license
Language Python3 with a smattering of shell scripts
Classification Author after Creation (Audit tool)
Functionality Tern is an inspection tool to find the metadata of the packages installed in a container image. The overall operation looks like this:
- 1) It analyzes the first layer of the container image to collect information like distro type, package format, and package managers;
- 2) It then executes scripts from the “command library” in a chroot environment to collect information about packages installed in that layer;
- 3) With that information as a starting point, it continues to analyze the subsequent layers in the container image;
- 4) Once done, it generates a report of packages with their metadata. Several formats are available. The report, in its default format, provides a layer by layer, explanation of the various software components imported. If a Dockerfile is provided, the report indicates the Dockerfile lines corresponding to each of the file system layers.
Locations https://github.com/tern-tools/tern
Automation support Yes
Data Fields This tool assumes project metadata from the repo including name and license. It does identify find project version.
Package Depth This tool also identifies dependencies between packages below the top level.
Relationships In addition to contains and describes, there are two relationship types generatedFrom and hasPrerequisite.
Support Specifications SPDX
Versions: 2.1, 2.2
Formats: JSON, tag-value
CycloneDX
Versions: 1.4
Formats: JSON
Functions report
lock
How to use Container Images:
$ tern report -f {sbom-format} -i {image}:{version} -o {output-file}
Docker Files:
$ tern report -d {path_to_dockerfile}
Installation Instructions: https://github.com/tern-tools/tern#getting-started
It requires sudo: Yes
It was installed: No
Testing It was tested: Yes
Comments: I could run Tern by building a container with the Dockerfile provided.

Trivy

Feature Description
Logo
Version 0.42.1
License Apache-2.0 license
Language Go
Classification Author during Build, Author after Creation (Audit tool), Consume(Analyze)
Functionality Scan the target for vulnerabilities, misconfigurations, secrets, and licenses. Targets can be Container Image, Filesystem, Rootfs, Git Repository, Virtual Machine Image, Kubernetes, AWS, and SBOM.
Trivy can take a CycloneDX(JSON) or SPDX(tag-value or JSON) SBOM as an input and scan for vulnerabilities.
The Trivy AWS CLI allows you to scan your AWS account for misconfigurations. You can either run the CLI locally or integrate it into your CI/CD pipeline.
Locations https://github.com/aquasecurity/trivy, https://aquasecurity.github.io/trivy/v0.43, https://aquasecurity.github.io/trivy/v0.43/docs/target/aws/
Automation support Yes
Data Fields This tool assumes project metadata from the repo including name and license. It does identify find project version.
Package Depth
Relationships
Support Specifications SPDX
Versions: 2.3
Formats: JSON, tag-value
CycloneDX
Versions: 1.4
Formats: JSON
How to use Directories:
$ trivy fs --list-all-pkgs --format {sbom-format} --output {output-file} {package-dir}
Container Images:
$ trivy image --list-all-pkgs --format {sbom-format} --output {output-file} {image}:{version}
Repository:
$ trivy repo --list-all-pkgs --format {sbom-format} --output {output-file} {repository}
Installation Instructions: https://aquasecurity.github.io/trivy/v0.43/getting-started/installation/
It requires sudo: No
It was installed: Yes
Testing It was tested: Yes

Fossa

Feature Description
Logo
Version 3.8.2
License MPL-2.0 license
Language Java
Classification Author during Build, Author after Creation (Audit tool), Consume(View, Analyze), Transform(Translate, Tool Integration)
Functionality It heps to track, manage, and remediate issues with open source to:
1. Stay compliant with software licenses and generate required attribution documents;
2. Enforce usage and licensing policies throughout your CI/CD workflow;
3. Monitor and remediate security vulnerabilities;
4. Flag code quality issues and outdated components proactively.
Locations https://app.fossa.com/, https://app.fossa.io, https://docs.fossa.com/docs/getting-started
Automation support Yes
Data Fields This tool assumes project metadata from the repo including name and license. It does identify find project version.
Package Depth 5 dependency depth levels
Relationships In addition to contains and describes, there are two relationship types dependsOn and dependsOf.
Support Specifications SPDX
Versions: 2.3
Formats: JSON, tag-value
CycloneDX
Versions: 1.2, 1.3, 1.4
Formats: JSON, XML
How to use Online Application:
You need to create an account at https://app.fossa.io/account/register than you can navigate to Projects > Add Project to import the project you want to analyze and export the SBOM file. Its possible to analyze code locally with FOSSA CLI, but you still need to connect it to your account and the report is a link to their FOSSA web application, which will load the project and reports to be visualized and exported in .
For more details see https://docs.fossa.com/docs/getting-started
Installation Instructions: https://github.com/fossas/fossa-cli
It requires sudo: No
It was installed: Yes
Testing It was tested: Yes
Comments: It was tested using FOSSA CLI their online application to export the SBOM file.

bom

Feature Description
Logo
Version v0.5.1
License Apache-2.0 license
Language Go
Classification Author after Creation (Audit tool)
Functionality bom is a general-purpose tool that can generate SPDX packages from directories, container images, single files, and other sources. The utility has a built-in license classifier that recognizes the 400+ licenses in the SPDX catalog. Other features include Golang dependency analysis and full .gitignore support when scanning git repositories.
Locations https://github.com/kubernetes-sigs/bom, https://kubernetes-sigs.github.io/bom/
Automation support Yes
Data Fields This tool assumes project metadata from the repo including name and license. It does identify find project version.
Package Depth This tools does not identify any project dependencies
Relationships This tool only identifies relationships between the project and its files.
Support Specifications SPDX
Versions: 2.3
Formats: JSON, tag-value
Functions document
generate
How to use Container Images:
$ bom generate -a --format {sbom-format} --output {output-file} -i {image}:{version}
Directories:
$ bom generate -a --format {sbom-format} --output {output-file} -d {package-dir}
Installation Instructions: https://github.com/kubernetes-sigs/bom#installation
It requires sudo: Yes
It was installed: Yes
Testing It was tested: Yes
Comments:

Microsoft SBOM Tool

Feature Description
Version 1.1.6
License MIT license
Language C#
Classification Author after Creation (Audit tool)
Functionality Validate a build artifact using the manifest, and generate a SBOM for all the files in the given build drop folder, and the packages in the components path.
Locations https://github.com/microsoft/sbom-tool
Automation support Yes
Data Fields This tool assumes project metadata from the repo including name and license.
It does identify find project version.
No files were detected.
Package Depth All packages detected by this tool are directly related to the main package.
Relationships All relationships between the project and its packages are of the type dependsOn
Support Specifications SPDX
Versions: 2.2
Formats: json
Functions validate
generate
How to use Directories:
$ sbom-tool generate -b {output-dir} -bc {package-dir} -pn {package-name} -pv {package-version}
Installation Instructions: https://github.com/microsoft/sbom-tool#download-and-installation
It requires sudo: No
It was installed: Yes
Testing It was tested: Yes
Comments: