Google pairs GUAC with SLSA to take a bite out of software supply chain insecurity

Knowing a vulnerability’s blast radius would be super helpful. Software Bills of Materials (SBOMs) and SLSA are fine — as far as they go — but there’s a need to bring thousands or millions of sources together into one, universal graph that’s easily queried. As software supply chain risks become more and more acute, knowledge is power.

It’s an open source project. In this week’s Secure Software Blogwatch, we go to GitHub and check it out.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: You can’t handle the truth.

Get a free SBOM and supply chain risk analysis report

Dip into this tasty repo

What’s the craic? Howard Solomon reports — “Google announced a way to help”:

“An open-source project”
IT and security leaders need to know what’s in applications to be able to judge their level of risk. [Google] has created a project called the Graph for Understanding Artifact Composition.
…
The goal is to help developers create metadata about their applications that describe the software build, security and dependencies. There already are several efforts, such as the ability to create signed attestations about how software was built … and software bill of materials generators.
…
GUAC would bring together different sources of software security metadata into a graph database. This is an open-source project on GitHub.

More detail please. Jaikumar Vijayan expands on that neat summary — “GUAC Aims to Democratize Software Supply Chain Security”:

“Potential weaknesses and vulnerabilities”

The trend is driving organizations to … requiring a software bill of materials (SBOM) for their software and to using … Supply chain Levels for Software Artifacts (SLSA). [GUAC] could move the needle forward on industrywide efforts to address software supply chain security. … Once available, [it] will give developers, security teams, auditors, and other enterprise stakeholders a central source for information about the security, provenance, and overall trustworthiness of the individual components in their … codebases.

…

According to Google … software and security teams … will be able to query GUAC for information on … their software, associated dependencies and any potential weaknesses, and vulnerabilities in them [and] determine if an application they are about to deploy meets organizational polices, and if all binaries in production can be tracked back to a secure repository. … For instance, when a new vulnerability is disclosed, organizations will be able to use GUAC to determine which parts of their software inventory might be affected.

GUAC? Surely there’s a childish easter egg in the acronym? Brandon Vigliarolo obliges — “Slap some GUAC on your software supply chain”:

GUAC is designed to [use] a variety of sources, including … SLSA (pronounced "salsa").

…

You can try it out – or inject some of your own helpful code – now.

The horse’s mouth? Google’s Brandon Lum, Mihai Maruseac and Isaac Hepworth — “Announcing GUAC”:

“We’ve teamed up with Kusari, Purdue University, and Citi”

[We’re] seeking contributors to a new open source project called GUAC (pronounced like the dip). … GUAC addresses a need created by the burgeoning efforts across the ecosystem to generate software build, security, and dependency metadata [and] to democratize the availability of this security information by making it freely accessible and useful for every organization.

…

Thanks to community collaboration in groups such as OpenSSF, SLSA, SPDX, CycloneDX, and others, organizations increasingly have ready access to … SBOMs … SLSA [and] vulnerability databases. … But it’s difficult to combine and synthesize the information for a more comprehensive view. The documents … cannot be easily aggregated to answer higher-level questions about an organization’s software assets. … To understand something complex like the blast radius of a vulnerability, one needs to trace the relationship between a component and everything else in the portfolio. … In the open source ecosystem, the number of documents could reach into the millions.

…

We’ve teamed up with Kusari, Purdue University, and Citi to create GUAC, a free tool to bring together many different sources of software security metadata. We’re excited to share the project’s proof of concept. … We welcome help and contributions of code or documentation.

ELI5? Terretta explains like we’re 5-ish:

Graph for Understanding Artifact Composition (GUAC) aggregates software security metadata into a high fidelity graph database—normalizing entity identities and mapping standard relationships between them.

Querying this graph can drive higher-level organizational outcomes such as audit, policy, risk management, and even developer assistance.

Clear as mud. Jacques Chester takes a step back — “Requirements for a Universal Asset Graph”:

“This problem is already bad”

We are blind: Take a piece of software and try to learn its true and complete provenance. It doesn't exist, it never has. So far, the profession of software and the society which depends on it have gotten by on goodwill and … good luck.

…

This problem is already bad; as more and more things become programmable, it will grow to truly catastrophic proportions. … How do we know what systems are affected by an attack? How do we know to trust a given software asset? How do we update the state of our knowledge as new information comes in?

…

SBoMs are fine as far as they go, but they are necessarily a best-effort snapshot. … I see in-toto in the same role as SBoMs.

But is it any good? Gravis Zero calls it a “Step in the right direction”:

Despite being a Google project, this is something that is actually good. However, it appears they completely lack any way to determine the level of dependency on a library/project, only that a dependency exists. Reducing your number of dependencies means there are fewer things to go wrong, so if you can entice a project to remove a needless/redundant dependency then your software is less likely to be vulnerable.

It's shameful how many projects pull in needless dependencies. … It would be nice if corporations started promoting dependency reduction.

Tune in to KubeCon tomorrow. Mihai Maruseac and Michael Lieberman present — “It's Dangerous To SLSA Alone Out There”:

“We built a supply chain knowledge graph”

By now, we’re getting bored of hearing the “am I affected by X vulnerability?” question. However, as supply chain attacks become more sophisticated, answering just this question is insufficient.

Instead, we need to think … “If TravisCI was compromised, which software is affected? With a bad actor in your supply chain, what's the blast radius?” There is a ton of information today in SBOMs, in-toto/SLSA attestations, etc. However, these documents observed individually provide limited information, but when put together and related, super-additively expand the knowledge base of our software supply chain.

We built a supply chain knowledge graph tool to help better understand the relationships between artifacts and their metadata/identities. Through this high-fidelity graph, we not only answer the hard questions posed earlier, but also make new discoveries. For example, we found that most build-systems rely not only on obvious dependencies like gcc, but often overlooked projects like libpcre and sed.

Meanwhile, fidodogbreath suggests a better oh-so-clever acronym — for real:

Should have called it Comprehensive Hyperscale Incremental Processing Of Tokenized Log Entries.

And Finally:

A few good toys

Previously in And finally

You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Juan Manuel Giraldo Grisales (via Unsplash; leveled and cropped)