The role of attestations in a secure software supply chain

At Chainguard, we like to talk a lot about policy. This is because the right policy, tailored to your organization’s needs, can shut down sophisticated supply-chain attackers like those that hit Solarwinds and even manage inadvertent vulnerabilities like log4shell.‍

The first step in securing your software supply chain is to articulate policy goals. You don’t have to do this step alone: projects like Supply Chain Levels for Software Artifacts (SLSA) provide guidance appropriate for just about any deployment, and Chainguard Enforce comes with a catalog of policies ready-to-use. Starting out, a policy goal should be described in plain human language. For example:

‍Every image running in my production cluster should be (1) based on source code that my dev team wrote and (2) built correctly following a standard recipe.

Note that at this point, it’s not important how to check this, just what it says. But a policy can’t help if nobody follows it—and attackers certainly have no interest in playing by the rules. This is where policy enforcement comes in.‍

Policy enforcement using attestations

One might approach policy enforcement with a “if you want something done right, you have to do it yourself” attitude. For example, you could (at deployment time) check that an image was built correctly following a standard recipe by running that build and using the result. However, there are two problems here. First, it might not be practical to have the enforcing party perform the check: deploying an image should take milliseconds, but a full build may take hours. Second, it might not be possible: what command would you even run to check that a source repository was written by your dev team? ‍

This is where attestations come in by outsource checking a policy. Attestations are like statements made in human speech by a particular (human or robot) speaker: “I (Developer Foo) wrote the code at commit abc123.” They include:

• a subject (“the code at commit abc123”),

• a claim about the subject (“I wrote”),

• and a speaker (Developer Foo).

Digital signatures can prove that the attestation actually comes from the purported speaker without modification (integrity). Using attestations in enforcing the policy requires describing what claims from what speakers are sufficient for trust:

• Based on source code that my dev team wrote: if any of the leads for the team (Developer Foo or Developer Bar) attest “I wrote the code at commit abc123,” trust this source.

• Built correctly following a standard recipe: if the CI/CD system attests “I built this image from source abc123 by running build command `make`,” trust that the image was built from the given source.

• Tie it together: the source from the “authorial attestation” should match the source from the “build attestation” (this is cheap to check locally).

Here, attestations allow realizing otherwise-uncheckable policy goals!‍For more examples, check out Chainguard Academy, which shows how to achieve a variety of high-level policies with different types of attestations.‍

Conclusion

Attestations can be used to enforce a software supply-chain security policy. This post covered the main concept: if a trusted party makes a claim, you don’t have to check that claim yourself! But we’ve barely scratched the surface of attestation techniques: we can audit attestations (“trust but verify”), prevent tampering (transparent), time-limit claims with timestamps and expiry, and deploy to air-gapped environments, or require thresholds (two-thirds of the dev team must sign a release). Stay tuned!‍

If you’d like to use these principles to create and enforce secure supply chain policies, Chainguard Enforce has first-class support for using attestations to check policies like we described today, including authorship for source code and requiring builds be signed by a CI/CD system. If you are interested in learning more about Chainguard Enforce, reach out to our team for a demo or a 30-day free trial.