How does SLSA fit into broader supply chain security?

[MarkLodato]

As mentioned at today's meeting (and prior meetings), SLSA is currently focused only on "integrity" supply chain security includes more than that, notably "vulnerability management" and "developer trust" (or whatever to call it).

We should either:

• Better explain how SLSA fits into the bit picture, e.g. generating SBOM, identifying dependencies, etc.
• Expand to cover all supply chain security. (If we do this, we need to make sure we don't become too diluted and confusing.)

This issue is just a placeholder to note the issue and record main thoughts and interested parties.

[MarkLodato]

At a minimum, we should update "How it fits into the security ecosystem" on https://slsa.dev/spec to be more technical and specific, particularly around vulnerability management and (maybe) SBOM.

[inferno-chromium]

Some areas i can think of

1. Vuln mgmt - open vulnerabilities in 1P code to start with. expand to include first-level 3P deps, and maybe later to transitive deps.
2. Continuous testing tools in SDLC - does it have fuzzing, static code analysis in CI/CD, testing coverage, etc
3. For OSS, maintenance aspect - does it have security policy to uptake vulns, what is fix speed, is code maintained ?

[mlieberman85]

Right now some of the SBOM formats are starting to format ways to link to vuln info. We probably want to make sure SLSA from a predicate format doesn't try and duplicate too much or just include the other reference formats like VEX.

[kimsterv]

This looks like a related issue #135, should we merge them or anything?

[shaunmlowry]

Happy to contribute here. I'm particularly interested in how SLSA and SBOM overlap where SLSA gives you highly detailed information on the provenance of individual software artifacts and SBOM gives you an overview of your entire stack and how it interrelates. There seems to be some synergy here where tooling could validate a complete stack by walking the graph presented in SBOM and doing artifact validation against the SLSA attestations

[jonmuk]

From my perspective i'd like to review an end user's recommended approach to securing their supply chain. By documenting the use cases and mapping out a high level secure supply chain programme we can pull out the requirements then identify gaps to SLSA. We are then able to debate about whether to include the new requirements into SLSA or another standard (Secure Development and the SSDF for example).

Also happy to contribute here.

[samwhite-gl]

@MarkLodato please let me know if this is not the best place to surface this. As we discussed some yesterday, this topic of "How does SLSA fit into broader supply chain security" is of interest to me. Currently GitLab's vision for broader supply chain security is defined at https://about.gitlab.com/direction/supply-chain/. There is a lot of overlap here with the current SLSA requirements, but there are also some key items that sit outside SLSA. A few examples include the following:

• Internal Code Scanning - SAST, DAST, Secret Detection, SCA Scanning, API Scanning, and Fuzz Testing are all critical activities to ensure that software is secure.
• External Code Scanning - Similarly, vulnerability scanning for upstream dependencies is important to verify as well. An upstream dependency could be SLSA level 4 compliant and still have critical vulnerabilities that expose the software to a high degree of risk. For example, Package Hunter is a tool that performs behavioral analysis to monitor upstream dependencies for suspicious behavior. This is one example of numerous tools and capabilities that can be run to test upstream dependencies.
• Consumption of SLSA-produced artifacts and validation of their provenance prior to deployment in a production environment. As an example, this might include properly setting up Binary Authorization in a Kubernetes environment.

It would be helpful for me to better understand whether SLSA is intended to be strictly a standard related to how artifacts are produced or if SLSA eventually plans to expand to address a broader view of Software Supply Chain Security (SSCS). It would also be helpful to more specifically talk through the GitLab framework and vision for SSCS to identify which areas SLSA intends to eventually cover and which areas are out-of-scope for SLSA.

[inferno-chromium]

@samwhite-gl - regarding your question on "It would be helpful for me to better understand whether SLSA is intended to be strictly a standard related to how artifacts are produced or if SLSA eventually plans to expand to address a broader view of Software Supply Chain Security (SSCS)." - this is something we are thinking about as well and need community input on how to proceed with this expanded scope (continuous testing tools, vuln mgmt). Please provide ideas on how these could fit into existing SLSA levels and bring up discussion in SLSA bi-weekly sync.

[MarkLodato]

Hi @samwhite-gl! As @inferno-chromium said, SLSA's scope is still TBD. The next concrete step is for someone to create a proposal (#296) that makes a recommendation one way or the other. GitLab's supply chain doc is a great resource for that. I'm hoping that someone from Google will be able to do start this in the coming weeks(?), but I know that others on this thread have also expressed interest in helping flesh it out.

Regarding the review for GitLab framework and vision for SSCS, it's on my TODO list. 😄 I'll reach out via email. Anyone else is also welcome to chime in.

[joshuagl]

I'd like to collaborate on a proposal for this.

My current preference would be to expand SLSA, but that's at least in part because I'm not familiar with other frameworks which cover the gaps.