9/7/2021
What is a supply chain attestation
Author: Cole Kennedy
You may have heard about Software Supply Chain Security and might be wondering why you should start providing or using attestations to increase the security of your software supply chain.
Why do I need to provide attestations for my software?
It is clear that the federal government is getting serious about supply chain security. There are efforts around legislation, executive order, and rule making. NIST, CISA, and the Department of Homeland Security are currently hard at work developing controls that will make it into critical infrastructure regulation. NIST currently has a draft of NIST SP 800-218 published. All of these documents point to one thing: requirements for software producers to provide verifiable proof of the quality of their software. We call this an attestation.
What can I do with an attestation?
An attestation is a piece of data representing proof of an event. In the real world, we generally call these certifications. For example, when a lab tests your blood data about the test is recorded and certified.
- Environment: What lab is the test is taking place in, and on what date.
- Process: What machine is performing the test. what are the configuration details of that test.
- Materials: Who's blood is going into the test. Is the chain of custody verified?
- Artifact: The output of the test is the test result. The blood test result should be verifiable and traceable.
In a software supply chain, that event may be using a code scanning tool, a commit by a developer, or even a statement about the environment the event is taking place in.
An attestation allows consumers of a software artifact to verify the quality of that artifact independently from the producer of the software. It is similar to how the chain of custody in our real world example allows a reviewer to verify the quality and authenticity of the medical test.
Attestations provide the data to automate governance and compliance tasks.
How do I create attestations?
At TestifySec we are hard at work on our Witness tool and platform. Witness allows users to easily create attestations for software supply chains no matter what CI platform your organization uses. Our Witness SaaS allows enterprises to manage policy over heterogeneous build platforms. Our platform gives your enterprise the tools they need to manage software supply chain risk.
At TestifySec we have heavily contributed to the open-source project in-toto. Please visit our media page to listen to our talks and articles demonstrating implementing attestations with in-toto.
What types of attestations should I make for my software
To verify the quality of a build, four attestations need to be made for each step in the CI process. Environment, Process, Materials, Artifacts
Environment
The environment is the inventory of the system at the time when the CI process happens. Attesting the environment mitigates against attacks such as Solar Winds, since we have a complete inventory of the system state.
Process
The process is the actual transformation process and represents a program that takes input and has an output. This process may represent a compiler, code testing tool, a packaging tool, or any other program. Each process in a computer has an identity, that is the string of 1's and 0's that makeup its content. This identity, like a person's DNA, can be used to uniquely identify it -- we call this a workload identity. A process attestation tells administrators what computer program transformed the original source code/materials into an artifact and what programs performed testing on that software. Process attestations are a critical tool in defending against complex supply chain attacks.
Materials
Materials are the files consumed by a process. These materials are any raw data and can include configuration, source code, and other data. Understanding what materials go into an artifact ensures critical IT and OT systems are protected against usually hidden vulnerabilities.
Artifacts
Artifacts are the result of a CI Process. They may be the result of either a final or intermediate step. Tracking artifacts between CI process is essential to preventing many types of supply chain attacks.
Example - Compiler Attestation
In the example below, we have a single CI step that takes a piece of source code (
main.c) and turns it into a compiled program (main.exe).
There are four attestations that we create in this process.
Material Attestation
We want to compute and record the SHASUM of the files going into our GCC compiler. In this case our attestation will include a single file,
main.c. This attestation will allow us to verify that the compiled program was derived from the source code we expect without disclosing the actual source code.Process Attestation
In this example the process is GCC. The process attestation should uniquely identify the compiler that was used. Again we look at the string of bits that actually make up the compiler. We compute the SHASUM of the process binary and record that in our attestation.
Environment Attestation
The environment attestation is probably the most challenging attestation to get correct. The state of the build system when the build took place should be measured and it should be measured from an outside view. Hooks into cloud metadata services and TPM devices provide this capability.
Environment attestations are needed to mitigate attacks against the build system. Strong attestations of the build environment are essential in mitigating attacks against the CI system and can stop attackers even after a full compromise of the CI system such as GitLab CVE-2021-2220.
In this example our attestation includes all of the libraries in the baseline system, the security group the build happened in
bigcorp-internal, and the AWS region used for the build. This information can be verified at any point of the SDLC without exposing internal details about the build system.Example - SAST Attestation
Many compliance frameworks require static application security testing (SAST) of software. Providing an attestation of SAST testing will automate many governance and compliance tasks and in the future may be mandatory depending on who you sell your software to.
Material Attestation
Like in the previous example the materials are the source code undergoing SAST. We need to create an attestation to prove the code that underwent scanning is the code that corresponds to the artifact we want to run.
Process Attestation
In this example the process is the SAST tool. The SHASUM, version, and manufacturer of the SAST tooling is recorded in our attestation. Tracking this information allows us to understand the SAST status of all of the artifacts running in production.
Environment Attestation
The environment attestation in this example is similar to the previous example. This attestation will allow consumers of the software to ensure that the materials and artifacts are tamper-free.
Artifact Attestation
In this example the artifact is the actual scan result. This attestation will allow consumers to link the scan result to the artifact without disclosing the source code.
What is the difference between an SBOM and an Attestation?
An SBOM (Software Bill of Materials) is all or a subset of the attestations made during the CI process in a standardized format that is easily distributable. Simply put, attestations are required for an SBOM.
Conclusion
We have shown a couple of examples of what attestations are and how they can be created. This pattern can be applied to verify any step in the CI process regardless of whether you act on source code, infrastructure code, or security and compliance testing. Software Supply Chain Security is a new research area. However, we are hard at work creating tools such as Witness to make creating attestations, SBOMs, and policies around these attestations much easier. Reach out if you would like to get a demo of our Witness platform, giving organizations control over their DevOps.