Software supply chain security practices are maturing — but it's a work in progress

Many software supply chain security practices have been widely adopted, but there is still a lot of room for improvement, according to a recent OpenSSF survey of 167 software professionals.

The survey, put forward by the Eclipse Foundation, the Rust Foundation, OpenSSF and software supply chain security tool vendor Chainguard, focused on the Supply-chain Levels for Software Artifacts, or SLSA. Their goal was to assess the extent to which the participating organizations used SLSA and other software supply chain security practices, and whether they found those practices helpful. 

"It’s important to understand how individual contributors responsible for this work – like developers, open source maintainers and security practitioners – are adopting software supply chain security practices and guidelines," the OpenSSF report noted of the new White House National Cybersecurity Strategy, which urges organizations to use its best practices and frameworks for secure software development.

"The new SLSA++ survey provides insights into these trends, what’s working and what’s not working."

Daniel Kennedy, research director at 451 Research, described SLSA as a set of practical advice and evolutionary steps organizations can take to maintain code and build integrity throughout the software development lifecycle. "SLSA is a multi-level guide to ensuring software hasn't been tampered with and that a sort of chain of custody exists in the way software is developed," he said.

Here are the main findings from the survey, with key takeaways and insights from software supply chain experts on the overall state of software supply chain security.

Despite limitations, SLSA seen as essential

The SLSA framework is essential as a standardized approach to assessing the security and quality of software artifacts at each level of the supply chain, said Dennis Zimmer, co-founder and CTO of Codenotary.

"That helps to ensure consistency and reliability in software products and services. The component view from development to deployment helps to identify potential security risks and vulnerabilities at each level of the supply chain."
—Dennis Zimmer

However, the framework can be demanding on users and the results aren't always rewarding, said Pierre-Martin Tardif, professor of electrical engineering at Université de Sherbrooke in Quebec, Canada and a member ISACA's Emerging Trends Working Group.

"The implementation of SLSA requires a significant investment of effort. Indeed, there are many dependencies in the supply chain for most software artifacts, which can make the verification effort obsolete."
—Pierre-Martin Tardif

The survey found that the perceived difficulty of the practice had little influence on its implementation, stating that "The results suggest that where there is a will, there is a way." 

One key problem with the SLSA framework is its limited scope, said James McQuiggan,  an advocate at security awareness training provider KnowBe4. 

"It aims to support only the integrity of the software, not items like encryption or backups, relating to the other CIA triad of confidentiality and availability." 
—James McQuiggan

Frameworks like SLSA also come with lots of overhead, McQuiggan added. For one, the adoption of any framework means additional costs for tools, hardware, resources, and training. And addressing changes in the threat landscape is also a problem. "It will require the framework to be updated frequently, if not annually, to address any new threats to the software supply chain," McQuiggan said.

Provenance adoption is lagging

Many SLSA security practices already enjoy at least moderate adoption, the survey report noted. However, providing provenance, arguably a key SLSA-related practice, notably lags in adoption.

Guy Pearce, an IT and data consultant and member of the ISACA Emerging Trends Working Group, sees provenance as fundamental to software supply chain security governance. "As a consumer, one wants to know where one's food comes from ... and for an organization, where its data comes from."

"In the case of software, provenance is becoming of critical importance. One wouldn't want a piece of software — especially mission-critical software — that facilitates backdoor access or data transmission to unauthorized actors."
—Guy Pearce

Guillaume Ross, deputy CISO of JupiterOne, a provider of cyber asset management and governance solutions, said provenance is a key control of SLSA. "It allows us to ensure that artifacts were made by who we think made them, and that what is used is what we expect the software to use," he said.

One reason provenance adoption may be lagging is its complexity, said Zimmer. "Implementation requires an understanding of the software delivery lifecycle as a whole. The single software developer doesn't see the benefits as much as the cyber security teams."

"Knowledge of SLSA is not yet widespread enough among the developer community, and the framework, including the definition of provenance, is still evolving."
—Dennis Zimmer

The IT industry hasn't paid sufficient attention to provenance, said Chris Hughes, CISO and co-founder of digital transformation security company Aquia. "With malicious actors increasingly looking to pass on compromised packages and software, organizations now need to be much more concerned with provenance and the when, where, and how of their software consumption."

"It is important to the software supply chain to have this information because while publicly disclosed vulnerabilities such as Common Vulnerabilities and Enumerations (CVE) are useful, they are lagging indicators of risk. Provenance can provide insight into leading indicators of risk and help software consumers and organizations be more thoughtful about where the software they consume comes from."
—Chris Hughes

High false positives a big problem in container scans

The survey also noted respondents' complaints about high false positive rates when scanning containers. One respondent commented, "False positive rates are extremely high with the current tooling to the point that the cost per averted vulnerability is quite elevated."

Container scans can produce variable results based on which, in a myriad of tools, is being used and which vulnerability database is being consulted.

"Container security tools also may not take into account an application's context. They often are scanning container manifests and static artifacts, rather than running containers. That may lead to false positives due to that lack of context."
—Chris Hughes

Some of the false positives identified by the surveyed IT pros, though, may not be false positives at all, said Tim Mackey, a principal security strategist at the Synopsys Cybersecurity Research Center, noting that it’s somewhat of a mischaracterization to call these false positives. "A false positive implies that the vulnerability was misidentified, not that the vulnerability was present but isn’t in code that the software explicitly uses."

"If the team creating the container image doesn’t minimize the files in that image to only the necessary files required for the containerized application, then the vulnerabilities from those unused or unnecessary files will be returned."
—Tim Mackey

SBOM skepticism: No silver bullet

The survey also found some dissatisfaction among IT pros with software bills of materials (SBOM). "Generating SBOMs is not really difficult anymore, but what do I do with it afterward?” one of the respondents asked the surveyors.

Said another respondent: "This is the kind of paperwork that is tedious and disliked by everyone: Devs (because they have to write up and possibly defend their many random dependencies), management (because this introduces delays and unhappy devs), even legal (because it risks turning accidental infringement into willful)."

"Still," the respondent conceded, "being mindful of dependencies seems like the only good way to reduce the risk of supply-chain attacks."

Yet, a third respondent argued: "We can get vulnerabilities very easy [sic] without creating an 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."

Hughes said that there is a healthy skepticism about SBOMs. "They have received a tremendous amount of attention related to software transparency, software supply chain security, and addressing the information asymmetry that exists between software suppliers and consumers," he said.

"They also have been painted to some extent as a panacea, or silver bullet, and as many experienced in cybersecurity know, there's no such thing. They are but one aspect of bolstering software supply chain security."
—Chris Hughes

While SBOMs are an important piece of the software supply chain risk mitigation puzzle, Zimmer noted, standalone SBOMs are often not valuable. But not all SBOMs are created equal.

"SBOMs generated without any quality score or added information, such as vulnerability scanner information, and stored in a file server are not useful, but SBOMs in a database, quality checked, always updated and enriched with additional information, provenance data, and more makes them very powerful."
—Dennis Zimmer

Adopt software supply chain security as a practice

In their final analysis, the survey noted that software supply chain security need not simply be a meme, or headline news from a widespread compromise. "This survey, in fact, suggests that it is not — that some of these practices can already be found among some software organizations."

"The next step is understanding how to make these and related practices the default option and, ideally, so commonplace as to no longer merit meme status."

Matt Rose, Field CISO at ReversingLabs, wrote recently that tools and frameworks for securing software supply chains are only part of the picture. Software supply chain security is an evolution of application security, he noted. 

Software supply chain security needs to be recognized for what it has become: A separate discipline within the application security ecosystem.