This article is the first official account of the Network Research Institute, follow WeChat to get more.
The December 2021 Log4j breach highlighted the software supply chain as a critically neglected area of security. It reveals how interconnected our software artifacts are, and how our systems are only as secure as their weakest link.
It also reinforces the idea that we may think security is something we can buy, but it's really about how we operate as a development team.
Since then, we've been working hard to improve.
Perhaps most notably, Google's open-sourced Sigstore project became the de facto method for signing software artifacts, adopted by all major language ecosystems, including Java, Python, Node, Ruby, and more. It became one of the fastest-adopting open source security projects in history and provided developers with a "wax seal" of authenticity for establishing the origin and provenance of their software building blocks.
The software bill of materials (SBOM) concept introduced by White House decree in May 2021 still feels far away. This notion of a common language for developers to share lists of ingredients in software packages has several emerging formats (SPDX, CycloneDX) that complicate matters.
Worse, it's unclear how SBOM will actually fit into a developer's workflow and what specific benefits developers will gain in the process.
Starting to bring all of this together and creating a cohesive strategy around software signing, SBOM, and developer workflow with greater urgency is governance, which will demand stricter ownership of software security integrity.
Back in April, the Cybersecurity and Infrastructure Agency (CISA) issued a request for comments on a new attestation form for secure software development that would put the onus on software company CEOs to certify that their software is developed in a secure environment. environment, and a good-faith, reasonable effort has been made to maintain a trusted source code supply chain.
So far, "reasonable" effort appears to be the guideline set forth in FedRAMP's Container Vulnerability Scanning Requirements and the National Institute of Standards and Technology's Secure Software Development Framework. But a more nuanced, in-depth explanation of the new self-certification requirement is in a clause covering third-party code incorporated into software.
In short, software providers will be held liable for unfunded, unmaintained popular open source software they use in their supply chains.
This dizzying array of considerations by CISOs has become the butt of many a Twitter meme:
supply chain tool chain
It's a bit shocking, if necessary, to examine the unchecked adoption of open source. I'm not suggesting that companies should not use open source, quite the opposite. There is no such thing as a free lunch, including when it's packaged as free (and open source) software. Someone needs to be paid to keep the maintainers up and running, and someone needs to help the developers understand all this incoming open source software.
Chainguard could be just that guy.
Chainguard, a company led by ex-Googlers, is responsible for the Sigstore project. It tries to bring all of this together into a cohesive toolchain for developers.
The startup's early work focused on locking down the build process and making features like signing, provenance, and SBOM native to the software supply chain and software build process. Last year, together with Wolfi, they launched the first community Linux (non-)distro built specifically around supply chain security primitives. They also launched Chainguard Images, which are base images for standalone binaries, applications like nginx, and development tools like Go and C compilers.
Recently, Chainguard made another major update to its Enforce platform, extending the building blocks used to lock down the build system to the toolchain that sits between developers and security teams.
Developers, security professionals, and even auditors need to know what packages are deployed, where, and by whom. SBOM is designed to help answer these questions and more, but the more complex the environment, the more difficult it is to achieve.
Clusters typically run hundreds of workloads and hundreds of container images, each with hundreds or even thousands of packages. We're still in the early days with SBOMs, and most software packages don't come with SBOMs; they need to be generated.
Chainguard aims to address both ends of the problem. First, as a Sigstore maintainer, the company has been bringing software signing, attestation, and certificate managers to all major programming languages and registries, so that there is unity and consistency in the way these open source projects create SBOMs. In the recently released Enforce, the platform will use Syft to automatically create the SBOM so that developers can view full package information for each image without any additional steps.
The most serious challenge with the new self-certification regulatory requirement is that container images often lag behind upstream updates, so the supply chain is still running images with known vulnerabilities. Additionally, most Common Vulnerabilities and Exposures (CVE) scanners today use package databases to see what packages are installed inside containers, but scanners cannot see software installed outside of those systems.
Chainguard provides higher fidelity datasets for vulnerability detection by enabling developers to easily obtain or automatically create SBOMs for packages that do not already include them. Additionally, Enforce's new vulnerability scans can tell teams if and where they are running artifacts with CVEs.
It all came at just the right time. No developer wants to be the first to figure out how to use the SBOM. Yet they have no choice: the combination of FedRAMP and self-attestation requirements is driving an urgent need for consistent visibility into software packages and automated processes to find and root out vulnerabilities.
An SBOM will soon become a requirement if you want to sell to the US Federal Government. But it's not just for those who sell to the government. It's reasonable to assume that a new self-certification model for assigning legal liability for insecure software could make the SBOM a common security expense across the tech industry, or at least for software companies that don't want to be named in future class action lawsuits.