Video: Deep Dive on SLSA (EPIC)

[melba-lopez]

Description Positioning SIG would like to create a webinar or video (may be a series) to deep dive into SLSA implementation.(Length TBD)

Background From June 14th Meeting

Possible option: Long form content and split up into chunks

Timeline TBD

FYI - @mlieberman85

[melba-lopez]

0. SCI WG ? (pre-req)--> create an issue for this separately
1. Why do i care about SLSA?
2. How do i get started (Beginner)? 2a. Use cases: GitHub Actions, Jenkins, Tekton, Team City, (need industry help)
3. How do i get started (Advanced)?

Persona: Producer (OpenSource Maintainers)

• Highlight OpenSSF: slsa - 10 point mobilization plan??
• They are writing the code and want to use a SLSA Build
• Assumes that the "build infra" already has been SLSA-fied
• potential CI Tool (open source project by Mike) to call a secure builder (SLSA "Certified"); openAPI specification, which allows folks to develop plugins as they see fit
• eventually we may want to have SLSA for the entire dev lifecycle, but currently focused on the build
• Assume trust of the secure builder

Persona: Verifier

• Highlight OpenSSF projects to do the verification: Sigstore, in toto, slsa provenance
• they have received a software package/product/project
• some artifacts (slsa provenance, in-toto attestation);
• sigstore does signing
• in-toto is the document that is signed by sigstore
• we don't require in-toto
• VSA (in-toto attestation) at a high level; consuming elements (most tools dont support VSA) --> maybe a secondary video

Persona: Consumer

• not sure this is any different (from a video perspective)
• potentially delay until a later time?
• consumer is mostly addressed in verifier part

Persona: Infrastructure provider (at a later time)

Securing your build systems generating this data xyz

[joshuagl]

I wonder if we should focus on infrastructure provider centric messaging to start? IMHO the ideal path to adoption is enabling a feature your existing tooling and infrastructure has implemented :-)

[melba-lopez]

I wonder if we should focus on infrastructure provider centric messaging to start? IMHO the ideal path to adoption is enabling a feature your existing tooling and infrastructure has implemented :-)

@sudo-bmitch likes this idea because many folks will want to implement and if there tooling doesn't support it they are stuck.

[melba-lopez]

2. How do i get started (Beginner)? 2a. Use cases: GitHub Actions + npm ecosystem support; Minimum Viable SLSA 2b. MVSLSA for maven (support is coming soon) 2c. MVSLSA python (support is coming soon) 2d. Common SLSA practices for verification (i.e. SLSA rebuilder) 2e. did this build come from the right party claiming to be doing the right thing?

• what SLSA level should we aim for? should we aim for signed provenance?

3. How do i get started (Advanced)? 3a. Getting your build to meet the requirements of SLSA (maybe 1.5 hour webinar) 3b. How to hit the isolation requirements (existing build tools not created to protect themselves from each other) 3c. @mlieberman85 End to end how to build a SLSA builder from scratch 3d. how does SLSA protect you from Supply Chain Security Threats? 3e. @jkjell Trusted control plane 3f. SLSA Provenance Deep dive - @jkjell what does this field (in provenance) mean and how does it apply to our application 3g. @sudo-bmitch Both "isolated" and "unforgeable" fall into the hard category for folks that are used to building pipelines with access to signing secrets.