SBOM validation is one of the core features of the PCA CERVUS device-centric vulnerability monitoring & threat intelligence platform.
SBOM validation is the process of verifying the accuracy and completeness of a Software Bill of Materials (SBOM) by analysing the actual software binaries in a product to identify its components, dependencies and actual versions.
In practice, SBOM validation is when a provided SBOM is compared to the software or firmware in a product (either extracted from an SBOM or found via reverse engineering) and the manifest provided by the manufacturer is validated.
It’s how manufacturers and companies that deploy embedded devices find risks they would otherwise miss and a vital part of complying with regulations like the Cyber Resilience Act (CRA).
We explain the reasons and methodology for SBOM validation in this article.
Why Validate An SBOM?
Why would you want to validate an SBOM that a supplier has provided to you?
The PCA Cyber Security team has analysed hundreds of supplier-provided SBOMs and our core finding is that without validation, the majority of Software Bill of Materials (SBOMs) provided by suppliers are incomplete or outdated.
Thus, without validating what the supplier says, manufacturers or any companies deploying embedded devices are unlikely to get a full or up-to-date understanding of risk. This means they might deploy or ship devices which contain unknown software components and introduce completely hidden risks to their own and customer environments.
At PCA Cyber Security, we see five main reasons why clients use PCA CERVUS to validate their SBOMs:
-
Identify hidden components. Often SBOMs will omit third-party libraries, dependencies or software used during development.
-
Find incorrect or outdated component names, versions and dependencies.
-
Find vulnerabilities which otherwise might be missed when a vulnerable component is omitted from an SBOM.
-
Improve remediation efficiency. A validated SBOM shows you exactly where remediation is needed and where it is not needed.
-
Verify supplier claims. Manufacturers can independently check the accuracy of SBOMs received from their software suppliers, supporting supply chain security and regulatory compliance.
Our experience is that companies deploying or manufacturing connected devices should validate SBOMs to assess the security of those devices. Supplier-provided SBOMs are often generated automatically and may not accurately reflect the actual components in the device.
Without validation, you cannot fully trust any SBOM.
An SBOM Validation Example
As a hypothetical example, based on our real experience in the market, imagine a payment terminal manufacturer receives an SBOM from its firmware supplier. In this case, the SBOM will list the software components used in the terminal, including third-party libraries and their versions.
However, during SBOM validation, the manufacturer analyses the terminal's actual firmware binaries and discovers an open-source library that was not included in the supplier's SBOM.
This creates a potential security blind spot because if a vulnerability is discovered in the undocumented library, the manufacturer may not know that its payment terminals are affected.
Identifying this library means the manufacturer can include the newly identified component in its ongoing monitoring program and prevent potentially catastrophic security incidents from occurring.
How to Validate An SBOM?
Below, we explain a simple methodology for SBOM validation based on the PCA CERVUS platform’s workflow.
PCA CERVUS allows you to validate SBOMs by connecting software component information to evidence from the actual embedded device, rather than relying exclusively on a supplier's declared component list.
The methodology for SBOM validation has five steps, all of which can be supported by the PCA CERVUS platform:
1. Analysing the device firmware
The SBOM validation process starts with analysing the actual firmware binaries used by the embedded device. AI-assisted decompilation and reverse engineering are used to examine the software code rather than relying solely on supplier-provided component information.
2. Reconstructing the SBOM
Software components are identified directly from the firmware binaries and used to build an independent, evidence-backed SBOM. This verified SBOM provides a real picture of the software actually incorporated into the device, including components that may be missing from supplier documentation.
3. Comparing the provided and reconstructed software inventories
Where an existing SBOM is available, the reconstructed inventory can be compared against it to identify discrepancies, including missing components and inaccurate component information.
The aim is to establish whether the declared SBOM accurately represents the to-be-deployed device and find components that are missing from monitoring.
4. Verifying vulnerabilities against the binaries
The next step is to check whether known vulnerabilities actually exist in any of the device's software components.
This is particularly valuable for identifying silent patches, where a vulnerability has been fixed without changing the reported software component version.
Rather than relying exclusively on component names and versions to determine vulnerability exposure, binary analysis can provide direct evidence of the software's vulnerability status.
5. Continuously monitor the device
The resulting software inventory can be used for ongoing vulnerability and threat intelligence monitoring.
PCA CERVUS uses SBOM component information to identify relevant vulnerabilities, correlate threat intelligence and prioritise findings according to the device's attack surface and potential exposure.
This process is how product security teams can continuously assess the security of their embedded products. It is now also a critical part of compliance with regulations like the Cyber Resilience Act (CRA).
SBOM Validation With PCA CERVUS
The only way to securely use or ship embedded devices is to have in place a process for continuously monitoring them for security issues, vulnerabilities and threats.
This includes not only the development and certification process, but also the implementation of daily surveillance over the threat landscape and vulnerabilities. This requirement has roots in compliance standards (PCI PTS, CRA, etc.), common sense, and real incidents on the market.
PCA CERVUS is the easiest and most secure way for embedded product manufacturers and device operators to meet this requirement and is available for a demo now.