Workstream: Dependency Track

[kpk47]

We discussed a dependency track in the community meeting on Aug 28, 2023. It may have significant overlap with the Source Track, so we should discuss them together.

[melba-lopez]

Since dependencies does overlap, i just want folks to remember the original thread on source that @marcelamelara and I originally were thinking through #463

Also, dependencies and some of source can also leverage s2c2f controls and maybe SLSA can just require/reference those controls "integrate/handshake" with S2C2F. @camaleon2016 and i have discussed this in the past and have talked about it from an SCI WG gap assessment.

[arewm]

There are many different aspects to dependencies which will be relevant to hardening the supply chain. Instead of creating a track just for dependencies, it might make more sense to figure out how dependencies relate across various other current, proposed, or in development tracks.

As an example, another related property to dependencies is reproducibility (i.e. in terms of ensuring that dependencies are appropriately pins as a basic requirement towards achieving reproducibility). I mentioned this relationship in the document which has been started for the reproducibility (#873 (comment)).

The initial proposal for reproducibility was to tack it on to the build track, but my proposal was to instead include it as higher ordered levels on top of these basic dependency-based properties.

[meder]

Hi everyone,

I'd like to start drawing some boundaries around what the Dependencies Track will cover:

1. Objective here would be to enable fundamental capabilities that lead to and enable reduction of risk from exposure to 3P dependencies.
2. Dependency is defined using SLSA's terminology.
3. 3P qualification means that the dependency is owned by an entity different to the publisher of a software package.
4. Levels should apply to the software packages (SLSA terminology).

Given the breadth of risks, both in nature and impact, the track likely doesn't need to get too specific about things like known vulnerabilities and SLOs, etc and instead focus on improvements and controls that enable effective management of that risk.

Would love to hear others' thoughts and comments and if that aligns with their thinking.

[mlieberman85]

@meder Underneath the OpenSSF we also have a framework called S2C2F - https://github.com/ossf/s2c2f that is focused on secure consumption of open source software. I wonder if we can reference stuff from here as part of a dependency track. S2C2F has mostly been focused on end user ingestion of upstream dependencies, but I can see us working to create a loop here where following some set of S2C2F practices along with maybe a few other SLSA specific things would create that loop where:

• SLSA is used to secure production of software
• S2C2F is used to secure ingestion of dependencies
• SLSA using S2C2F as part of pulling dependencies into a build can then sign off that it conformed to those practices as part of a dependency attestation which could then itself be used by folks following S2C2F to consume either as an end user or for this dependency to be used itself in a future SLSA build.

@adriandiglio Thoughts?

@

[camaleon2016]

+1 This is an excellent way to get all the benefits of both SLSA and S2C2F. I've been pushing this from the start.

[meder]

@mlieberman85 @camaleon2016, thanks, let's keep that in mind while discussing the implementation. As the starting point I'm sharing the draft Google Doc where we can have a more concrete and targeted discussion:

[DRAFT] SLSA Dependencies Track