Source track attestation claims

[laurentsimon]

Tracking issue for #1037 (comment)

Main comments:

• The current claims are a mix of policy (who's allowed to review) and facts (who reviewed).
• The current use case is useful when consumers and producers are the same but does not help for consumption of other (open source) projects

Current suggestion: Separate policy and fact claims, like we do in build track.

[marcelamelara]

Also to consider in this context is the currently open PR on human review predicates: in-toto/attestation#151

[arewm]

One of the challenges that we will have to contend with is who is an "appropriate" entity for generating the attestations. The build system would not be appropriate in my opinion as it would not have detailed knowledge of the source control system to understand whether any settings have been modified (and reset) in the past. The entity generating any attestation/data should have access to any necessary audit data to inform any attestation.

[joshuagl]

I think source attestations would be generated by the source control platform? Because that platform would need to be trusted for producing attestations, we'd want to have a document similar to Verifying build platforms (or perhaps an extension to that doc) which will help a) SCP producers think about what security objectives they should meet and b) SCP consumers query their SCP providers to understand how they meet SLSA provenance generation requirements.

[zachariahcox]

Related to:

• Consistency: "attestation" vs "provenance attestation" vs "provenance" #758
• content: draft: define source-track objective in terms of revisions and provenance.  #1083

The build system would not be appropriate in my opinion as it would not have detailed knowledge of the source control system to understand whether any settings have been modified (and reset) in the past

☝ Agree, the build system would in fact be the consumer of this information.

...source attestations would be generated by the source control platform

☝ I think it might be clearer to say that the SCP stores / serves the attestations, but they claims might need to be made by "any actors or tools with claim-write permission."

Importantly, this would include the change management / code review tooling to describe the process that produced the change, but there may be other actors who need to make subsequent security claims.

Examples that come to mind:

• late-branching strategies (making pre-existing commits reachable from release branches) may require after-the-fact claims from different actors.
• release-to-market revisions may undergo additional long-from stress testing which was not included in the organization's merge policies for the protected branch.

[zachariahcox]

The relevant terms that seem to pop out here are:

• revision: a state of the source identified uniquely, such as by commit sha
• claim: a statement about a revision from the perspective of a specific actor or tool.
• provenance: a set of claims about the origins / process-of-production-for a specific revision
• attestation: a signed document associating a predicate with a subject.
• "source provenance attestation": a signed document associating provenance claims (predicate) with a specific repository revision (subject)
• VSA for source track: An attestation that the platform-specific claims were sufficient to meet a SLSA standard. This moves some of the complexity of dealing with specs, versions and implementation bugs out of the verifier tooling and into the SCP, or some other platform-aware tooling.

[TomHennen]

Is it true to say that these claims can be broken down into two broad categories:

1. Those issued by the SCP to the builders for downstream use.
2. Those issued by other actors in the production of changes for use by the SCP in making the determination to 1.

?

If so, do we have names for those two categories?

As I read this discussion I'm getting a bit confused about which we're referring to and I wonder if others have similar trouble.

[zachariahcox]

@TomHennen what's your mental model example for this one:

Those issued by other actors in the production of changes for use by the SCP in making the determination to 1.

From the SCP perspective, I don't think it would trust anyone else's input. It would be forced to claim what it knows for sure and move on.

I can imagine a specific release pipeline that requires a VSA "meets slsa level 2" AND the sign off from some specific actor or tooling (EG: passed some kind of internal legal review), but I think that would fall outside the goals of the slsa spec.

[TomHennen]

Maybe I should rephrase 2

2. Those issued by the SCP or other actors in the production of changes with the detailed claims needed to make the determination in 1.

For the source track I'd probably stick with just the claims needed to meet the source track requirements (e.g. history retention, strong auth, multi-party review).

[TomHennen]

For example:

Category 1: attestation stating "repo git+https://github.com/octocat/hello-world@refs/heads/main at revision abc123 is SLSA_SOURCE_LEVEL_3"

Category 2: attestations stating "revision abc123 was created by ACTOR1, reviewed by ACTOR2, based on merge base def456, in repo git+https://github.com/octocat/hello-world which retains history" (followed by either a category 1 attestation about def456 or a chain of category 2 attestations starting at def456)

[adityasaky]

I'm going to drop some thoughts / reasoning we've been using as we've been building gittuf. 😄

In my mind, the question about source attestations are across two axes. First, it's about the granularity of an attestation - what claims some source attestation makes. Second, it's about who creates the attestation.

On the granularity of the attestation, I think we're in agreement that the attestation, as yet undefined, represents the process involved in submitting source code changes and having it merged in some target branch. Now, we can have a single attestation, the "source provenance", that represents all of the processes involved, which is tempting because it's a) probably easier, and b) similar to what we have with build provenance today. However, I think what works on the build provenance side does not map as cleanly to the process involved in source code changes. On the build side, we ultimately have a single entity taking in some inputs, running build steps, and producing some output artifacts; this is where the granularity intersects with creator of the attestation on the build side.

