Chainguard, the co-creator of Sigstore, has conducted a survey to better understand if and how software supply best practices
are utilized by the industry. We take a look at the findings.

With the title, SLSA++ A Survey of Software Supply Chain Security, it was actually run by a consortium comprising  Chainguard, the Eclipse Foundation, the Rust Foundation and the OpenSSF. Suffice to say that these resounding names put some weight behind it.

It tried to address the following questions: 

• Is everyone doing software supply chain security, or is everyone just talking about software supply chain security?
• Do software professionals actually think different software supply chain practices are helpful, easy or difficult? 

The objective of the survey in addressing those questions was to grasp a better understanding of the direction the industry has taken concerning the software supply security and identify any shortcomings on that route that render the the best security practices difficult to adopt.

In order to introduce a level of uniformity, the best practices were derived from the Supply-chain Levels for Software Artifacts (SLSA) framework. The questions investigated the extent to which respondents used SLSA-related and other software supply chain security practices, the extent to which respondents perceive these practices as helpful, and the extent to which respondents believe these practices are difficult.

But since SLSA does not include all aspects of software supply chain security, the survey also added some questions about other popular practices sometimes associated with software supply chain security, including SBOMs (Software Bill if Materials) and vulnerability scanning. Hence the SLSA++.

The survey, conducted in the summer and fall of 2022, included data from nearly 170 respondents at a wide range of organizations, large and small, some security-focused in their role and others not. All respondents answered a series of questions for ten different software supply chain security practices, where the responses were on the 5-point scale from Always to Never:

Three findings stood out:

1. Some software supply chain security practices are widely practiced. Many SLSA security practices already enjoy at least moderate adoption. That said, providing provenance, arguably a key SLSA-related practice, notably lags in adoption.

2. Most SLSA practices are considered helpful though there is hardly any variation in the aggregate level of perceived usefulness. Importantly though, an individual’s belief in the usefulness of a SLSA practice is closely related to whether they or their organization adopt it.

3. Some SLSA practices are considered substantially more difficult than others. For instance, using a centralized build service or performing container vulnerability scanning are considered relatively easy while hermetic and reproducible builds and providing provenance are considered notably difficult.

Surprisingly, the perceived difficulty of each SLSA practice has relatively little effect on whether an individual or organization adopts a practice. The results suggest that where there is a will, there is a way.

Some practices, like constructing an SBOM have not really caught on, despite the requirement by the recent White House National Cybersecurity Strategy. Per the findings, some respondents expressed concern about the utility of SBOMs. For instance, one survey respondent wrote,

Generating SBOMs is not really difficult anymore, but what do I do with it afterwards?

Another respondent commented on their belief that SBOMs aren’t necessary to enable vulnerability scanning.

We can get vulnerabilities very easy [sic] without creating a SBOM. The SBOM is there for us if a vendor asks for a SBOM of the solution. So it’s good for that purpose, but that request is rare.

Due to the advent of tools like Jbom, collecting the software bill of materials is now easier than ever. In "jbom - Dependency Analysis For Java Apps" we found that in simple terms you've got a few options for generating SBOMs:

GOOD -- Static SBOM (source) - This works fine , but you'll miss runtime libraries from appservers and runtime platforms. You'll also include libraries that don't matter like test frameworks. You'll also have no idea which libraries are actually active in the running application.

BETTER -- Static SBOM (binary) - You'll still miss parts , because code can be located in a variety of different places. And you'll also probably include libraries that don't matter but happen to be on the filesystem.

BEST -- Runtime SBOM - This is what 'jbom' is all about. Runtime SBOM is the most accurate approach as it captures the exact libraries used by the application , even if they are in the platform , appserver , plugins , or anywhere else. This approach can also include details of services invoked and which libraries are active.

Jbom's novelty was that it can generate SBOMs Statically or at Runtime for local and remote Java apps, so really there's no way to miss a dependency.

We detailed an example of how a SBOM enhances security and facilitates immediate alerts in Track Open Source Vulnerabilities With Google's OSV Database. At the time the Open-Source Vulnerabilities (OSV) database which provides:

"precise data on where a vulnerability was introduced and where it got fixed".

was new. As explained, OSV complements CVEs by extending them with precise vulnerability metadata , making it easier to query (using either package versions or commits). Furthermore it describes bugs according to a cleaner vulnerability schema. 

Google Security used SBOMs against the OSV database to find vulnerabilities in open source software which were then mapped onto a list of known vulnerabilities to know which components could pose a threat. The advantage of connecting these two sources of information was that consumers were able to know not just what’s in their software but also its risks and whether they need to remediate any issues.

As far Container security goes, the respondents also expressed concerns about high false positive rates when scanning containers for known vulnerabilities. One respondent opined:

False positive rates are extremely high with the current tooling to the point that the cost per averted vulnerability is quite elevated.

Another offered their frustrating experience with large container base images:

Our docker images are not that slim, so there is [a] lot of noise from packages in base images, so most findings are not quickly acted on. This works better if docker images can be slimmed down.

There's a solution to both those problems too. For instance, adopt the Wolfi Linux (Un)Distribution, a slim community Linux distribution that is built with the default security measures necessary for securing the software supply chain.

In the article "Wolfi Linux (Un)Distribution Secures The Software Supply Chain" we also found that :

What better than package all the work in an immutable container? Chainguard’s new Linux (un)distribution and build toolchain, Wolfi, is doing exactly that. It produces container images that meet the requirements of the secure software supply chain; that is images already provided with signing and sensible defaults.

The images created by Wolfi are produced with the minimal of components to the point of not even having a package manager. This is in order to minimize dependencies as much as possible and as such it simplifies auditing, updating and transferring images as well as reducing the potential attack surface.

Furthermore the images are signed, rebuilt daily from upstream sources and have an accompanying SBOM generated at build time. The signatures and SBOMs are stored in a transparent registry and can be queried with Sigstore's cosign tool.

Both these i-programmer articles align well with the surrey's findings.

Rebecca Rumbul Executive Director & CEO Rust Foundation, concluded:

It is clear from this report that, while security is seen as a priority, there is still some way to go to ensure that it is pursued coherently and efficiently

Kim Lewandowski, Co-Founder and Head of Product at Chainguard & Co-Founder of SLSA considered that:

The results of the first SLSA usage survey show me that while SLSA is helpful there is still a lot of work that needs to be done to integrate common software supply chain security practices into the development lifecycle.

We are definitely trending positively, but this report illuminates critical gaps and challenging areas that we can start addressing today to ensure a more secure software supply chain tomorrow.

What's needed, in essence? Tooling for one; tools must be easy to manage, like Sigstore is already doing (see links below), and two, education; tools mean nothing without documentation and training in applying them to real use cases.

The SLSA survey is certainly a step towards the right direction in identifying and then filling those gaps.

More Information

SLSA++ A Survey of Software Supply Chain Security (pdf)

Related Articles

jbom - Dependency Analysis For Java Apps

Protect The Software Supply Chain With Gitsign

Securing Your Software Supply Chain With This Free Course

Wolfi Linux (Un)Distribution Secures The Software Supply Chain

Sigstore Reaches General Availability

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info