SBOM and CVE Scanning – Why Secure Artifacts Are Essential for the Software Supply Chain

The security of software supply chains is one of the central topics in IT security today. Companies are under increasing pressure to ensure transparency, traceability, and reliability of the software they use. A key tool in this regard is the Software Bill of Materials (SBOM), complemented by automated scanning for known vulnerabilities – Common Vulnerabilities and Exposures (CVE).

In this post, we will:

• Explain the term SBOM and make it tangible using real-world concepts.
• Describe the concept of CVEs and introduce the main sources of vulnerability information.
• Show how tools like GitLab and Harbor help generate SBOMs and conduct CVE scans.
• Highlight the particular benefits of these processes for compliance-heavy industries such as pharma, industry, and GovTech.

What is a Software Bill of Materials (SBOM)?

A Software Bill of Materials is essentially a bill of materials for software. It describes the components that make up software – similar to the bills of materials used in industrial manufacturing.

Real-World Analogy

Let’s imagine a modern car. A car manufacturer knows exactly:

• Which screws, sensors, and electronic components are installed.
• The supply chains from which these parts originate.
• The quality and safety certificates available for the parts.

This exact concept is applied to software with an SBOM:

• Libraries and dependencies: e.g., OpenSSL, Log4j.
• Versions: precise indication of the versions used.
• License information: important for compliance with open-source rules.
• Origin: repository, registry, or package source.

The SBOM is thus a kind of “digital twin” of a software supply chain – it makes visible which components are in use.

Standards for SBOMs

There are various standards that have been established internationally:

• SPDX (Software Package Data Exchange)
• CycloneDX
• SWID (Software Identification Tags)

Each of these standards aims to describe software components in a machine-readable, interoperable, and unambiguous way.

What are CVEs (Common Vulnerabilities and Exposures)?

While SBOMs provide the inventory, a system is needed to associate known vulnerabilities with the respective components. This is where Common Vulnerabilities and Exposures (CVE) come into play.

Definition

CVE is a list of known security vulnerabilities and exposures that serves as a global reference. Each vulnerability is assigned a unique identifier, e.g.:

• CVE-2021-44228 (Log4Shell, a critical vulnerability in Log4j)
• CVE-2014-0160 (Heartbleed, a severe OpenSSL security flaw)

Sources for CVEs

The two most important “sources of truth” are:

• ENISA Vulnerability Database (EUVD) – the European vulnerability database developed by the EU Agency for Cybersecurity.
• MITRE Corporation – the organization that originally developed and still maintains the CVE system.

Both data sources are the foundation for almost all automated security tools.

Practical Benefits

With an SBOM, it is possible to automatically check for each library used:

• Are there known CVEs?
• What is the severity of these vulnerabilities (CVSS score)?
• Are immediate updates required?

Without CVEs, SBOMs would be worthless because they would only represent a list. Only by matching with CVE databases does real value emerge.

Interaction of SBOM and CVE

The combination of SBOM and CVE scanning is the central building block of a secure software supply chain.

Example: Log4j Crisis

When the Log4Shell vulnerability (CVE-2021-44228) became known in December 2021, thousands of companies worldwide faced the challenge: Where do we use Log4j?

• Without SBOM: tedious, manual search in code repositories, artifacts, and container images.
• With SBOM: automated query – which software components contain Log4j, in which version, and how can targeted updates be applied?

The SBOM is thus the foundation, CVE databases provide the attack vectors – and together they enable quick and targeted action.

Tools for SBOM Creation and CVE Scanning

GitLab

GitLab offers extensive security features directly in CI/CD pipelines:

• Automated creation of SBOMs.
• Dependency scanning: matching with CVE databases.
• Container scanning for Docker images.
• Policy management: rules for which CVSS scores are tolerated.

Harbor

Harbor is an open-source registry for container images:

• Integrated scanning of artifacts.
• Support for SBOMs through tools like Trivy.
• Signing and verification of images.
• Role-based access control.

Other Important Tools

• Trivy: Lightweight scanner tool for containers, filesystems, and repositories.
• Syft: Creation of SBOMs in CycloneDX or SPDX format.
• Grype: Vulnerability scanner for container images, compatible with SBOMs.

By integrating these tools into CI/CD pipelines, security becomes a continuous process rather than a downstream check.

Compliance Perspective

For many companies, SBOM and CVE scanning are not only a matter of security but also of compliance.

Industry Requirements

• Pharma: Regulations like FDA 21 CFR Part 11 require traceability and documentation of every component used.
• Industry: Standards like IEC 62443 demand security proofs for software used in critical infrastructures.
• GovTech: National security agencies require auditability and proof of trustworthiness.

Benefits of SBOM & CVE Scanning

• Auditability: SBOMs provide evidence of which components were in use and when.
• Transparency: Security vulnerabilities can be identified more quickly and traceably.
• Reduced Audit Effort: Instead of manual checks, an automated scan report is often sufficient.

Compliance teams thus benefit massively from automation.

Conclusion: SBOM & CVE are Indispensable

The discussion about secure software supply chains has shown through incidents like Log4j or the Bitnami incident how vulnerable global ecosystems are. With SBOM and CVE scanning, we have tools at our disposal to significantly reduce these risks.

• SBOMs create transparency.
• CVEs provide knowledge about threats.
• Tools like GitLab and Harbor operationalize these processes.

For companies – especially in regulated industries – the introduction of such processes is no longer a “nice-to-have” but an essential requirement for security, compliance, and resilience.