Tackling Supply-Chain Security in Regulated Industries

The threat of software supply-chain attacks has been looming over the software industry in mellow silence. This all changed when Solarwinds was hit with a large-scale, software supply-chain attack that resulted in at least $100 Billion in recovery costs. This woke up the industry to the threat and enterprises scrambled to patch the vulnerability. But, the unknown remains—what damage did they do before the vulnerability was patched? Hacker attacks are increasing because infecting a single, commonly used software component can potentially allow unauthorized access to all enterprises that use that software component. Even worse, enterprises might not be aware they are vulnerable, because the software component or dependency came packaged in a software they trust.

Recent, more-prominent vulnerabilities such as Log4J and Spring4Shell are just the start of the storm. Based on the recent 2021 State of Software Supply Chain report by Sonatype, supply-chain security attacks are increasing at an unprecedented rate. In the United States, President Biden issued an Executive order to improve the nation’s cybersecurity that specifically called out the threat of software supply-chain attacks and required private and public vendors to act based on NIST’s Secure Software Development Framework (SSDF) and related Software Supply Chain Security Guidance. Based on this order, software suppliers that provide services to federal agencies are required to comply with secure-software development requirements and meet the supply-chain security guidance or they will not be allowed to sell to the federal government. Federal government, military, and banks are few of the regulated industries that have been scrambling to tackle the supply-chain threat.

With the importance and impact that software supply-chain threats can have, what can regulated industries and organizations do to protect themselves? This is where the open source community is coming together to provide recommendations, best practices, requirements, and tools. In the next few sections we’ll discuss how this all comes together and can help prevent such attacks in the future.

Standards to secure your supply chain

Supply-Chain Levels for Software Artifacts or SLSA is a security framework that provides a check-list of standards and controls to help improve an organization's software supply chain. It introduces levels of assurance that can be used to gradually secure your supply chain, as shown below:

Each level that an organization obtains brings them that much closer to detecting and preventing compromises or effects from supply-chain threats. Next, we’ll go deeper into the actual implementation, and look at two key terms used by SLSA and the tools that implement the different levels.

Based on the official definitions from SLSA:

• Attestation: Authenticated, machine-readable metadata about one or more software artifacts.
• Provenance: The verifiable information about the software artifact that describes where, when, and how something was produced.

Using these definitions, we’ll look briefly at the actual levels shown in the table above. The full list of requirements is quite long, so we’ll discuss the major ones.

• Level 1 should be the easiest for all organizations to adopt. It requires scripted builds and generation of provenance.
• Level 2 adds hosted source/builds, version control, and signed provenance. This level is a little harder for organizations to do, but still relatively easy.
• Level 3 is where things started to get complicated. It includes hardened infrastructure, ephemeral environments, builds-as-code, and non-falsifiable provenance.
• Level 4 introduces more controls, but most importantly—a hermetic (air-gapped environment) and reproducible builds. This level is the hardest to obtain for any organization, because it requires changes to infrastructure, policies, and more stringent controls.

What do I do now?

The question a lot of organizations (especially regulated ones) are asking is, “What do I do to protect myself against such threats?” Meeting these requirements is nothing trivial for a large organization to follow. To this end, the open source community has been hard at work to create the tools and integration needed to meet the SLSA which also help achieve NIST’s SSDF.

There are multiple tools out there in the ecosystem, but we’ll focus on a few that have been paving the way. The first is Sigstore and another is Tekton. Sigstore contains multiple tools that can help organizations do signing (cosign), provide a public CA that can be used for signing (fulcio) and a transparency log (rekor). Tekton Pipelines, first and foremost, is a cloud native CI/CD system (CI/CD Pipeline) that can be used to build, test, and deploy across cloud providers and on-prem systems. In conjunction to this pipeline, there is another tool, a sort of third-party monitor, known as Tekton Chains, that keeps track of the pipeline and adds the ability to do signing and attestation generation.
Components of the CNCF Secure Software Factory reference architecture

Based on the CNCF The Secure Software Factory reference architecture, there are still components missing. Looking at the figure above, we’re still missing components such as policy framework, admission controller, and run-time visibility. An OpenSSF project known as FRSCA (as in Salsa Fresca), aims to provide a full-reference architecture based on the best practices provided by the CNCF white paper. While FRSCA it is still a work in progress (missing the runtime-visibility piece) it integrates the various components to provide enterprises and organizations a way to implement the tools together to meet the requirements set forth by SLSA (which in turn meets the SSDF). With the current tool and feature set, it provides the ability to meet SLSA level 2. Features are in the works that will be added in the coming month that will bring it up to SLSA level 3.

How does FRSCA meet SLSA?

You may be asking, “How do all these tools help organizations meet SLSA?” We’ll next dive into a deeper understanding of what each tool brings to the table within FRSCA and how they all integrate to help us solve the “build” piece of software supply-chain security.

• OCI Registry - Open Container Initiative registry that is used to store images and other types of artifacts.
• Cosign - provides the ability to sign, verify, and store in an Open Container Initiative (OCI) registry. The signature is stored with the image being signed in the OCI registry such that when a user pulls down the image, they can validate it themselves.
• Fulcio - a public root CA that provides the basis of container signing used by Cosign.
• Rekor - a transparency and timestamping service that records signed metadata to a ledger that can be searched, but can’t be tampered with.
• Tekton Pipelines - the CI/CD system where multiple tasks can be combined together into a pipeline to meet the organization's objectives.
• Tekton Chains - monitors Tekton Pipelines and adds in the ability to sign the images being created (internally using cosign) and create SLSA compliance provenance.
• Kyverno - an admission controller that can be used to inspect incoming artifacts to ensure they match a specific policy to secure the build system based on the best practices. This relates to the admission controller block shown in the diagram above.
• SPIFFE/SPIRE - provides short-lived attested certificates that can be used to secure the build system from tampering. This relates to the workload attestor and node attestor seen in the diagram above.
• CUE - a language which can be used for defining, generating, and validating all kinds of data. In FRSCA it is used for validation and policy enforcement.

Now that we’ve explored the various tools, we’ll show how they help meet the different SLSA levels. The table below maps out the different requirements per SLSA level and how they are met by FRSCA.

As you can see from the table, the tools that are integrated via FRSCA come together to meet the various requirements. The FRSCA repository contains various examples that can be run to show all the tools instantiate together (via CUE configuration) and create an image and provenance that can be validated by Cosign.

Regulated environments slow to embrace

Regulated industries such as a financial institution or a government/defense agency need to take the software supply-chain risk very seriously. They have the most to lose if they are ever exposed to such an attack (this was made apparent by the Solarwinds and Log4J that caused a massive stir in the industry). The attack vector and possibility of being vulnerable is very high to ignore, yet it seems like cybersecurity is always viewed as a hindrance or an afterthought. Senior members of the organization have to be educated about the severity of the problem before it leaves their organization crippled. While recent events and mandates by the government have opened some eyes in organizations, others seem complacent to continue as things are.

Supply-chain security is not something that will replace traditional security and continuous monitoring, but has to be implemented to secure the software artifacts being produced and ingested. FRSCA aims to provide an architecture that can be instantiated quickly within an organization and help them meet requirements set forth by SLSA. This can be easier said than done in slow-moving regulated industries, but steps still need to be taken to begin this journey as soon as possible. The open source community can provide guidelines and tools to ensure security in regulated industry’s software supply chain, but in the end it’s up to the industries to decide their path.