Everything Developers Need to Know About Attestations

Last month the US White House issued a memorandum that impacts all software vendors who sell applications to US government departments and agencies. Essentially, they must comply with a new set of rules introduced by the US National Institute of Standards and Technologies (NIST), which can be summarized as:

• U.S. agencies are required to obtain a self-attestation from the software producer before using the software.
• U.S. agencies will only be able to use software that meets the NIST guidance for secure software development practices.
• U.S. agencies will be required to obtain from their software producers SBOMs and documented processes to validate code integrity.
• The U.S. will create a government-wide “centralized repository for software attestations and artifacts, with appropriate mechanisms for protection and sharing among Federal agencies.”

Last week, I addressed the SBOM Revolution that is impacting not only US government requirements, but many corporate requirements, as well. Attestations are quickly gaining much of the same recognition as SBOMs in their ability to help secure the software supply chain, and specifically the open source software supply chain. Let’s dig in.

What is a Software Attestation?

A software attestation is a trust mechanism that allows a verifier (i.e., a customer) to independently validate the integrity of something asserted by the provider (i.e., the vendor). For example, an attestation can verify that an application is not compromised by malicious code. In other words, attestations make it easier for users of third party code to trust that code. 

Given the prevalence of third party open source software in today’s applications (in some cases making up >80% of the codebase), attestations have arrived none too soon. For example, public repositories that provide open source components to software developers currently lack:

• Strict controls around typosquatting and brandjacking, which can result in developers mistakenly downloading and incorporating compromised packages in their software.
• Strict guidelines to ensure that prebuilt packages are built using secure practices.
• Signed artifacts, which would ensure that prebuilt packages have not been tampered with after they have been built.

The result is that developers are forced to either implicitly trust public repositories and open source authors, or else validate every package they import (as well as the dependencies on which that package relies). Attestations are a key mechanism for resolving these issues.

For example, for the purpose of selling to the US government, software vendors must provide an attestation that includes (at a minimum):

• The software vendor’s name.
• A description of the product or products the statement refers to.
• A statement attesting that the software vendor follows secure development practices.

They also note that while self-attestation is required, government agencies can accept third-party assessments at their discretion, such as those that might be obtained from a different government agency working with the software in question. This is one of the driving reasons behind the government’s stated desire to create a “centralized repository for software attestations and artifacts.” Such a repository would go a long way toward allowing agencies to automate their software supply chain governance and compliance requirements through the use of a policy engine like Binary Authorization or in-toto ITE-6. 

Software Attestation Standards

Software attestation standards like Binary Authorization and in-toto are machine-readable, open metadata standards that you can implement in your software development process toolchain to automate the consumption of software attestations, thereby helping to assure the security and integrity of your software supply chain. 

• Binary Authorization – supported by Google, it’s positioned as a deploy-time security control. Available today on the Google Cloud Platform (GCP), you can use it to create and validate policy (for example, to enforce signature validation) in order to ensure the security and integrity of container images deployed on Google Kubernetes Engine (GKE) or Cloud Run.
• in-toto – supported by the Linux Foundation, it’s still under development but proposes a generic way for software vendors to create and validate metadata for a wide range of software artifacts, including: 
  • A component, such as an open source library.
  • A process, such as a build process.
  • Other entities, such as the vulnerability status of a component, the result of a CI/CD test, and so on.

For example, an in-toto ITE-6 attestation includes the following parts:

• Envelope: must minimally contain a statement and a signature that denotes the attestor. It is used to handle authentication and serialization.
• Statement: must minimally contain a subject and predicate:
  • Subject: Identifies which artifacts the predicate applies to.
  • Predicate: Contains arbitrary metadata about the subject.
• Bundle: (optional) a collection of attestations that are not necessarily related.

in-toto ITE-6 is also the format supported by the ActiveState Platform, which will generate an attestation for the open source language runtime environment on which you build your application. ActiveState’s attestation includes:

• Entry Point, or the package to be built.
• Materials, or the source code for all of dependencies and transitive dependencies required to build the package.
• Environment, typically a Docker container in which the current step of the build process will be executed.
• Predicate, which shows all the steps in the build process, including any parameters used
• Metadata, such as the id for the artifact that was generated by the build step.
• Subject, which shows identifying information for the final artifact produced.

The attestation also includes checksums for all components used and artifacts produced, and the process validates the signatures of all components and artifacts to ensure none of them have been tampered with.

Conclusions – Best Practices for Attestation Adoption

While it will cause adoption pains in the short term, the attestation requirement from the US government will inevitably help raise software security for everyone, including both public and private sectors alike. Luckily, there is still time to prepare:

• US government agencies will communicate their software supply chain requirements to software vendors on or before January 12, 2023.
• Agencies will collect attestations for critical software on or before June 11, 2023.
• Agencies will require attestations for all other software on or before September 14, 2023.

But with such an aggressive timeline, contractors, resellers and software vendors that sell directly to the government need to start preparing now for the new SBOM and attestation requirements. While resellers need only check with their upstream suppliers, contractors and software vendors have heavy lifting to do in order to incorporate both SBOM and attestation generation into their current software development processes. 

The simplest way to accomplish these goals is to use an off-the-shelf solution that can meet the US government’s requirements. The ActiveState Platform automatically builds runtime environments from source code (including native libraries) using a secure build service that supports the security and integrity controls defined in the highest level of the Supply Chain Levels for Software Artifacts (SLSA) framework. While there are many evolving solutions, the ActiveState Platform today also offers the ability to create both SBOMs and attestations in formats compliant with the US government’s requirements.

Read Similar Stories