blog: SLSA E2E Verification with the in-toto Policy Framework #1488
Conversation
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
trishankkarthik
changed the title
|
@trishankkarthik @s-snahil, the e2e examples came up in the SLSA specification call today. We recognize that these blog posts will be long and some other authors of potential blog posts are planning to split up the content across multiple posts. While I haven't yet reviewed the content of this PR or the proposal, I wanted to let you know that if you wanted to split up your content into multiple posts, it would be consistent with others. |
TomHennen
left a comment
TomHennen
left a comment
There was a problem hiding this comment.
Thanks for this. Content generally looks good. Some formatting/rendering problems to fix. Some optional content suggestions.
| is_guest_post: true | ||
| --- | ||
|
|
||
| ## 1. Introduction |
There was a problem hiding this comment.
It looks like our blogging engine takes whatever text immediately comes after the header and includes it as a snippet when rendering the blog page.
Notice how the heading winds up showing as a summary of the post.
Looking at what happened with this post I think it just takes the first paragraph.
Suggestion: move the first paragraph of 'Introduction' before the first heading. Alternatively, remove the first heading entirely. This will mess up your numbering though. Maybe the numbering could be dropped?
|
|
||
| Our hypothetical supply chain, as depicted in the figure above, consists of three named Steps: [Source](#21-Source-which-code-was-used-GitHub), [Build](#22-Build-which-code-was-built-where-GitHub-Actions), and [Release](#23-Release-which-artifact-was-released-where-NPM). Each *Step* corresponds to a human or machine role which, in turn, produces a signed Attestation of what happened at that stage of the supply chain—including which inputs and outputs were read and written. Note that while the Attestations here are technically synthetic, they are still realistic (i.e., they use real values from `sigstore-js`). | ||
|
|
||
| Specifically, each Attestation has a signed [Statement](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md). The [subject](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md) of this Statement precisely identifies one or more Artifacts (either inputs or outputs), while the [predicate](https://github.com/in-toto/attestation/blob/main/spec/v1/predicate.md) is categorized by a predicate type and contains details specific to the Step. This Statement is then enclosed in a [DSSE](https://github.com/secure-systems-lab/dsse) [envelope](https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md) and digitally signed by a trusted entity. |
There was a problem hiding this comment.
| Specifically, each Attestation has a signed [Statement](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md). The [subject](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md) of this Statement precisely identifies one or more Artifacts (either inputs or outputs), while the [predicate](https://github.com/in-toto/attestation/blob/main/spec/v1/predicate.md) is categorized by a predicate type and contains details specific to the Step. This Statement is then enclosed in a [DSSE](https://github.com/secure-systems-lab/dsse) [envelope](https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md) and digitally signed by a trusted entity. | |
| Specifically, each Attestation has a signed [Statement](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md). The [subject](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md#fields) of this Statement precisely identifies one or more Artifacts (either inputs or outputs), while the [predicate](https://github.com/in-toto/attestation/blob/main/spec/v1/predicate.md) is categorized by a predicate type and contains details specific to the Step. This Statement is then enclosed in a [DSSE](https://github.com/secure-systems-lab/dsse) [envelope](https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md) and digitally signed by a trusted entity. |
|
|
||
| ## 2. Attestations: a trail of evidence [sigstore-js] | ||
|
|
||
|  |
There was a problem hiding this comment.
This figure doesn't seem to show up when rendered:
|
|
||
| The reader can generate their own attestations like so: | ||
|
|
||
| ```shell= |
There was a problem hiding this comment.
For some reason this renders really badly. I don't know if it's the formatting options? E.g. is that '=' causing problems?
This post has code sections that seem to render properly: https://deploy-preview-1488--slsa.netlify.app/blog/2023/05/in-toto-and-slsa
|
|
||
| Specifically, each Attestation has a signed [Statement](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md). The [subject](https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md) of this Statement precisely identifies one or more Artifacts (either inputs or outputs), while the [predicate](https://github.com/in-toto/attestation/blob/main/spec/v1/predicate.md) is categorized by a predicate type and contains details specific to the Step. This Statement is then enclosed in a [DSSE](https://github.com/secure-systems-lab/dsse) [envelope](https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md) and digitally signed by a trusted entity. | ||
|
|
||
| The reader can generate their own attestations like so: |
There was a problem hiding this comment.
It looks like this isn't actually doing the build, etc. Are these just example attestations that could have been produced elsewhere in the SDLC? Perhaps that can be stated?
There was a problem hiding this comment.
optional: Reading further it looks like the intention isn't to provide a working end-to-end demo, but a conceptual walkthrough of how it could work. I think that's fine, but it might not be what readers expect (it's not what I was hoping to get out of the E2E request). Since there's still a lot of good value here, perhaps it would help to set expectations a bit more clearly upfront?
| digest: | ||
| sha512: 3c73227e187710de25a0c7070b3ea5deffe5bb3813df36bef5ff2cb9b1a078c3636c98f31f8223fd8a17dc6beefa46a8b894489557531c70911000d87fe66d78 | ||
| predicateType: https://slsa.dev/verification_summary/v1 | ||
| predicate: |
There was a problem hiding this comment.
Note this is missing the required 'resourceUri` field and the instructions below omit the verification of that field as recommended.
Fixing this shouldn't be a blocker for getting this post published, but it would probably be good to incorporate with other feedback?
|
Oh, and see here to address the linter errors: https://github.com/slsa-framework/slsa/blob/main/CONTRIBUTING.md#markdown-style |
|
|
||
| ### 2.1 Source: which code was used [GitHub] | ||
|
|
||
| For the first Step, we suppose GitHub [generates](https://github.com/in-toto/attestation-verifier/pull/92/files#diff-0fbba41689defbe9ff00a2d33d694324ad6c838fb144d25313a594f789aeb19f) using [gittuf](https://gittuf.dev/) a realistic [Source VSA](https://slsa.dev/spec/v1.2-rc1/source-requirements#source-verification-summary-attestation) that records which source code repository and commit were verified, under which source policy, when, and with what result. We construct a Statement whose subject points to the exact repository (`sigstore/sigstore-js`) and git commit (`3a57a741bfb9f7c3bca69b63e170fc28e9432e69`), optionally including branch refs that contain that commit. The predicate type is `https://slsa.dev/verification_summary/v1` and its predicate records the source policy it was checked against, the resource URL, the verification timestamp and the verdict. In our example, the verdict shows the source met SLSA Source Level 3 controls (for e.g., branch protection, mandatory code review, and tamper resistant history). |
There was a problem hiding this comment.
I haven't looked at this in detail to see whether it is consistent with the source track as it continues to evolve, but that might be irrelevant as you are referring the RC1. I imagine that most of the concepts are still valid.
Even with this, you mention mandatory code review but I don't see that in the source attestation. The two person review is also only required at L4 which you are not claiming.
|
|
||
|  | ||
|
|
||
| The end-user uses the Policy VSA Verifier to [check](https://github.com/in-toto/attestation-verifier/pull/92/files#diff-de46bb73a167ce2209202960f07192ac457e1d5ae91bc0aa430cb25f36101144) a given Artifact against the Policy VSA without rerunning the potentially more expensive policy verification. It reads the Artifact (`sigstore-3.0.0.tgz`) and its Policy VSA, verifies the VSA’s signature, confirms its predicate type (`https://slsa.dev/verification_summary/v1`), compares the hash of the Artifact against that in the VSA, checks that the policy verification did indeed pass, and enforces freshness by rejecting VSAs older than a configured max age (for e.g., 24 hrs). |
There was a problem hiding this comment.
How will end users appropriately verify the VSA? Is it tied to the identity of the verifier (do they need to know this) or is there some other reusable policy that can be used?
|
Hey all, just checking in. Is this still something you'd like to publish? I think it would be valuable. |
3 participants
Guest blog post for #1486