SBOM and Software Supply Chain Security — Protecting the Supply Chain

SolarWinds, Log4Shell, xz Utils — supply chain attacks have become one of the most serious threats. How to defend? SBOM (Software Bill of Materials) and SLSA framework are the answer every company needs in 2026.

Why Supply Chain Security Is Critical¶

Modern software is 80-90% composed of open-source dependencies. The average enterprise application has hundreds of direct and thousands of transitive dependencies. Each one is a potential entry point for an attacker.

Supply chain attacks are particularly insidious because they bypass traditional security measures. A compromised library passes code review, passes tests, passes scanners — because the malware is part of a “trusted” dependency.

The EU Cyber Resilience Act (CRA), which takes effect in 2027, requires SBOM for all software products sold on the European market. Preparation must start now.

What Is SBOM and Why You Need It¶

SBOM (Software Bill of Materials) is a complete list of all components that make up your software — libraries, frameworks, tools, versions, licences. Think of it as the ingredient list on food packaging.

SBOM enables:

• Rapid response to CVEs: When a new vulnerability appears (like Log4Shell), you immediately know which applications are affected.
• License compliance: Automatic detection of licence conflicts (GPL in a commercial product).
• Vendor risk management: Visibility into your suppliers’ dependencies.
• Regulatory compliance: NIS2, CRA, DORA — all require knowledge of software composition.

SBOM Formats — SPDX vs CycloneDX¶

Two dominant formats in 2026:

• SPDX (Software Package Data Exchange): ISO/IEC 5962:2021 standard. Strong in licence compliance. Supports JSON, XML, YAML, RDF. Preferred by NTIA and federal agencies in the USA.
• CycloneDX: OWASP standard. Focused on security — supports VEX (Vulnerability Exploitability eXchange), services, ML model BOM. Lightweight JSON/XML. Preferred in the DevSecOps community.

Our recommendation: CycloneDX for security-first organizations, SPDX for regulatory compliance and licence management. Tools can convert between formats.

Generating SBOM in the CI/CD Pipeline¶

SBOM must be generated automatically with every build. Manual management is unrealistic. Proven tools:

• Syft (Anchore): Generates SBOM from container images, filesystems, archives. Supports both SPDX and CycloneDX. Open-source.
• Trivy (Aqua Security): Scanner + SBOM generator in one. Excellent Kubernetes integration.
• cdxgen: CycloneDX generator with support for 30+ languages and frameworks. Also detects reachability — whether the vulnerable code is actually called.
• GitHub/GitLab native: Both platforms offer dependency graphs and SBOM export. A good starting point for smaller projects.

Integration into the pipeline typically looks like this: build -> SBOM generation -> vulnerability scan -> SBOM signing -> SBOM storage -> deployment.

SLSA Framework — Build Integrity¶

SBOM tells you “what software is made of”. SLSA (Supply-chain Levels for Software Artifacts) tells you “how software was built” — and whether you can trust the process.

SLSA defines four levels:

• Level 1: Documentation of the build process — who, when, how. Provenance metadata.
• Level 2: Automated build + signed provenance. Hosted build service (GitHub Actions, GitLab CI).
• Level 3: Hardened build platform — isolated builds, tamper-resistant provenance. Reproducible builds.
• Level 4: Two-person review, hermetic build, full auditability. Enterprise standard for critical software.

Most Czech companies are at Level 0-1. The goal for 2026 should be at least Level 2 — automated CI/CD with signed provenance.

Dependency Management Best Practices¶

SBOM and SLSA are important, but prevention is better than detection:

• Lock files everywhere: package-lock.json, Pipfile.lock, go.sum — pin exact versions. No floating ranges in production.
• Private registry proxy: Artifactory or Nexus as a proxy for npm, PyPI, Maven Central. Caches, scans, and blocks problematic packages.
• Automated dependency updates: Dependabot or Renovate with automatic PRs. But: review before merge, never auto-merge for major versions.
• Scorecard check: OpenSSF Scorecard evaluates the security practices of open-source projects. Integrate into PR review — it flags dependencies with poor security hygiene.
• Sigstore / cosign: Sign your own artifacts (container images, binaries). Verify signatures at deployment.

VEX — Context for Vulnerabilities¶

SBOM + vulnerability scan generates hundreds of findings. Most of them are false positives or non-applicable vulnerabilities. VEX (Vulnerability Exploitability eXchange) adds context:

• Not Affected: The vulnerable function is not called in our code
• Affected: We are impacted, but we have a mitigation
• Fixed: Fixed in the given version
• Under Investigation: We are investigating

VEX dramatically reduces alert fatigue and helps security teams focus on actual threats.

Practical Roadmap for Companies¶

Introducing supply chain security step by step:

• Months 1-2: Audit the current state. Inventory dependencies. Introduce lock files. Deploy Trivy/Syft into CI/CD.
• Months 3-4: SBOM generation for all production applications. Central SBOM storage (Dependency-Track). Vulnerability alerting.
• Months 5-6: SLSA Level 2 — signed provenance, automated builds. Private registry proxy. Scorecard integration.
• Ongoing: VEX process for vulnerability triage. Regular supplier audits. Preparation for CRA compliance.

Supply Chain Security Is a Team Sport¶

Protecting the software supply chain is not just the security team’s concern. It requires collaboration between developers (dependency management), DevOps (CI/CD hardening), security (vulnerability management), and management (risk governance).

Our tip: Start by generating an SBOM for one critical application. You will see how many dependencies you did not even know you had. That is the best motivation for action.