Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
Open Source / Security / Software Development

2023: The Year Open Source Security Supply Chain Grew Up

Open source security has always been important. We just pretended otherwise. We don't have that luxury of laziness anymore.
Jan 4th, 2024 8:00am by
Featued image for: 2023: The Year Open Source Security Supply Chain Grew Up

Open source security is now vital not only to developers but to governments and top corporations as well.

Open source security has always been important. We just pretended otherwise. We don’t have that luxury of laziness anymore. Now, the U.S. government’s Cybersecurity and Infrastructure Security Agency (CISA) Open Source Software Security Roadmap has declared we must secure open source software. It’s not just in the State. In the European Union (EU), the Cyber Resilience Act (CRA) is well on its way to demanding software to disclose software vulnerabilities within 24 hours and provide a minimum five-year guaranteed patch support.

The latest version of the CRA eases off on open source software. It declares, “In order not to hamper innovation or research, free and open source software developed or supplied outside the course of a commercial activity should not be covered by this regulation.” I’m not a lawyer, but I cover open source legal issues, there are enough weasel words in there to worry open source developers.

Linux Foundation Europe chief Gabriele Columbro worries that “in order to prevent liability, open source projects could be blocked for download into the EU or be published with a disclaimer [saying they are] not approved for use in the EU” may yet come true.

So, why are governments suddenly so worried about open source security?  Easy, they’ve finally realized just how vital software security is to overall security.

Decades ago, Eric S. Raymond, one of open source’s founders, famously coined Linus’s Law: “Given enough eyeballs, all bugs are shallow.” Makes you feel warm and fuzzy about open source security, doesn’t it? There’s a corollary, though. For Linus’s Law to work, you need expert eyeballs hunting and hands fixing bugs. We haven’t been doing well at that.

That’s a real problem because, as security company Synopsys said in its 2023 Open Source Security and Risk Analysis Report, “Open source is everywhere,” it’s “the foundation for the vast majority of commercial codebases. In fact, it’s so intertwined in modern development that code owners often don’t know the open source components in their own software.”


As Synopsys reported, “The first step in securing the software supply chain is managing the open source and third-party code in your applications. If you can’t effectively manage and ensure the security of your open source and third-party software, no other efforts made toward securing your supply chain will work — or frankly, even matter.”

Synopsys isn’t wrong. That’s where the open source software security community has been improving its game recently.

The rise of the Software Bill of Materials (SBOM), pronounced S-Bomb, has provided the essential groundwork needed for building code security defense. As President Joe Biden’s Executive Order on Improving the Nation’s Cybersecurity, declared SBOMs are “a formal record containing the details and supply chain relationships of various components used in building software.” SBOMs include  Software Package Data Exchange (SPDX), CycloneDX: GitHub’s dependency submission format; and Kubernetes Security Operations Center’s (KSOC) Kubernetes Bill of Materials (KBOM) standard.

But, to safeguard the integrity of open source software artifacts, you need more than SBOMs. That’s where Supply-chain Levels for Software Artifacts (SLSA, pronounced Salsa) come in.

Specifically, SLSA 1.0 provides:

  • A common vocabulary to talk about software supply chain security.
  • A way to assess your upstream dependencies is by evaluating the trustworthiness of the artifacts you consume, such as source code, builds, and container images.
  • An actionable checklist to improve your own software’s security.
  • A way to measure your efforts toward compliance with forthcoming Executive Order standards in the Secure Software Development Framework (SSDF).

Brian Behlendorf, the OpenSSF’s General Manager, emphasized that SLSA provides organizations with “the tools they need to protect their software.” My thumbnail description of SBOMs and SLSA is SBOMs as the recipe, and SLSA as the cooking instructions for a program.

So, how do you know what’s really what in those recipes? That’s where Sigstore, the open source software signing service, comes in. With Sigstore, you can cryptographically sign release files, container images, and binaries. Once signed, the signing record is kept in a tamper-proof public log. This gives software artifacts a safer chain of custody that can be secured and traced back to their source.

To make it easy to use Sigstore, Craig McLuckie, one of Kubernetes co-founders, co-started a new company, Stacklok, which builds on top of Sigstore. It’s two projects, Trusty and Minder. The former is a free service for developers to assess the dependency risk of a software package holistically. The latter is a platform for library creators to automate and enforce artifact signing and verification across multiple repositories.

Another recent open source addition to security is the Open Source Security Foundation (OpenSSF) Security Insights Specification. This provides a mechanism for maintainers to provide information about their projects’ security processes in a machine-processable way using YAML. With this, you don’t need to rewrite or relocate your existing policies and documentation. They can be integrated right into the Specification.

While most of 2023’s major security improvements were to the software supply chain, there were other significant advances. One of those was the rise of the vulnerability exploitability exchange (VEX) and its open source implementation, OpenVEX, This technology, used by Anchore, Chainguard, and Microsoft, among others,  records the status of software vulnerabilities. For example, with OpenVEX, instead of wasting time creating spreadsheets to track vulnerabilities, they can be recorded and then used by open source vulnerability scanners to reduce the pain of managing vulnerabilities and the burden of false positives.

But, just because the tools are there, doesn’t mean we use them. Snyk, a developer security company, found in its 2023 software security survey that 40% of respondents still don’t use key supply chain security technologies despite cyber attacks hitting record highs with an increasing focus on open source code.

Sure, companies know there’s trouble, but Synk found they were addressing their supply chain security problems on an ad hoc basis. Only half have a formalized supply chain security strategy in place.

Our security mission in 2024 is clear. We must take these software chain security tools and start using them as part of our toolchain.

Sounds easy, doesn’t it? It’s not.

One reason that’s proving difficult is we have nothing like enough IT security workers. As the  International Information System Security Certification Consortium (ISC2), recently pointed out, we’re short 4 million cybersecurity experts to support today’s global economy.

What’s a company using open source code to do? Well, first, as Bobby Ford, Hewlett Packard Enterprises’ (HPE) chief security officer, observed, “People think that cybersecurity is something that’s highly technical. Yes, some roles require deep technical expertise, but cybersecurity is a vast domain, and making an organization cyber-resilient also requires generalist roles that need a broader skillset.”

Therefore, 95% of cybersecurity professionals believe that “more could be done to encourage a greater recruitment drive of employees into cyber-security related roles.” You may already have the people in your company who are up for the challenge of helping to secure your software.

In addition, research has shown that 70% of cybersecurity labor feels overworked, and 25% of cybersecurity leaders will change jobs as a result of multiple work-related stressors.

In short, we need more people, many more people. That means devoting more time and energy going forward to security education.

It also means automating as much security as we can. By both educating and automating our security, we can build on the security standardization gains we made in 2023 to create a solid open source security foundation for the future. Considering the stakes, this isn’t just a good idea. It’s a necessity.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.