[Specification SIG] Clarify/refine SLSA source requirements

[marcelamelara]

As we work to clarify the intent and requirements for SLSA 1-3, several folks have suggested to revisit how source requirements are treated.

One suggestion is to more clearly separate the source requirements from the build requirements, possibly even defining separate source-specific SLSA tiers on top of a core set of SLSA requirements. The main reasoning behind this is that source management and build are not necessarily handled by the same entity, meaning that builders do not have insight into/control over the source management of a package they are building. A clearer separation may also help in identifying additional or more fine-grained source management requirements.

The goal of this issue to capture a set of recommended source requirements.

cc @melba-lopez @MarkLodato

[melba-lopez]

These are just a few items I think of when I think of source integrity and the system the houses code. I don't think we need to duplicate what these frameworks state, but it is something to consider when designing for what SLSA requirements should be.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf

[melba-lopez]

Here is what I've been working on. This is currently still draft, but wanted to share with the team progress so far

@MarkLodato @marcelamelara @joshuagl (the case for separation of source vs build)

[marcelamelara]

@melba-lopez These figures are really helpful, thank you for putting them together! I think they distill some of the major use cases for separating source repo integrity from build integrity. I have a couple questions.

Where do dependency sources fit into these figures? I'm thinking of two scenarios.
(1) The builder pulls dependencies from npm at build time, and these dependencies might or might not include their own SLSA attestations.
(2) A git source repo includes one or more git submodules, some first- or third-party repos, each with different visibility settings, and each with different source management and SLSA source attestations.
Given these scenarios, should integrity info about these dependencies, in both cases, be considered part of build or source integrity info? I think in the first scenario, including dependency info in the build integrity attestation makes sense. I'm a bit less clear about what the right thing to do is in scenario 2, where you have nested source repos that are built from source together with the parent source to produce a single artifact. What integrity info, if any could/should the parent source repo provide in scenario 2 about the submodules?

A few other clarifying questions:

• For all the boxes that say "Trusted", who are those components trusted by?
• Should the deployment tools be attested as part of the source integrity? I would guess that deployment tools might be used in several different components of the the supply chain, including a builder. Do you have a specific use case in mind for including deployment tools under the source category?

[melba-lopez]

per hybrid meeting @camaleon2016 suggesting Jonathan meadows (from citi) to help with the oss/proprietary model that may answer some of these questions. Awaiting diagram.

[marcelamelara]

Based on the Hybrid OSS/Proprietary meetings today and last month, two points have emerged out of these discussions:
(1) developing the source management/repo SLSA requirements is necessary but warrants more time and careful consideration to get right, and
(2) ensuring that the SLSA build requirements cover Hybrid OSS/Proprietary build workflows is a separate effort and should be prioritized for 1.0.

@melba-lopez @MarkLodato Given this split and the focus on Build Levels for 1.0, do we think it would make sense to defer refining source management requirements until after 1.0?

[MarkLodato]

Agreed.

[shaunmlowry]

+1 on deferring this

[marcelamelara]

Per the Specification SIG meeting today, how should we mark this issue? Can we create a post-1.0 tag?

[MarkLodato]

Thanks @marcelamelara. I just moved it to a new "SLSA spec v1.1+" milestone and removed the maybe-1.0 tag.

[TomHennen]

So I think we can now close this bug? We've removed source requirements from the build track, we're working on a separate source track. I think the decision has been made?

[zachariahcox]

agree! marking closed for now.