Software Supply Chain Security: Why SBOMs Will Be…

⏱ 8 min Reading Time

SolarWinds, Log4Shell, 3CX – the list of successful software supply chain attacks grows longer each year. Sonatype reports a 700% increase in supply chain attacks on open-source components since 2020. Meanwhile, the EU Cyber Resilience Act will make Software Bills of Materials (SBOMs) mandatory for all digital products starting in 2027. Companies that do not act now will soon find themselves without market access.

TL;DR

700% more supply chain attacks since 2020: Open-source dependencies are the primary entry point – on average, an application uses over 200+ transitive dependencies (Sonatype, 2025).
EU Cyber Resilience Act (CRA): Starting in 2027, all digital products must be delivered with SBOMs, vulnerability management, and security updates.
DevSecOps integration: SBOM generation, dependency scanning, and container signing belong in the CI/CD pipeline – not in the manual checklist.

Anatomy of a Supply Chain Attack

Supply chain attacks target not the software itself, but its dependencies – libraries, frameworks, build tools, and infrastructure components. The attack vector is particularly effective because a compromised package is automatically distributed to thousands of downstream users.

The most common methods: typosquatting (publishing a package with a nearly identical name to a popular package), account takeover (taking over the account of a trusted maintainer), dependency confusion (overwriting an internal package with a public one of the same name), and build system compromise (manipulating the build server or CI/CD pipeline).

The 3CX incident in 2023 demonstrated the full extent: attackers compromised an upstream library used by 3CX. The manipulated code ended up in the official 3CX desktop client, used by over 600,000 companies. Detection took weeks.

“Software supply chains are the weakest link in cybersecurity. Companies blindly trust code they neither wrote nor reviewed – and which is often maintained by unpaid individuals.”
– Brian Behlendorf, General Manager, Open Source Security Foundation (2025)

SBOMs, Signatures, and the EU Cyber Resilience Act

A Software Bill of Materials (SBOM) is a machine-readable inventory of all components of a software – including versions, licenses, and known vulnerabilities. The two standards are SPDX (Linux Foundation) and CycloneDX (OWASP). Both are functionally equivalent and supported by the most important tools.

The EU Cyber Resilience Act (CRA) will make SBOMs mandatory for all digital products sold in the EU starting in 2027. Manufacturers must actively manage vulnerabilities, provide security updates for the entire product lifecycle, and submit SBOMs to ENISA. This affects not only software manufacturers but also IoT devices, industrial controls, and connected consumer products.

Code signing and artifact signatures complement SBOMs: Tools like Sigstore (Linux Foundation) enable cryptographic signing of build artifacts and container images – for free and transparently. This allows any user to verify that an artifact truly comes from the expected build pipeline and has not been tampered with.

+ 700 %

Increase in supply chain attacks on open-source components since 2020. On average, every application contains over 200 transitive dependencies.

Sonatype State of the Software Supply Chain Report, 2025

DevSecOps Pipeline: Security as Part of the Build Process

Supply chain security only works if it is integrated into the development process – not as a subsequent audit, but as an automated part of the CI/CD pipeline:

Dependency Scanning: Tools like Snyk, Grype, or Dependabot automatically scan all direct and transitive dependencies for known CVEs with every build. Critical vulnerabilities block the build – no merge without a fix or documented risk acceptance.

SBOM Generation: Syft (Anchore) or cdxgen automatically generate an SBOM in CycloneDX or SPDX format with every release. The SBOM is stored as a build artifact and can be passed on to customers or regulatory authorities.

Container Security: Container images are particularly vulnerable – a typical base image contains hundreds of packages, many with known vulnerabilities. Trivy or Grype scan images before deployment. Distroless images (Google) or Chainguard images drastically reduce the attack surface.

Artifact Signing: Every build artifact is signed with Sigstore/Cosign. Kubernetes clusters can accept only signed images via policy (e.g., Kyverno, OPA Gatekeeper) – unsigned deployments are automatically blocked.

The effort for integration is manageable: In an existing GitHub Actions or GitLab CI pipeline, the additional steps can be implemented in one day. The tools are open source and free.

Key Facts at a Glance

Frequently Asked Questions

What is an SBOM?

A Software Bill of Materials (SBOM) is a machine-readable inventory of all components of a software – libraries, frameworks, dependencies – including version numbers, licenses, and known vulnerabilities. It is comparable to an ingredients list for software.

Which SBOM format should I use?

CycloneDX (OWASP) and SPDX (Linux Foundation) are the two established standards. CycloneDX has better vulnerability integration, while SPDX is stronger in license analysis. For a security focus, CycloneDX is recommended; for compliance focus, SPDX. Most tools support both.

When does the EU Cyber Resilience Act come into effect?

The CRA was adopted in 2024. Manufacturers have a transition period until 2027 to make their products compliant. After that, all digital products in the EU must be delivered with SBOMs, active vulnerability management, and security updates.

How do I start with supply chain security?

Three immediate actions: 1) Integrate dependency scanning into the CI/CD pipeline (Snyk, Dependabot – free tiers available). 2) Automate SBOM generation (Syft, cdxgen). 3) Scan container images with Trivy. All together can be implemented in one day.

What is Sigstore?

Sigstore is an open-source project of the Linux Foundation for cryptographic signing of software artifacts. It allows developers to sign code, container images, and other artifacts for free – without their own PKI infrastructure. The signatures are transparent and publicly verifiable.

Are open-source components less secure than proprietary ones?

Not inherently – but they are more transparently attackable. The code is public, which helps both attackers and defenders. The main risk lies with neglected projects maintained by single individuals. Tools like OpenSSF Scorecard automatically evaluate the security maturity of open-source projects.

Further Articles on the Topic

→ EU Cyber Resilience Act: What Manufacturers Need to Know

→ Passkeys 2025: A Guide for Enterprise Implementation