Clarify what "control plane" means

[MarkLodato]

We could use some clarity on what "control plane" means since it's pretty esoteric.

From https://openssf.slack.com/archives/C03NUSAPKC6/p1716910044980559:

Rémi REY

Starting with a first question / remark.
I'm a bit bothered by the accuracy requirement from SLSA around the Provenance attestation.

This part :

Accuracy: The provenance MUST be generated by the control plane (i.e. within the trust boundary identified in the provenance) and not by a tenant of the build platform (i.e. outside the trust boundary), except as noted below.

versus the first exception right after:

The data in the provenance MUST be obtained from the build platform, either because the generator is the build platform or because the provenance generator reads the data directly from the build platform.

I had to go back and forth several times to the build model table to understand what would be "Build platform" and "control plane".

After some time checking materials online I saw the implementations with GitHub Actions and I think I have the proper scope in mind.
The control plane could be represented by whatever a Platform Team (in the Platform engineering leaning) would produce to ease the build.
So the GitHub actions through the reusable workflow are considered the control plane, and based on this, having the action generating the Provenance is totally fine as long as data it contains comes from GitHub.

[...]

So about the accuracy statement.
If

the provenance MUST be generated by the control plane

I understand that it cannot be generated by anything the Platform team would have built on top of GitHub/GitLab for example. And that GitLab/GitHub MUST be the component generating Provenance because these are :

... [the] component that orchestrates each independent build execution (source)

Mark Lodato:

First, let me say that SLSA is a framework for security, but it's up to you (or a delegate) to decide what's good vs bad. So what I'm saying here is a recommendation rather than a requirement.

For this case, the relevant question is who can influence the provenance. If the provenance generation happens within the scope of control of the project owner, meaning that they can inject false information into the provenance (e.g. claim that it came from a source repo that it didn't really come from), then I'd say that clearly does not satisfy the requirement. However, if the provenance generation happens in a secure module (e.g. reusable workflow) that only the Platform Team has control over, such that regular project owners cannot inject false information, then I think it does meet the requirement - the "control plane" is GitHub/GitLab + the reusable workflow owned by the Platform Team. Whether or not it's OK to include the Platform Team in your trust base is up to you.