OTOH, the process involved with source code changes is distributed among more participants. For example, a typical process may be I submit a PR, two maintainers approve it, the CI runs some tests, and one of the maintainers merge it. As such, I propose we consider using different attestation predicates to represent these actions. For example, the human review predicates Marcela linked above to represent code review approvals (feedback on those predicates welcome, BTW!), another predicate to represent CI runs and checks, etc. This may seem too complex, but I think we may want to consider this so as to not back ourselves into a corner, which brings me to the who creates the attestation(s) part.

ETA: I think this aligns with @zachariahcox's point above as well:

☝ I think it might be clearer to say that the SCP stores / serves the attestations, but they claims might need to be made by "any actors or tools with claim-write permission."

For the source track levels where we trust the SCP to provide this information as an attestation, it's probably more pain than gain to use separate attestation predicates for the consumer. But as we (hopefully) move towards future, higher SLSA levels that try to distribute the SCP's trust among the participants involved in the code submission process, we will want to have stronger authentication for each participant. Then, having granular predicates helps us: each approver can be authenticated using their review attestation signature, the CI attestations can be authenticated using its workflow identity, etc. FWIW, this is the world we're exploring with gittuf today.

Which brings me to Tom's questions above.

Those issued by the SCP to the builders for downstream use.
Those issued by the SCP or other actors in the production of changes with the detailed claims needed to make the determination in 1.

On 1, I think it depends what the builders expect from the SCP. If the builder merely wants to know a certain SLSA level was met and is taking the SCP's word for it, a VSA may suffice, which I think you highlight in a follow up response.

On 2, this goes back to having either one all-encompassing attestation predicate or a bundle of more granular predicates. I want to note, though, that for SLSA levels where we trust the SCP, there isn't a real difference for the consumer of the attestation between the VSA and the attestation(s) determining the claims made in the VSA, as the SCP is trusted to generate both. Ultimately, the more detailed attestations may be a nice-to-have that don't make a big difference in the trust involved, because the VSA claims and the detailed claims all come from the same party.

This got longer than I expected. To summarize, I propose we consider using slightly more granular attestations to represent the actions performed by different parties. Today, they may all be signed by the SCP, making no difference to whether it's a single attestation or multiple. But in future, when we may want to distribute trust more or maybe support tools like git-appraise as well, we wouldn't have painted ourselves into a corner and can continue using the same predicate types, just switching out who the expected signers are in our policy.

[zachariahcox]

@TomHennen, is it fair to say that your analysis is similar to the topic of this issue: #974 (comment)

Essentially, if you know a lot about what to expect, you'll want all the constituent claims.
If you don't, you'll want the "category 1" / VSA of the claims as attested by a trusted source (the SCP for this case).

[TomHennen]

@TomHennen, is it fair to say that your analysis is similar to the topic of this issue: #974 (comment)

Essentially, if you know a lot about what to expect, you'll want all the constituent claims. If you don't, you'll want the "category 1" / VSA of the claims as attested by a trusted source (the SCP for this case).

Yes I think that's about right. I'd go one step further though and say that VSAs can be used by all users, and folks that want more information/are in a position to know can look for the constituent claims then.

To that end, and maybe inline with @adityasaky's points... would it be shocking to suggest "why don't we start by defining a category 1 attestation now (maybe VSA) and then defer the constituent attestations until later (perhaps giving the various implementations an opportunity to see what works best for them)"?

[adityasaky]

@TomHennen I personally think that'd be a good start! It unblocks the early levels (where we trust the SCP fully anyway), and we can build on what we're putting in the VSA (mapped to requirements) to understand the best way to capture the events used to meet the requirement (review, etc.).

[zachariahcox]

I think the original topic raised in the description of this issue was addressed by #1097.

I think we can close this one now!

[arewm]

My primary issues with the original source attestations are resolved as the PR states that the source control platform generates them.

+1 from me to close this.