Unclear requirement around build service secrets

[james-w]

• It MUST NOT be possible for a build to access any secrets of the build service, such as the provenance signing key.

I am not sure what this means, and I asked some of the people on our team, and we got a few different answers, with no-one confident that they had the right answer.

What would be other examples of secrets that should be restricted under this?

It says that no secrets should be accessible for the build, but how would you deal with things like:

• Connecting to a sonarqube instance to get code analysis
• Fetching dependencies from private storage
• Pushing built artifacts to private storage

Perhaps it's about what is defined as the build in this statement?

[MarkLodato]

I agree that this is unclear and needs better explanation. Please take a look at Implementing verifiable builds in Chapter 14 of Building Secure & Reliable Systems and let me know if that is any help. Your feedback can guide us as we update the SLSA site.

The model is that the build service is trusted, but the users of that service are not. In this way, we minimize the number of components that we have to trust so that we can focus our effort on securing those.

This particular requirement is that a user of the service must not be able to access the provenance signing key or fake any of the provenance metadata. For example, Google Cloud Build can automatically generate provenance in the trusted control plane. GCB is implemented in a way such that the user-defined workload has no access to the signing key (barring a serious vulnerability!). Therefore, using GCB in this mode could be one way to satisfy this requirement.

What would be other examples of secrets that should be restricted under this? [...] Perhaps it's about what is defined as the build in this statement?

Yes, the phrase "secrets of the build service" was intended to refer to secrets that could be used to compromise the build service and ultimately influence other builds or affect the provenance. For example, credentials for the machine or workload identity (K8S, Istio, etc.) might fall into this category.

(At least this was my understanding. Others, please chime in if you disagree.)

It says that no secrets should be accessible for the build, but how would you deal with things like:

• Connecting to a sonarqube instance to get code analysis
• Fetching dependencies from private storage
• Pushing built artifacts to private storage

I think that's out of scope for this particular requirement, though in general I would recommend following the Principle of Least Privilege. If practical, separate the build step into multiple phases, and only grant secrets to the phases that need them. For example:

• Fetch dependencies
• Build (hermetically, with no network access)
• Analyze/test
• Push

Does this help?

[mlieberman85]

@MarkLodato I by and large agree.

@james-w A bit of extra elaboration:

The premise of this requirement is that the build service itself is easier to reason about than a user defined build that could run any arbitrary action, including printing out of secrets. Also since build actions can call out to compilers and other build tools which themselves are hard to reason about it is much easier for secrets to leak as a result of a secret in a build itself as opposed to a hardened build service.

This framework doesn't get into best practices, but should link to them in the future. From a best practices perspective:

• If possible have the build service delegate temporary access to the individual builds rather than giving builds themselves the secrets.
• When that isn't possible try and use build tasks specifically developed for a single purpose, e.g. sonarqube as opposed arbitrary shell commands that use sonarqube cli tool or something like that.

[james-w]

Thanks for the clarification, I think that it makes it clearer. This matches what some of us thought, but others saw this requirement and thought that it would require us to try and run builds that used no secrets in order to comply.

I think that trying to include some of this clarification in to the framework would be useful.