As everyone is getting progressively more aware, protecting your software supply chains should be a vital part of every organization’s cyber security strategy.
One of the main difficulties in creating a comprehensive strategy to mitigate software supply chain threats is the complexity and diversity of supply chains. Each supply chain is unique, and the elements involved are constantly changing, making it difficult to trust your own supply chain, let alone the software it produces.
In this article, we’ll describe a continuous compliance platform that enables software consumers and producers to transparently demonstrate trust and compliance to secure SDLC, promote security best practices, meet regulatory requirements, and mitigate cyber risks using attestations.
Our proposed model consists of set blocks that can be easily extended and integrated into your stack, regardless of your preferred platform or use cases. We’ll end by demonstrating a basic verification policy using Scribe’s Valint tool to show that this process isn’t as complicated as you might first fear.
Supply Chain Chaos Theory
One of the main challenges in securing supply chains is the sheer complexity of the systems involved. Your software supply chain includes every piece of software involved in the creation of your final product, either as part of the environment or as a piece of software integrated into your code base. You can tell by this description that these supply chains are vast and include everything from the moment a developer starts to write code all the way through compiling, testing, integrating, and up to the point where the final product is running and incorporating every piece of software and library used along the way.
Defining the security model for such systems requires understanding the vast array of programming languages, package managers, products, technology stacks, CI services, cloud providers, dependency imports, VMs, operating systems, and other components that may be included in a given supply chain. It’s essential to consider the wide range of assets that could be at risk within such a system, including applications, tokens, keys, and other forms of access permissions.
Overview of the Policy Verification Model
Our proposed model includes several building blocks that work together to ensure the security and compliance of a supply chain. These building blocks are needed for continuously verifying software security aspects and compliance with software supply chain regulation.
- Evidence: Immutable objects that are intended to be consumed automatically by the policies. These objects contain metadata needed to enable policy enforcement and to meet compliance requirements. Evidence content includes metadata about artifacts, events, and settings, but can also collect actual reports, configurations, or scans.
Evidence may come in both a signed and unsigned form. We suggest following the in-toto attestation spec utilizing the signed attestation and unsigned statement formats, respectively.- Attestations (AKA verifiable signed evidence): Verifiable evidence linked to a specific environmental context, conveying trust using some form of PKI signatures.
- Environmental context: The contextual information ties the model together.
It answers the question of where the evidence comes from and what information it contains. It’s important that the context is linked to the evidence rather than being a part of it, since you can have multiple pieces of evidence linked to the same context and this model allows for easier, more efficient, search and retrieval of evidence.
In basic terms, an environmental context is a labeling system where most of the labels are read from the environment, platform, or artifacts. Labels provide normalized access to many processes of your development process and CI/CD pipeline. Aspects related to the origin of the evidence such as Git repositories, tags, and commits, but also workflow names, job names, runID, and so on. Environmental context can also include aspects of the subject, such as artifact hashes, names, and tags.
Context can be viewed as an extension of the in-toto Attestation spec, integrated into the signed payload. Using the labeling system, we can provide the policy evaluation phase with a way to query evidence by labels in a range of aspects. In addition, the context data can be used as part of the policy evaluation process, adding “situational awareness” to the evidence.
- Policies: A set of user-configured policy modules that define the required compliance report. Policies may specify the minimum security standards or the required levels of compliance for different types of products or systems included in your build pipeline or your development process. Most importantly, the resulting policy evaluations create compliance reports which are attestations as well. This allows us not only to manage the compliance reports – e.g., exposing your compliance status to stakeholders – but also utilize the compliance report for more complex policies that may encapsulate a larger scope of compliance regulation for an organization. Policies can be grouped into policy modules. These are plugins which implement sets of policy rules that share some characteristics (similar to software modules). These plugins are provided by Policy Providers (more on that later).
Evaluation of a policy module provides results that include valuations, compliance details, and verdicts referring to the security regulation in question. Furthermore, results include the history trail of evidence needed to backtrack the evidence module evaluated for compliance. - Stores: Services providing hosting, upload/download, and querying capabilities for evidence (more on this later). They can be utilized over Image registries (OCI as storage), dedicated services (i.e., Scribe Service), or simply the local file system.
- Policy Providers: These are entities (companies, organizations) responsible for signing and providing policy modules. By providing policies as a type of attestation, providers convey trust and transparency to the policy itself. For instance, an OPA Bundle Attestation can empower regulators to publish and sign official OPA bundles implementing policy modules.
By utilizing these building blocks, our model enables organizations to verify the security and compliance of their build pipelines and development lifecycle with relative ease.
How Does it Work
The starting point of this workflow is a developer or a system, generating evidence for a software product or component. The evidence content, as well as contextual information, subjects, and signatures, are collected and uploaded to an evidence store.
On the flip side, compliance reports are created by evaluating policies fitted to the organizational needs and requirements.
Using contextual information, policy evaluations can query evidence produced by your supply chain and ensure that they contain all the information that regulation might require.
As an additional benefit, policies and compliance reports are themselves accessible as evidence, providing transparency and trust as well as a history trail back to all evidence involved. This allows organizations to manage compliance reports but also to use them as trusted attestations to convey trust to software consumers.
By utilizing this flow, organizations and stakeholders can reduce risk, provide transparency, and ensure compliance within their supply chain, reducing the impact of chaos and improving the overall security and trust in their products.
Policy evaluation
The evaluation of a policy is done by verifying a set of policy modules, each one upholding specific regulations and compliance needs.
A policy evaluation asks each module two simple questions:
- What evidence is required to comply with the module?
- What are the criteria for the evidence to prove compliance?
For example, in the context of the SLSA (Supply Chain Levels for Software Artifacts) framework, policy modules might specify that signed SLSA provenance evidence and a security posture scan for the build pipeline are both required to comply with the security requirements. The evidence provided by these modules would then be verified to ensure that it meets all the SLSA requirements.
- What evidence is required to comply with the SLSA requirements?
- A SLSA provenance attestation (signed evidence) of the build artifact.
- Security posture scan of the CI pipeline producing the artifact.
- What are the criteria for the evidence to prove compliance with the SLSA requirements?
- Both pieces of evidence must include information that meets all the SLSA requirements.
For this example, the SLSA provenance attestation needs to describe your image build process in its entirety, while the security posture attestation needs to verify that the SCM that stored the image’s source uses branch protection rules.
- Both pieces of evidence must include information that meets all the SLSA requirements.
Another example of a policy module is the Verify Artifact module, which specifies that some artifacts must be signed by a trusted source. Utilizing attestations (verifiable signed evidence) PKI (Public Key Infrastructure) signature, to comply with the requirement of some specific person/entity that needs to sign the artifacts and as well as attesting to the context of where the artifacts originated from.
The Verify Artifact module answers the following questions:
1. What evidence is required to demonstrate compliance with the security requirements?
- Evidence describing an artifact that includes a PKI signature (attestation).
2. How can this evidence be verified to ensure compliance?
- Attestation PKI signature is valid.
- PKI Certificate identity matches user requirements.
- Subject of the evidence matches the user requirements.
- Format and origin match the user requirements.
From Theory to Practice
Let’s delve into the implementation of this model that is currently supported by the Valint tool.
Let’s look at a simple example of a policy that specifies how to verify an image’s signatures and origin.
Specifically, we need to verify that the evidence satisfies the following criteria:
- The evidence type is CycloneDX SBOM attestation describing an image.
- The artifact is signed by mycompany.com.
- The image originates from a Circle-CI workflow triggered by the my_image_src repo.
Template Policy
In the previous example, the policy was static and only checked for a specific image named mycompany/my_image. However, it’s often preferable to have policies that support template/variable capabilities. This allows you to define requirements that can be applied to multiple similar processes or artifacts in your CI/CD build pipeline.
To template the policy, you can use a variable instead of locking the policy statically to a product. In the above example, you may change the artifact_name value to `$MY_IMAGE` instead, allowing evaluators to configure one policy for a multitude of images requiring the same compliance regulations.
Looking Forward
At Scribe, our ultimate goal is to mitigate risks in the supply chain through a verifiable compliance model that is evidence-driven. One of the first places to try this model out is in your CI/CD build pipeline. We believe that this evidence-verification approach is the key to ensuring transparency and accountability in the supply chain, with benefits to all stakeholders involved. Our model encapsulates many of the emerging ideas in the software supply chain community, defining the relationship between many of them. We are committed to innovating and improving software supply chain transparency. If this model piqued your interest, I encourage you to check out our Valint CLI documentation where we expand on the tool’s capabilities and uses. Feel free to try it out.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
