Software Bill of Materials – a burden or a benefit? You decide.
Wapice helps organisations create accurate SBOMs even in challenging software environments, integrate component information into existing development workflows and use it for practical vulnerability analysis.
Generic SBOM scanners produce incomplete or inaccurate results, especially in complex builds, firmware and legacy software.
Vulnerability scanners produce findings, but teams still need effective ways to understand and prioritise them.
Cybersecurity regulation is ambiguous. It is hard to judge what SBOM and vulnerability management capabilities are sufficient.
How to distribute SBOM and vulnerability information in closed-source supply chains?
Are you shipping hidden risk?
Modern software typically consists of numerous third-party components, with dependency trees extending far beyond what development teams directly see.
Third-party code, containers and trusted components can all introduce vulnerabilities into the software supply chain.
When these risks accumulate unnoticed, they can affect software quality, create costly security incidents and make regulatory compliance increasingly difficult.
Effective software supply chain security requires accurate visibility into your software components, well-defined processes and tools that support the engineering team.
Accurate SBOM matters
The first step in knowing what software contains is a Software Bill of Materials, more commonly known as an SBOM.
An SBOM represents the dependency tree in a standardized inventory that can be read and understood by vulnerability analyzers and other systems. SBOMs can, however, vary significantly in quality.
The simplest SBOM may contain only package names and versions, whereas a more accurate version can include identifiers such as PURL, CPE and hashes, license information and build information.
Creating a high-quality SBOM can be challenging without previous experience.
Ensuring that the SBOM is as accurate as possible reduces false positives and misconceptions while providing a realistic view of software dependencies.
Univeral SBOM scanners might be very inaccurate. It is recommended to create SBOM as part of your build instead.
SBOM and regulation
The EU Cyber Resilience Act (CRA) requires manufacturers to identify and document software components in a commonly used, machine-readable format. In practice, this means maintaining an accurate Software Bill of Materials (SBOM) for products with digital elements.
The CRA also requires manufacturers to address known exploitable vulnerabilities and to perform vulnerability analysis and management throughout the product lifecycle. This makes SBOM not only a documentation requirement, but also an important foundation for continuous vulnerability management and software supply chain security.
The main CRA obligations become applicable on 11 December 2027.
From SBOM to vulnerability management
One of the most important benefits of an SBOM is that it enables vulnerability tracking against public vulnerability databases such as CVEs.
This provides visibility into vulnerabilities affecting third-party software components. However, analyzing an SBOM once is only the beginning of a well-defined software supply chain security process.
Feeding an SBOM into a vulnerability analyzer does not automatically guarantee accurate or actionable results. The quality of the SBOM determines which vulnerabilities can be identified in the first place.
Even with a high-quality SBOM, several challenges remain:
Scope creep: Large applications may contain hundreds or thousands of vulnerabilities, making prioritization difficult.
Unfixable vulnerabilities: Vulnerabilities may exist outside direct dependencies and cannot always be upgraded by the development team.
Impact uncertainty: Finding a vulnerability does not necessarily mean the product is affected. Determining exploitability often requires additional analysis beyond the SBOM.
Custom mitigations: Backported patches and other mitigations may remain invisible to standard vulnerability analysis.
Make vulnerability data more useful
OWASP Dependency-Track is a free and open-source platform for organization-wide third-party software vulnerability management.
Wapice has practical experience using and extending Dependency-Track and integrating SBOM-based vulnerability analysis into software development environments.
For situations where standard vulnerability information creates too many false positives, we have also developed AI-assisted, context-aware relevance analysis that can provide additional information about whether vulnerable functionality is actually used by the software.
We help companies build software supply chain security practices that fit their products, development environments and regulatory requirements.
Pick & commission tools for efficient and CRA-compliant vulnerability management process
Organize a workshop where we get your team on board with SBOM and Vulnerability topics
Boost vulnerability assessment with AI or other automation
Offload software maintenance & vulnerability management to our support team
Finding the best tools for your SBOM generation
Integrating SBOM tools with existing workflows and tools
SBOM process quality analysis
These are examples of ways how we usually start working with clients. Feel free to tell how you would like to start!
Build software supply chain security into your development process
SBOM creates value when it becomes part of continuous software security work — not when it remains an unused build artifact.
Whether you are preparing for CRA requirements, struggling with SBOM accuracy or looking for a more effective way to manage third-party vulnerabilities, we can help you define the right approach and put it into practice.
