Date: Wed, 24 May 2023 11:40:18 -0700 (PDT) From: Brian Behlendorf <brian@...lendorf.com> To: oss-security@...ts.openwall.com Subject: Re: Clarification on embargoed testing in a partner cloud 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.