Most modern applications are mostly other people’s code. A typical project pulls in hundreds of open-source dependencies, each with its own dependencies, and any one of them can become an attack path. High-profile incidents have made this concrete: Log4Shell in 2021 showed how a single widely used library could expose countless systems, SolarWinds in 2020 showed how a compromised build pipeline could poison trusted updates, and the xz Utils backdoor discovered in 2024 showed how a patient attacker can infiltrate a small open-source project. Self-propagating attacks on package registries have continued since. In response, a set of practices has taken shape, including software bills of materials, build provenance frameworks, and signing. Here is an honest look at what each really delivers.
What an SBOM Actually Gives You
A software bill of materials is an inventory of the components inside a piece of software, commonly produced in the SPDX or CycloneDX formats. Its main value is speed: when a new vulnerability such as Log4Shell appears, an organization with accurate SBOMs can query which products contain the affected library instead of scrambling to search. Regulation is pushing adoption, including US executive guidance since 2021 and the European Union’s Cyber Resilience Act, which phases in obligations for manufacturers of products with digital elements. The limitation is that an SBOM is a list, not a defense. It does not say whether a vulnerability is reachable, and an inaccurate or stale SBOM can give false confidence.
Provenance and Signing
Where an SBOM says what is in the software, provenance says how it was built. SLSA, short for Supply-chain Levels for Software Artifacts, is a framework that describes increasingly strong guarantees about build integrity, such as builds running in controlled, tamper-resistant environments and producing verifiable records. Sigstore and similar tools make it easier to sign artifacts and verify those signatures, without developers managing long-lived keys. Together they help answer whether an artifact really came from the expected source and pipeline. The hard part is adoption: verification only helps if consumers actually check signatures and provenance, and most do not yet.
Practical Steps That Reduce Risk Today
Some of the most effective measures are unglamorous. Pin dependency versions and use lockfiles so builds are reproducible, and review updates rather than accepting them blindly. Reduce the dependency count where practical, since every package adds risk. Use automated scanning for known vulnerabilities, but treat results with judgment, as many alerts concern code paths an application never uses. Protect the build pipeline itself: limit who can change workflows, use short-lived credentials, and require reviews for changes to build configuration. Enforce multi-factor authentication for package registry and source accounts, since stolen maintainer credentials have driven many compromises.
Where Teams Overinvest and Underinvest
Teams often overinvest in producing SBOMs for compliance while underinvesting in using them, so the documents sit unread. Others buy scanning tools that generate thousands of alerts no one can triage, leading to alert fatigue. Underinvestment is common in the basics: weak access control on build systems, long-lived tokens in pipelines, and no process for removing abandoned dependencies. A realistic approach is to prioritize by exposure: protect the build and release path first, know what you ship, and focus vulnerability work on reachable, exploitable issues. Small teams cannot do everything, and sensible defaults beat a perfect program that is never finished.
Looking at how organizations have fared, the pattern is that supply chain security improves through process more than purchases. Teams that generate SBOMs automatically in their build pipeline, store them centrally, and actually query them during incidents get real value, and those that harden their pipelines and credentials remove entire categories of attack. Meanwhile, consuming open-source safely remains a shared problem: maintainers of critical projects are often volunteers, and funding and support matter. Expect continued regulatory pressure, better tooling for provenance, and more emphasis on verifying what you consume. None of this removes the need for ordinary good practice, such as least privilege, code review, and fast patching of known vulnerabilities.
Conclusion
Software supply chain security is not solved by any single standard or tool. SBOMs tell you what you ship, provenance and signing tell you how it was built, and disciplined dependency and pipeline hygiene reduces the chance of being surprised. Start with the build pipeline and the basics, make the data usable during incidents, and improve a little each quarter.
