SBOM: Know your supplier

Security work has always been important at Wapice. We develop multiple software products, each with security needs of its own. Security work rarely provides visible value by itself. It is most effective when everything runs smoothly and people barely notice it.

Building and maintaining secure software is essential for creating reliable products. Doing this consistently requires supporting infrastructure and processes, ranging from CI/CD pipelines and dependency management to vulnerability monitoring.

Modern software consists of many third-party libraries, frameworks, tools and containers. Their dependency trees can run deeper than the Mariana Trench. Even software developed largely in-house relies on components coming from external suppliers.

If those components are not known, audited and maintained, they can introduce supplier based vulnerabilities in final products.

An SBOM helps you know what you ship, identify affected products when new vulnerabilities appear, prioritize security work and provide reliable information to customers. It turns unknown third-party dependencies into manageable risks and helps prepare your organization for requirements such as the EU Cyber Resilience Act.

The EU Cyber Resilience Act (CRA) makes cybersecurity a legal requirement for many hardware and software products sold in the EU. Manufacturers must track and mitigate vulnerabilities, provide security updates and document software components. That includes a machine readable SBOM. However the CRA does not require it to be shipped by default but to be available for authority inspection upon request.

Vulnerability and incident reporting obligations apply from 11 September 2026, while the main CRA requirements including SBOM generation requirement, apply from 11 December 2027. Once effective, non-compliance can lead to fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Authorities may also restrict, withdraw or recall non-compliant products.

It it well known that modern software builds heavily on 3rd party components. Open-source packages, container images, build tools and CI/CD systems help teams deliver software faster, but they also extend the attack surface beyond the organization’s own code.  Recent incidents have shown that attackers increasingly target trusted software ecosystems instead of individual products. Compromised package repositories, malicious dependencies and attacks against CI/CD pipelines have affected large numbers of organizations simultaneously.

Without a systematic process for tracking third-party components and vulnerabilities, risks tend to accumulate over time. A single outdated dependency may seem insignificant, but large software products can eventually contain hundreds or thousands of outdated and vulnerable depedencies containing vulnerabilitis. This makes prioritization difficult and increases the chance that important findings are overlooked.

This is where SBOMs and vulnerability management processes become essential.

An SBOM (Software Bill of Materials) is a machine-readable inventory of the software components included in a product. It describes the components of a software product in a standardized format. Common formats include CycloneDX and SPDX.

At its simplest, an SBOM contains package names and versions. More complete and advanced SBOMs may include:

• Unique identifiers such as Package URLs and CPEs
• Component hashes
• License information
• Supplier information
• Dependency relationships
• Build and environment information

This additional metadata matters because vulnerability analyzers must correlate SBOM components with entries in public vulnerability databases. More accurate infomration makes the comparison between CVE databases easier and improve accuracy while ambiguous package names, missing versions or incorrect identifiers can lead to both missed vulnerabilities and false-positive findings. Inaccurate SBOMs are even more dangerous than not having an SBOM since those create the false sense of security.

An SBOM is not the end goal. Its primary purpose is to enable vulnerability detection and tracking for third-party components throughout the software lifecycle.

Effective 3rd party vulnerability management typically requires:

• Repeatable and accurate SBOM generation
• Storage and versioning of SBOMs along with software releases
• Continuous vulnerability monitoring with vulnerability analysis tools
• Ownership of findings
• Prioritization and impact analysis
• Remediation and documented mitigations
• Monitoring of newly published vulnerabilities
• Communication with customers and other stakeholders

Without these supporting practices, an SBOM can easily become another build artifact that is generated but rarely used.

The goal is not merely to collect component information. The goal is to identify vulnerable components, understand their impact on the product and ensure that security risks are addressed in a timely and controlled manner.

There are many tools available for generating Software Bills of Materials (SBOMs) and performing vulnerability analysis based on SBOM data. When it comes to SBOM generation, the most accurate results are often achieved using tooling that integrates directly with the build process and package management ecosystem of the application. Many of these tools support the CycloneDX format, which has become one of the industry’s most widely adopted SBOM standards.

For general-purpose SBOM generation, Syft is a popular choice. It supports a wide range of programming languages, operating systems, containers, and software packages, making it an excellent tool for quickly generating SBOMs across diverse environments.

the vulnerability management side, there are several mature options available:

• Grype: A lightweight CLI tool for fast vulnerability scanning of SBOMs.
• OWASP Dependency-Track: A full blown platform for managing SBOMs and continuously monitoring software components for known vulnerabilities and supply chain risks.

At Wapice, we have invested significant effort into researching software supply chain security and SBOM-driven vulnerability management. To better understand the challenges faced by development teams, we deployed Dependency-Track in our own datacenter and began using it across internal projects.

It did not take long for our team to identify critical a limitation in usability. While Dependency-Track provides excellent visibility into vulnerabilities across a product’s dependency tree, it does not differentiate between vulnerabilities that developers can realistically address and those buried deep within transitive dependencies outside their control. As a result, teams can easily be overwhelmed by large numbers of findings without clear guidance on where to focus their efforts.

To tackle this challenge, we forked the project and started developing our own enhancements to provide better visibility, prioritization, and actionable insights for our development teams.

Want to know what we built and how it helps developers focus on the vulnerabilities that actually matter? Stay tuned for Part 2.