Reduce risk to your supply chain with a software bill of materials (SBOM)

Today, we’re excited to launch a few new features as part of our ongoing efforts in our Software Supply Chain Security solution. These developer-first tools help you gain a better understanding of your app’s supply chain, identify potential risks, and take the necessary steps to get ahead of them.

The rise of SBOMs as a key part of supply chain security

Modern applications are more assembled than built, with free and open source software making up over 70% of modern software. Although using open source within your app can improve time to market, it can also introduce complexities and risks within your supply chain. 

In response to the recent regulatory guidance designed to help organizations protect themselves, many teams are adding software bill of materials (SBOM) creation to their SDLC. 

As a refresher, an SBOM is an inventory of the components that make up your application, along with their dependencies. You can think of this as analogous to the “bill of materials” used in manufacturing, which informs buyers about the parts used in a particular product. Standardized formats for SBOMs, like CycloneDX and SPDX, help make this inventory both human-readable and consumable by downstream tools.

For AppSec teams, this composition visibility across the enterprise is an important step towards understanding and mitigating risks of supply chain attacks, while remaining compliant with regulatory mandates. 

But how do you adopt these practices? And what’s the impact on your developer workflows? 

In the past, improving security posture may have slowed down development teams. But we’re firm believers that developers shouldn’t have to choose between innovation and security. Snyk makes it easy to produce an SBOM for your applications, giving you visibility into their building blocks (e.g. open source components, libraries, and frameworks) and how they work together. 

Now GA, Snyk provides developer-first CLI tooling to generate SPDX or CycloneDX SBOMs either locally or from your CI/CD pipelines. 

snyk sbom --format spdx2.3+json --all-projects

Using the Project SBOM API — also now GA — you can produce an SBOM for any open source or container project that you’ve imported to Snyk, from a single API endpoint. 

Example of a package within an SBOM

1{
2"bom-ref": "35-curl@7.52.1-5",
3"type": "library",
4"name": "curl",
5"version": "7.52.1-5",
6"purl": "pkg:deb/debian/curl@7.52.1-5?distro=stretch"
7}

Using SBOMs to identify risks and take action

Producing an SBOM is an important step in unlocking visibility and remaining compliant, but it’s only one part of the equation. SBOM artifacts often don’t provide actionable insights to downstream consumers. 

As a developer or AppSec professional, you also need to test SBOMs and their contents to identify potential issues and act on them faster. As SBOM generation becomes more widely adopted in your organization, and you begin to receive SBOMs from suppliers (e.g. SaaS), you’ll likely need to test various formats produced by various tools.  

You may even want to build a platform for managing this across all of your enterprise teams. 

Coming in early Q3, we’ll launch the beta of our SBOM testing feature. With this API, you can scan and test CycloneDX and SPDX SBOMs for known vulnerabilities and license issues in our leading vulnerability database.

And with the now GA Package Issues API, we provide you the tools to look up vulnerabilities at the package level based on the package URL (purl), with support spanning various language and operating system ecosystems. A granular, low-level API provides teams with the flexibility to tailor testing to their needs.

Example of getting issues for a package

You can look up a single package using a GET request and a URL-encoded purl:

https://api.snyk.io/rest/orgs/{{orgId}}/packages/pkg%3Adeb%2Fdebian%2Fcurl%407.52.1-5%3Fdistro%3Dstretch/issues?version=2023-05-10

Example of a returned vulnerability (truncated) 

1...
2"id": "SNYK-DEBIAN9-CURL-2936242",
3"type": "issue",
4"attributes": {
5"key": "SNYK-DEBIAN9-CURL-2936242",
6"title": "Out-of-bounds Write",
7"type": "package_vulnerability",
8"created_at": "2022-06-28T02:25:54.487787Z",
9"updated_at": "2023-02-14T13:32:10.421029Z",
10"description": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `curl` package and not the `curl` package as distributed by `Debian:9`._\n_See `How to fix?` for `Debian:9` relevant fixed versions and status._\n\nWhen curl < 7.84.0 does FTP transfers secured by krb5, it handles message verification failures wrongly. This flaw makes it possible for a Man-In-The-Middle attack to go unnoticed 
11...

Extending the value of SBOMs

Transparency into an application’s composition is independently valuable, but SBOM artifacts alone typically contain a limited set of information.

While that information is fine as an input to vulnerability testing as is, it leaves a lot to be desired — consumers of the artifacts still have to use the SBOM to get the insights they need.

Since we can create SBOMs and test them along with their components, why can’t this information be included in the artifact to begin with? With Parlay, Snyk’s latest contribution to the open source community, we’re aiming to solve exactly that. 

The leading formats (CycloneDX and SPDX) already offer extensibility in their schemas, which makes it possible to enrich an SBOM with additional metadata like vulnerabilities and source provenance.

This greatly benefits downstream consumers like AppSec teams who receive a point-in-time snapshot of an application, along with rich data to help automate actions or inform decision-making.

Check out this blog with more information on the possibilities this project opens up, and head over to the on-demand recording from SnykLaunch for all the details you missed.