Cybersecurity regulation and the software supply chain

It’s standard practice for software companies to use existing software components as building blocks for their new products. But what happens when those building blocks contain vulnerabilities that can be exploited by malicious actors? Recent cybersecurity breaches like the one at Solar Winds have attracted the attention of regulators, and that means software organiztions are going to have to get serious about governance and risk.

The problem with building new software out of existing software

In today’s world, building new software usually starts with exisiting software components someone else has written. This includes open source software, but many companies also sell closed-source technology or open their source code to the world while offering a support package. This software includes, but is not limited to, source code, compiled binaries, and other software artifacts. It’s really useful because it solves everyday problems and allows engineers, companies, and organizations to focus on creating new value and assets.

No software is perfect. All software is vulnerable to nefarious actions, whether open-source or closed-source. And the proliferation of open-source, and of buying source code and complied artifacts, presents bad actors with numerous opportunities to cause mischief. The effects of this mischief compound when consumer products are affected, and it’s not easy to trace this software back to its origins.

How do we make software traceable to its source code?

Today’s focus on the software supply chain is based on the idea that all software must be directly traceable to its source code. Provenance is the record of existence, the known history of something. Pedigree is similar to provenance, given both words concern themselves with the origin and history of something. But pedigree is different because it considers the quality of something and its history.

The proliferation of software supply chain tooling focuses on establishing an artifact’s pedigree. Projects such as SigStore provide pedigree points with signature and key transparency. Signature and key transparency are critical to establishing trust. But this capability is just one piece of a larger story.

Ultimately, what is required is the capability to track the evolution of a software artifact from its origin to its current state. The bigger picture requires the capacity to tie secondary artifacts, data, and decisions to the software artifact. Which brings us to secondary artifacts.

What are secondary artifacts? Trust, but verify.

Secondary artifacts are outputs from the process of validating the quality of a software artifact. These artifacts include, but are not limited to, evidence generated by tools describing a software artifact’s security or compliance aspects. 

Examples of this evidence are scan results from static and dynamic code analysis, or compliance tooling such as a Security Techincal Implementation Guidance (STIG).  Still, scan results, in and of themselves, are not enough.  

The most potent form of secondary artifact is the documentation of how one evaluated the data. This evaluation is critical as it allows others to see how an individual or organization determined others could trust their artifact. 

These artifacts are essential to making the best downstream decisions. Secondary artifacts allow any disinterested 3rd party to establish an independent analysis for trust. Secondary artifacts are the epitome of “trust, but verify.”

Get ready because the regulators are coming

In short, regulatory bodies all over the world are starting to pay serious attention to the way software is built and ultimately delivered to customers. And that means technology companies are going to have to be able to meet new regulations concerning the provenance of the software in their products and services.

In the USA, the Solar Winds episode and Colonial Pipeline hack are credited with alerting the US government to the vulnerablitiies inherent in software and the need to mitigate against them. In early 2021 the Biden administration issued an Executive Order on the subject of cybersecurity. The European Union followed suit in 2022 with the NIS2 directive, designed to improve risk and cybersecurity posture across the EU27.

And in early 2023 cybersecurity was the hottest topic at the annual WEF forum in Davos. In fact, one explosive WEF report predicted a “catastrophic mutating” cybersecurity event will take place at some point within the next two years.

It’s clear that these regulatory trends will mean that software organizations are going to require a much more robust and reliable approach to governance, risk and compliance. Finding effective ways of gathering secondary artifacts will be an essential part of an organization’s security posture.