What you'll take away
In December 2021, a critical vulnerability was disclosed in Apache Log4j — a Java logging library so ubiquitous that it was embedded in products sold by thousands of vendors, running in the infrastructure of tens of thousands of enterprises, and present in applications whose developers had never heard of Log4j because it was a transitive dependency: a dependency of a dependency of a dependency.
The immediate remediation question — 'do we run Log4j?' — proved nearly impossible to answer quickly for most organisations. Security teams spent weeks manually searching codebases, container images, and third-party software inventories trying to determine their exposure. The average enterprise took 17 days to fully assess their Log4j footprint. The vulnerability had been exploitable for 17 days before many organisations knew they were at risk.
A Software Bill of Materials would not have prevented the Log4j vulnerability. But it would have reduced the discovery phase from weeks to hours.
What Is an SBOM?
A Software Bill of Materials is a formal, structured inventory of all software components in an application or system — including open-source libraries, proprietary components, and their transitive dependencies. An SBOM names every component, its version, its license, and its known vulnerabilities at the time of generation. It is the software equivalent of a product's ingredients list.
The most common SBOM formats are SPDX (ISO standard, backed by the Linux Foundation) and CycloneDX (OWASP standard, widely supported by security tooling). Both are machine-readable and designed for automated vulnerability correlation against CVE databases.
The Regulatory Mandate
SBOM is no longer a best-practice recommendation — it is becoming a regulatory requirement in multiple jurisdictions simultaneously:
- US Executive Order 14028 (May 2021) requires software vendors selling to the US federal government to provide an SBOM for all software components. CISA has issued detailed guidance on SBOM minimum elements and is enforcing the requirement for federal contractor renewals.
- EU Cyber Resilience Act (entering enforcement 2027) requires manufacturers of products with digital elements — including software — to maintain an SBOM for the product lifecycle and provide it to national authorities on request. This applies to any company selling to EU customers.
- EU NIS2 Directive requires supply chain security assessment — which operationally requires knowing what software your suppliers are providing you, pushing SBOM requirements downstream through enterprise supply chains.
- FDA guidance for medical devices requires SBOMs for all software components in medical devices as a condition of market approval.
The average enterprise runs 530 open source components across its application portfolio. Studies consistently find that 85-90% of application code is open source rather than in-house developed. Most enterprises have never performed a systematic audit of what that code contains or what vulnerabilities it carries.
Supply Chain Attack Patterns
Understanding why SBOM matters requires understanding how supply chain attacks actually work:
- Dependency confusion: An attacker registers a public package with the same name as a private internal package. Build tools that check both public and private registries download the public (malicious) version when its version number is higher. Discovered in 2021; still active.
- Typosquatting: Registering packages with names similar to popular packages (numpy vs numpay, requests vs request). Developers making typing errors install the malicious package.
- Maintainer account takeover: Attackers compromise the credentials of a legitimate open-source maintainer and push a malicious release. The package passes every integrity check because it is signed by the real maintainer's key.
- Malicious package injection: The XZ Utils backdoor (2024) — a sophisticated, multi-year campaign where an attacker built social capital in an open-source project over months before introducing a backdoor in a compressed release. It was caught by accident, days before it would have shipped in major Linux distributions.
Is your security posture audit-ready?
48-hour turnaround. No obligation.
SLSA — Supply Chain Levels for Software Artifacts
SLSA (Supply Chain Levels for Software Artifacts, pronounced 'salsa') is a framework developed by Google, now managed by the OpenSSF, that defines four levels of supply chain security maturity. Each level adds incrementally stronger guarantees about how software was built and whether it was tampered with:
- SLSA Level 1: Build process is documented and produces provenance — metadata describing how an artifact was produced.
- SLSA Level 2: Source and build are version-controlled, and provenance is generated and signed by the build service.
- SLSA Level 3: Source and build platforms meet specific security standards. Builds are isolated and tamper-resistant.
- SLSA Level 4: (Proposed) Two-person review, hermetic builds, reproducible build process.
What a Mature Supply Chain Security Practice Looks Like
- SBOM generation in CI/CD: Every build automatically generates an SBOM using tools like Syft, cdxgen, or native toolchain integrations. The SBOM is stored alongside the artifact.
- Continuous vulnerability correlation: SBOMs are automatically correlated against CVE databases on generation and on new vulnerability disclosure. Critical CVEs in production components generate immediate alerts.
- Dependency pinning and lock files: All dependencies are version-pinned and managed through lock files (package-lock.json, poetry.lock, Gemfile.lock). Direct registry resolution is prohibited in build pipelines.
- Private registry with allow-listing: An internal registry (Nexus, Artifactory, or AWS CodeArtifact) serves as the single source of all dependencies. Direct internet resolution is blocked. New packages require approval before being added to the allow-list.
- Signed artifacts and provenance: Build artifacts are cryptographically signed using Sigstore/Cosign, and provenance attestations are generated and verified at deployment time.
- Supply chain security policy: Licence compliance requirements, prohibited licence types, dependency age limits, and minimum SLSA level requirements for critical components.
Where to Start
The highest-value first step is SBOM generation and continuous vulnerability scanning — it delivers immediate visibility into existing risk without requiring a multi-month programme. Run Syft or cdxgen across your production container images and application codebases today. The output will show you what you're actually running. What you find will determine the urgency of the rest of the programme.
GYSP's Cyber Security and Cloud & DevOps Engineering practices implement supply chain security programmes covering SBOM generation in CI/CD pipelines, private registry setup, vulnerability correlation automation, and SLSA maturity roadmaps — built to satisfy both the EU Cyber Resilience Act and NIS2 supply chain obligations.
“Most enterprises are more secure against external perimeter attacks than they are against supply chain attacks. Perimeter security is visible and auditable. Supply chain security is invisible until a package you didn't know you were running does something you didn't know it could do.”
— Rahul, AI/ML Delivery Head — GYSP.tech
