You are only as secure as your weakest dependency; SLSA 4 artifacts can have SLSA 0 dependencies?

[vielmetti]

My experience of several real supply-chain vulnerabilities is that integrity of the finished product depends on the whole supply chain. In particular, incidents like left-pad,
shared-mime-info, and a host of others have seen
substantial disruptions as a result of problems deep in the dependency tree.

With that in mind, I have a hard time seeing how SLSA levels can reasonably be independent of the quality assessment of the dependencies they rely on. If I read things right, you could have an SLSA 4 rating on a final product, but that rating could include components that were unrated or SLSA 0 or even I guess known to have problems.

Did I miss something crucial here? I just don't see the point of having hypercorrect build patterns for the finished product if the components it's being built from are not adequately testable.

[TomHennen]

Hi Edward, thanks for your comment.

This issue is discussed in the scope section.

The reason for non-transitivity is to make the problem tractable. If SLSA 4 required dependencies to be SLSA 4, then reaching SLSA 4 would require starting at the very beginning of the supply chain and working forward. This is backwards, forcing us to work on the least risky component first and blocking any progress further downstream. By making each artifact's SLSA rating independent from one another, it allows parallel progress and prioritization based on risk. (This is a lesson we learned when deploying other security controls at scale throughout Google.)

Does that help? Is further clarification needed?

[vielmetti]

@TomHennen

Upon reflection this seems to make sense for prioritizing the workload, if nothing else. As long as people understand the SLSA is a metric of build system quality, not code quality, I think that will be helpful overall.

However - I look at the results from Google's deps.dev project where big projects routinely include 100s of individual dependencies, and wonder how this process will adequately identify weak spots in big systems like kubernetes.