slsa
slsa copied to clipboard
slsa-framework
Less reductive SLSA leveling
I've been trying to rationalize SLSA levels but struggle when I see three discrete separate domains of provenance, integrity, compliance conflated as one that lumps together criteria across the three for the different SLSA levels in a single axis, rather than aggregating and computing across three different axes for the three different areas of guarantees.
Borrowing from the docs, here is where I see this reductiveness become problematic. I don't see how this makes sense except as theater:
The SLSA level is not transitive (see our FAQs). This makes each artifact’s SLSA rating independent from one another, allowing parallel progress and prioritization based on risk. The level describes the integrity protections of an artifact’s build process and top-level source, but nothing about the artifact’s dependencies. Dependencies have their own SLSA ratings, and it is possible for a SLSA 4 artifact to be built from SLSA 0 dependencies.
I understand why requiring levels to be transitive makes it all a much harder problem to solve, It's almost as to say: 'we know it’s all mystery meat but hey at least we double-checked and signed off on it'
One approach here would be to introduce interim levels such as 3.5 and a level 5, retaining the same guarantees but adding more levels to the progression, for instance, level 4 would require two-person reviews as a guarantee of compliance while getting to level 5 would require attaining hermetic builds as the ultimate integrity guarantee.
Now, a much better solution would be to separate compliance from provenance and integrity altogether and introduce a split stack of levels for compliance while enforcing that the supply chain levels need to be transitive.
It's almost as to say: 'we know it’s all mystery meat but hey at least we double-checked and signed off on it'
To put this a bit more charitably, I think of it as, "I did my part! Yes, we're still all connected in the supply chain, but I did all I could to make my portion safe." :)
It's probably worthwhile a writeup on the transitive problem.
There are still plans for a "transitive" SLSA level but where does it end? What is that bottom turtle, do we go back to the kernel and all the compilers? What are individual projects and organizations comfortable with?
To @dlorenc 's point SLSA's initial releases are in that piece of getting individual projects to start attesting that they did their part.
Nothing will get done if no project can start generating some metadata without attesting to all their upstream dependencies. This would be much easier if everyone from OS on down were already generating SLSA attestations, but we're not there yet.
Separating compliance out is a good point.
FWIW Verification Summaries provide some help in understanding the transitive posture of a given software artifact.
But yeah, we don't have a way of succinctly talking about it yet.
Some have suggested something like "SLSA L4, transitive L3" to indicate an artifact that itself meets SLSA L4 while it's lowest transitive dependency is L3.
I think there's 2 potential transitive axes here:
- Steps along the path to producing an artifact, e.g. I've applied a SLSA 4 build process to source code which was only managed to SLSA 3
- Dependent artifacts, e.g. I have DBD::MySql built end-to-end SLSA 4, but it's linked against MySQL which was only built to SLSA 3
Both axes have effects on the level of trust you should put in any given artifact at the point of use but have different potential remediations. In the first case, you might like to encourage the maintainers of your package to improve their processes and controls and in the latter you might be able to choose a different version (or provider!) for your dependent artifacts. If we're going to make statements on transitive effects on SLSA level, we should also give users information on where those transitive effects have come from to allow artifact consumers paths to improving the overall SLSA level of their stack.
Also, regarding transitive effects, this description of SLSA level composition appears to be germane but discarded
In #502, I added a paragraph explaining that SLSA is intended to be part of a broader determination of risk. I don't think that sufficiently addresses this issue, but I'm hoping that it's a start. If you get a chance, please take a look. It's a large PR so it's just the new paragraph added to the "What is SLSA?" section (a917c17).
I'm going to mark this issue as closed because I don't think there is anything actionable at this point. There have been some discussions around a "dependency track" but that is likely fairly far out. Not to say that the thread here isn't valuable, just that it's likely better to have a cleaner issue tracker.