Discussion on path to S2C2F aligning with SLSA as its dependency track

[camaleon2016]

Based on discussions within the Supply Chain integrity working group and S2C2F Project we wanted to open discussions on a path for S2C2F to align with SLSA as its dependency track. This would be contingent on SLSA's Source and Build tracks being completed and a clear understanding of the strategic direction, path, and roadmap. @mlieberman85 @marcelamelara @hepwori

[hepwori]

Great timing! @meder has done some early sketches of goals, scope, and shape of a possible dependency track. He'd be a great person to pull in here too.

[meder]

Thanks, would love to collaborate. Dependency track issue is here: https://github.com/slsa-framework/slsa/issues/961 You can see the first draft there, which will be reworked based on feedback.

[hepwori]

Update on this: as planned, folks from S2C2F and from SLSA Specification met this week to discuss this idea.

Attendees: @adriandiglio @camaleon2016 @haydentherapper @hepwori @meder

Discussion points:

• SLSA is pursuing a Dependencies track, along with Hardware Attestations and Source tracks
• S2C2F is interested in exploring ✨synergy✨ between what S2C2F has today and what SLSA desires
• On the face of it, the S2C2F project has a bunch of skills, research, and prior art relevant to SLSA Dependencies
• Also, S2C2F community contains folks who are expert and passionate about the topic
• SLSA's aim is to have a set of tracks which share a standard approach and philosophy to level definition
• There may be some gaps between how S2C2F is formulated today, and how SLSA approaches tracks and levels

Next steps:

• S2C2F (Adrian): Assess community interest (e.g., in the next S2C2F meeting) in putting focused effort behind adapting S2C2F to be contributed as SLSA's Dependencies Track
• SLSA Dependencies Track (Meder): Produce and share first draft of track principles, and areas where we'd need to adapt S2C2F to conform
• SLSA Specification (Spec Leads): Validate approach (e.g., in next meeting) and raise any concerns with proposed plan.

Others — please chime in if I missed or misrepresented anything!

[tombedfordgit]

Hey @meder Were you able to produce the first draft of track principles? As we discuss this opportunity within the S2C2F community, it'd be really useful to understand the delta we'd encounter today. Thanks!

[meder]

@tombedfordgit I should have something to share next week.

[meder]

@tombedfordgit Here's a list of principles (also as Google Doc version for comments/discussion):

1. Conceptual integrity and compatibility with the other two tracks: build and source.
2. As with other tracks, the level is a property of the built artifact. Dependency level of an artifact describes the risk reduction outcome that was achieved for all of the “build dependencies” of the built artifact.
3. Each level should have a clear articulable security outcome.
4. There may be more than one way to achieve each outcome.
5. Higher levels imply reduced risk. This usually results in higher levels being harder to meet.
6. Dependency track is about the security of external build dependencies: software artifacts that are fetched or are made available to the build environment during build. This includes build tools.
7. Dependency track should conceptually work for packages acquired via package managers like npm and Maven but also vendored source code (e.g. C libraries) and Docker images.

[bureado]

Adding a couple comments/questions in the spirit of cross-referencing efforts.

1. Re. point 6 where it says "includes build tools", this relates slightly to #1164 and associated workstream.
2. Re. point 7, what's that definition leaving out? Arbitrary binaries downloaded via curl from, say, GitHub releases? git submodules or other acquired remotes? If so, why are we leaving those out?
   1. Also, there's a good high level blog post talking about consumer-side SLSA scenarios in https://blog.trailofbits.com/2024/10/01/securing-the-software-supply-chain-with-the-slsa-framework/
3. Finally, as a suggestion, I think the track principles can be derived from understanding what consumer policies look like. For example, what does a package manager client in an organizational/enterprise setting want to verify beyond what slsa-verifier does? Does it want to ingest VSAs? Fetch non-SLSA statements cross-referenced by subject? Inspect deep claims in build provenance against some custom logic?

[meder]

@bureado

1. ack, thank you.
2. Great question. Dependency track covers "build dependencies", which are currently defined in SLSA as: "Artifacts fetched during initialization or execution of the build process, such as configuration files, source artifacts, or build tools.".
3. Each level of the Dependency Track must define a security outcome that achieved for all build dependencies of an artifact being built. e.g. if level 1 is about addressing availability risk then all build dependencies of an artifact must have this risk addressed and the artifact being built would have a corresponding attestation that can be verified by the clients consuming the artifact. Hope this clarifies the intent of the build track.

[camaleon2016]

@hepwori @meder @tombedfordgit @bureado @adriandiglio

Please see the reformatted S2C2F to fit SLSA tone and methodology for SLSA Dependency Track. Included are comments meant as discussion points. This is a first draft and is meant as a launching pad for our collaborative effort in bringing SLSA Dependency Track to fruition.

Draft SLSA Dependency Track