A software bill of materials lists the components inside a piece of software. Generating one is the easy part. The harder questions are whether it is accurate, which of its components are vulnerable, and whether the SBOM a supplier handed you matches what actually ships.
Testers meet SBOMs from both sides: as an input to a product or firmware assessment, and as a deliverable clients now need for the Cyber Resilience Act, FDA submissions and US federal procurement. These are the tools that come up in that work.
PCA Cervus is a device-centric vuln monitoring, and threat intelligence platform that supports SBOM analysis & SBOM validation
Component analysis platform that ingests SBOMs and tracks software supply chain risk over time.
Vulnerability scanner for container images and filesystems, from the makers of Syft.
Command-line tool and library that generates an SBOM from container images and filesystems.
Scanner for vulnerabilities, misconfigurations, secrets and SBOMs across containers, Kubernetes, repositories and cloud.
Builds SBOMs from compiled binaries, showing what actually executes rather than what a manifest declares.
Product cybersecurity platform for connected-device makers: firmware SBOMs, vulnerability management and CRA compliance.
Missing one? Suggest a tool
No. An SBOM is an inventory. It tells you which components are present, and an SBOM analysis tool tells you which of those have known vulnerabilities. It does not find flaws in your own code or configuration, which is what a penetration test is for.
Not without checking it. A supplied SBOM describes what the supplier believes ships. Tools that analyse the binary or firmware directly can confirm whether it matches, which is the step most procurement processes skip.
Not to start. Syft for generation, Grype for matching and Dependency-Track to hold the results cover most software teams. Commercial tools earn their cost on firmware and binaries, validation of supplier SBOMs, and compliance evidence.