Securing open-source code supply chains may help prevent the next big cyberattack

The headline-making supply chain attack on SolarWinds late last year sent a shock wave through the security community and had many CISOs and security leaders asking: “Is my software supply chain secure?”

After months of analysis, we know that many (some might argue most) organizations are vulnerable to supply chain attacks. In a business world in which we all have so many third-party dependencies, no organization is an island, and no one is immune. The SolarWinds incident is an example of a software supply chain attack in which compromised code was pushed to run in customer environments. As a result, many of SolarWinds’ customers were also impacted, including several Fortune 500 firms. This scenario is one of a few ways a supply chain attack can occur.

Of course, the next logical question is: How can I best defend against this kind of incident? The starting point of protection is knowledge. Know what is in your software by mapping your software supply chains. As part of this visibility and understanding, another pressing question CISOs and DevSecOps teams need to address is their dependencies on open-source components in the development pipeline.

Open source is the “low hanging fruit” for criminals

Open-source components have become an essential part of development for obvious reasons. Open-source components exist in all types of software today – even proprietary software. It is simply the nature of the beast of how software is developed. Development teams are continuously using open-source packages and containers to move innovation forward and push new code.

In fact, the 2021 State of Software Supply Chain report from Sonatype, IT Revolution, and Muse.dev reveals the top four open source ecosystems released a combined 6,302,733 new versions and introduced 723,570 new projects in the last year. The report states that these communities now contain a combined 37,451,682 different versions of components, representing a 20% year-over-year (YoY) growth in global supply. But this growth also means as open source becomes more pervasive, so does criminal interest in trying to exploit it. The Sonatype report finds attacks aimed at actively infiltrating open-source code increased 430%.

“[Members] of the world’s open-source community are facing a novel and rapidly expanding threat that has nothing to do with passive adversaries exploiting known vulnerabilities in the wild—and everything to do with aggressive attackers implanting malware directly into open-source projects,” the report’s authors state in the research.

It’s the very nature of what makes open source so valuable that also makes it exploitable. Unmanaged, with no clear oversight, open-source repositories can be compromised. And the software industry does not currently track the source of all code, nor does it grade the level of security standards applied in these international code factories. Anyone with good or malicious intent can easily insert their code into a repository. Because open-source software often contains vulnerabilities, attacks have increased on this “lowest hanging fruit.”

Keeping track of open-source dependencies is a mind-boggling task. But security leaders must know where developers are getting their open-source and third-party packaged code, containers, and infrastructure as code.

How can companies better manage risk from open-source supply chains?

From the top of an organization and throughout IT, everyone should be asking about the security level of open-source code that is being used in development. The following three key steps can help give companies more visibility into open source:

1. Create and maintain a software bill of materials (SBOM)

Recently mandated by the Biden administration for organizations that want to work with federal agencies, SBOM is a tool all organizations should incorporate into their security strategy. An SBOM is the equivalent of a list of software ingredients in your environment.

2. Map it out

You can’t secure what you can’t see. Companies need to perform provenance mapping determining the level of security from where the code was created.

3. Use a software security grading system

Establish a grading scale to rate each piece of code to more effectively determine the risk a company is inheriting from the code. This is essential to obtaining a level of confidence in the code you are using in your environment.

Parallels can be drawn with the FDA process for approving drugs by inspecting the ingredients and the factories where a drug was made.

Google takes the first step

Google has set a quality example for grading open-source code repositories. Known as repo scoring, Google ranked more than 200,000 open source code repositories one to 10 using the Google Scorecard program to determine the security hygiene of these “code factories”. This data can be used to understand the provenance risk of every component in the SBOM.

However, for a company to replicate Google’s efforts internally at scale requires significant manual resources that will increase friction between developers and security teams. Leveraging this fantastic Google Scorecard data at scale is a herculean task: for every one of the millions of pieces of code in your environment’s SBOM you would have to:

• Identify its provenance (from which repository it came from)
• Scan this repository with Google Scorecard, as well as all the repositories it’s dependent on.

Developers want to innovate, build, and push code while the security team wants to ensure that code is secure. Automating the DevSecOps process can remove many of the manual steps necessary to secure code. It automatically builds the SBOM, understanding provenance, and can easily be used to include security ratings about the provenance sites to the SBOM.

Standardization, collaboration, and transparency

These early steps by Google are just the beginning of what the industry needs to be doing. As a collective software industry, we need to ask ourselves how we can create and document standards for code repositories and make them publicly accessible, so the risk of the code is clear for any company that wants to use it.

This process should include creating the security standards, a grading scale aligning with the standards, and a public mechanism to be transparent about the grade. These frameworks are a necessity as Google’s Scorecard program does not cover the entire open-source code universe, not to mention closed repositories used by vendors to develop their own code.

The more companies, large and small, that begin this process will foster greater collaboration in the industry, boost confidence in code supply chain integrity, and should be a positive force towards reducing major cyberattacks.