Re: Clarification on embargoed testing in a partner cloud

[Brian Behlendorf <brian () behlendorf com>]

On Wed, 24 May 2023, Anthony Liguori wrote:
> I think the right policy for list members is that they are responsible for
> understanding the third-party infrastructure they use and if they aren't
> confident that they can maintain the rules of the list, they shouldn't use
> it.

We've known since "On Trusting Trust" that every variable consumed during 
the SDLC is a vector for compromise, even in very subtle and difficult 
(impossible? halting problem?) ways to defeat. Inevitably we need to rely 
on self-attestation, paired with certification processes when called for 
(e.g. FedRamp). There is emerging regulatory action, at least in the US 
(see the new White House Cybersecurity Policy) and the EU's CRA, calling 
for the establishment of clear processes for demonstrating provenance and 
attestation to at least the build environment and likely eventually the 
full SDLC.

A clear and more formal way of understanding the different levels of 
attestation of one's build environment can be found in the SLSA 
specification. Here's a story about how Google Cloud incorporates it into 
build service:

https://slsa.dev/blog/2022/12/gcb-slsa-verification

Of course attestation is not proof, and even human certification can only 
go so far. Reproducible builds offer a path there but that goal seems just 
as far away as it was 20 years ago, when Java was going to solve that for 
us.

I have no recommendation on if or how to use SLSA or something like it in 
this policy, just that it may be something to consider.

Brian