Securing your SBOM on Google Cloud

Over the past few years, software supply chain security has been top of mind for governments and businesses alike. Following Log4Shell in late 2021, the Biden administration’s National Cybersecurity Strategy started focusing on open source supply chain security. 

The National Security Agency (NSA) recently released new guidance on securing open source software supply chains. This new document provided recommendations on managing open source software (OSS) and maintaining a software bill of materials (SBOM). 

Securing the software supply chain is getting attention for a good reason. The number of software packages affected by supply chain attacks started at around 700 in 2019 and increased to more than 185,000 in 2022. 

As development teams consider how to respond to NSA’s new guidance, especially regarding cloud environments such as Google Cloud, they need to find partners who can help them on their journey and tie these best practices back to an iterative DevSecOps model.  

A breakdown of NSA’s recommendations 

This new recommendation document, entitled Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bill of Materials, centers around four main topics of security:

1. Open source software management

2. Creating and maintaining secure open source repositories

3. Open source maintenance and crisis management

4. The creation and validation of SBOMs

Let’s cover a few of the recommendations for developers that they mention in this document. 

Open source software management

This document assigns the developers most of the responsibility for managing open source software. They must choose the best OSS options, check for licensing/vulnerability issues, add it to their development lifecycle, and create an SBOM.

The NSA recommends several practices when using open source software in your development process, including:

• Selection: Evaluating OSS properly to choose the most secure options

• Risk assessment: Fully understanding any risks associated with each chosen OSS

• Licensing: Following the set obligations and constraints required by any licenses

• Export control: Adhering to export regulations that apply

• Maintenance: Upkeeping an internal secure repository

• Vulnerability response: Creating a set process for finding and fixing novel vulnerabilities

• Secure software delivery: Double-checking a final deliverable’s contents with binary composition analysis before shipping  

Creating and maintaining secure open source repositories

The NSA dedicates a section of its recent publication to recommendations for creating an internal secure repository.

Their two recommendations for maintaining this repository include:

• Establishing an OSS adoption process that makes sense with your organization’s size and available resources.

• Conducting vulnerability and risk assessments before and after adoption, then using these assessment results to decide which components to use or which need to be reverted or updated to more secure versions. 

Open source maintenance and crisis management

Open source software previously known as secure and approved for an internal repository can still be susceptible to zero-day vulnerabilities. Organizations should also consider ways to find and address these new risks within their chosen OSS. 

Businesses can create a continuity plan for finding and fixing new open source vulnerabilities and threats with the following recommended practices:

• Leveraging reliable intelligence to find out about emerging threats. 

• Using an SBOM to locate vulnerable components across libraries.

• Following a process to remediate the vulnerability, such as updating it to a fixed version or reverting to an unaffected version.

• Setting up a crisis management plan ahead of time for responding to a significant software issue and providing timely information to stakeholders.

The creation and validation of SBOMs

The document also emphasizes the importance of SBOMs — creating and updating them and making them accessible to the right people and tools. 

NSA highlights a few characteristics of a successful SBOM:

• Details on components, versions, licenses, and dependencies

• Integration into the pipeline with security techniques like software composition analysis (SCA)

• Automated extractor tools to make it easier to discover and update components across the entire SDLC

• Quality assurance and validation to ensure that the SBOM data is in the correct format for developers to integrate it into tools and automation

How Google Cloud users can adhere to these recommendations with Snyk

These processes might sound like an extra burden on your development teams — but they don’t have to be. Snyk’s open source security management makes it seamless to find and fix vulnerabilities in your existing open source components, scan pull requests for insecure components before merging, and create enriched SBOMs. Thanks to Snyk Open Source, our SCA tool, 99% of Snyk customers affected by Log4J fixed the Log4Shell vulnerability within three days. In leveraging Snyk’s developer-first security platform, you can more easily adhere to federal security guidelines by:

• Finding vulnerable dependencies as you code, directly in your IDE or CLI.

• Testing your projects directly from the repository before merging, and monitoring them daily for new vulnerabilities.

• Adding an automated Snyk test to your CI/CD pipeline to prevent new vulnerabilities from passing through the build process.

• Testing your production environment to verify that there is no exposure to existing vulnerabilities.

• Generating SBOMs with enriched information from Snyk on each open source package including license details, external links, maintainer information, and more.

In addition, Snyk works with Google Cloud to ensure the security of software supply chains, integrating with the Google services you use to build and run your apps, including :

• Google CloudBuild. Snyk scans all the packages in your projects and provides automated fix advice. 

• Google Artifact Registry (GAR). Snyk scans your containers for vulnerabilities and tests your base images.

• Google Kubernetes Engine (GKE). Snyk enables you to import and scan running workloads, identifying vulnerabilities in images and configurations. 

With these integrations, teams building modern, containerized apps on Google Cloud can ensure their SBOMs are validated and secure their software supply chain without leaving existing environments. 

Customer can also use their existing billing mechanisms with Google to purchase Snyk software directly from the Google Cloud Marketplace. 

Read about how Snyk helped the team at Kroger secure their supply chain to learn more.