So, The Software Supply Chain is Broken. How Do We Fix It?

Slowly.

It isn't funny, I know. But, it is the unfortunate reality in front of us. The software development and deployment supply chain is complex, with multiple stakeholders and dependencies, most of which are often outside our horizon of visibility and control, resulting in a spate of software supply chain attacks in recent years. Contrary to popular belief, this situation is exacerbated in the open-source world, with decentralised, sometimes-pseudonymous entities controlling some of the most critical software components that we as an industry collectively rely upon. Consensus is hard, and cooperation is limited.

While there is no silver bullet, we can certainly make a dent if we understand and accept the challenges, adopt open standards, and implement incremental changes in the way we currently develop and deploy software. Several organisations and industry bodies have looked at this issue and proposed improvements, but I find that Google's approach to vulnerability management is the most tangible and merits a deeper dive (because they have followed up with tools and guidelines).

Google also proposed a second set of criteria to prevent supply chain attacks for open source software, with extra constraints for a higher level of security. Check out the original blog for more details on the goals outlined here.

While this was an initial proposal, Google soon co-founded OpenSSF and followed up with Supply chain Levels for Software Artifacts (or SLSA, pronounced "salsa"), an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. They also published this excellent logical model to think about transparency in the supply chain - in my opinion, this covers most, if not all, of the layers required for improving supply chain security.

Let's break down these layers further, starting from the bottom:

• Trust foundation: This is the foundational layer, rooted in a decentralised trust fabric, with signatures, strong identities, distributed timestamping, and federation. Sigstore is the flagship project here - a new standard for signing, verifying, and protecting software. Sigstore "offers a suite of technologies that include Cosign for signing software artifacts, the Fulcio certificate authority, the Rekor transparency log, and Gitsign for signing Git commits. These tools can be used independently, or as one single process, for a holistic approach to open source security". Sigstore is already seeing rapid development and traction, with behemoths like Kubernetes and GitHub pledging early support.
• Software attestations: On top of a strong foundation, we need to ability to capture security metadata, and verify the systems and artifacts that are built along the way. This layer is effectively where the heavy-lifting is being done today, with several standards and frameworks already in place. Along with the aforementioned SLSA, projects like Software Bill of Materials (SBOM), Vulnerability Exchange (VEX), Open Source Vulnerability DB (OSV), Security Scorecards and others are helping improve the integrity of the supply chain.
• Aggregation and synthesis: This layers offers aggregation and synthesis, intelligently linking projects, resources, artifacts, repositories etc. and turning data into meaningful information. The Graph for Understanding Artifact Composition (GUAC) and deps.dev projects play in this space, helping to make sense of the rich security metadata collected and ingested in the previous layer. GUAC, in particular, helps answer questions like "what are the most used critical components in my supply chain ecosystem?", "am I exposed to risky dependencies?", "do all binaries offer traceability to my source?", "where am I exposed to new vulnerability X?", and many more.
• Policy and insight: Finally, this layer helps define and implement automation, risk management, and compliance throughout the life cycle. While this layer has had pretty good representation in the past, with publications like NIST SP 800-218: Secure Software Development Framework offering recommendations for mitigating the risk of software vulnerabilities, adding it to the model ensures that these practices are considered for software supply chain systems and artifacts as well.

If only supply chain security were as easy as following a logical model though. Like I said before, consensus is hard, and cooperation is limited. But I have hope that with enough awareness, we can slowly yet drastically improve our supply chain.