-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future Suggestion: Build Systems Track #802
Comments
This is a good call out @mattfarina. Given that a significant portion of open source projects rely heavily on managed build systems, conveying the security of build systems to users is important, akin to how 3P Cloud Providers convey the security of their services to their users. CC: @jonmuk who was instrumental to our development of the paper. |
Thank you for bringing this up! @JoshuaMulliken and I are still working on #515 but got a bit sidetracked working on the v1.0-RC2 spec release. Now that the release is ready, we'll be focusing on the conformance program more. Do you think there would be value in a Build Systems track as opposed to a yes/no conformance program? Right now we're focused on whether build systems are isolated sufficiently to meet Build L3, but it would make sense to have a higher level of certification for Build L4. I wonder if there would be value in lower levels of a Build Systems track (e.g. if a build system needs to hit Build Systems L3 to produce Build L3 provenance, would there be any value in a Build Systems L1 or L2? What would they look like?). |
In short, yes. The CNCF TAG Security white paper notes:
This is something I've learned matters. What one needs for Finance, Healthcare, and Government sectors is often different from a typical small to medium sized business. For example, there are build services that don't allow network/internet access while the build step is happening. In the 0.1 SLSA spec there were requirements for access and superusers. Some build systems will target mass audiences. Others may target niches with stricter requirements. Being able to spot that matters. I like to think of it this way. All build systems have attack surfaces. How are those managed and are they managed to a level that meets my needs? My needs being different depending on the situation. While I was reading Verifying build systems I noticed the questions are very open ended. For example,
For end users who consume a build system, they aren't looking for a yes/no in general. People have different requirements that can't be answered with a yes/no. But, things can often be put in terms of levels (or something similar). There is also the user experience. This is for both consumers and producers. Consumers want to see, at a glance, where something is. Producers going after levels is a bit of gamification that can help them make their systems more secure. Does that make sense? |
There's a lot SLSA is working on in this space. We're playing a delicate balance between granularity and standardization. I agree with the Build Systems Track, and previous suggestions have been to look at white papers folks like the CNCF have released, e.g. Secure Software Factory Ref Arch, and Supply Chain Security White Paper, NIST SSDF, etc. and refer to those practices as opposed to creating new requirements. @mattfarina Would something like an attestation (similar to the provenance spec), that makes claims on the build system might help here? It would be a signed JSON document with a bunch of metadata claims about how the build system is built, secured, and operated? This would allow for both self signed attestations or allow for other external parties make claims via an audit/conformance program. (FWIW, I wrote up some of the securing the build and build infrastructure pieces of the Supply Chain Security White Paper and helped lead up the CNCF Secure Software Factory) |
I've been thinking about this for a bit and there are a couple considerations to think about:
This is why I don't think attestations are enough. |
An attestation does not help to provide evidence of the practices of the build platform. I interpret the challenge here to be around the "trust but verify" statements. Attestations help to associate the platform's sign-off on artifacts. This can be used by consumers once the platform is trusted but there is no way for producers/consumers to verify the trust placed in build platforms. Many CI systems used today are trusted on first use, but having been in the middle of reacting to an incident in a once-trusted system (i.e. Travis), it is much harder for systems to gain my trust from a producer's point of view. I haven't knowingly been a consumer of CI systems that have had leaks, but that is another element that I see Matt trying to get at (and a much harder problem to solve as I see producer trust as being easier to get than consumer trust). |
Thanks, @mattfarina, for joining the SLSA Specification meeting today and leading the discussion! To recap:
@mattfarina volunteered to send out a PR by Wednesday (?) to add to Future Directions. Thank you! |
This change was proposed in the SLSA Specification meeting on April 10, 2023 from a discussion on issue slsa-framework#802. Secure build systems are essential for building secure artifacts. While the work leading up to the 1.0 release for the SLSA build track was not able to come to concensus around verifying build systems, there is potential for a future track that addresses build system concerns. There is an opportunity for concerns to be met for those building and operating build systems, those checking conformance of those systems, and end-user of those systems. Each has their own needs. Fixes slsa-framework#802 Signed-off-by: Matt Farina <[email protected]>
This change was proposed in the SLSA Specification meeting on April 10, 2023 from a discussion on issue slsa-framework#802. Secure build systems are essential for building secure artifacts. While the work leading up to the 1.0 release for the SLSA build track was not able to come to concensus around verifying build systems, there is potential for a future track that addresses build system concerns. There is an opportunity for concerns to be met for those building and operating build systems, those checking conformance of those systems, and end-user of those systems. Each has their own needs. Fixes slsa-framework#802 Signed-off-by: Matt Farina <[email protected]>
This change was proposed in the SLSA Specification meeting on April 10, 2023 from a discussion on issue slsa-framework#802. Secure build systems are essential for building secure artifacts. While the work leading up to the 1.0 release for the SLSA build track was not able to come to concensus around verifying build systems, there is potential for a future track that addresses build system concerns. There is an opportunity for concerns to be met for those building and operating build systems, those checking conformance of those systems, and end-user of those systems. Each has their own needs. Fixes slsa-framework#802 Signed-off-by: Matt Farina <[email protected]>
The "build track" appears to look at things from the standpoint of a user of a build system. In the future directions sections it covers expanding the "build track" and a "source track".
While these are great, there is a track that's missing. A build systems track that covers the security of a build system. The material on verifying build systems is a nice start. But, there are some limitations with it:
Note, to expand on why I can't verify a build system here's a simple example. I cannot see who has superadmin access and can make arbitrary changes. Or, how an organization handles that level of access.
A build system could be a complete mess. Very much insecure. Or, it could be really good. At present, there is no way to know and nothing in the future plans to solve for it.
I came to this when I noticed the Common Requirements have been removed. This is already captured in #674.
The text was updated successfully, but these errors were encountered: