Define how SLSA _source_ properties should be incorporated into the VSAs for built artifacts #1492

Activity

1. github-project-automation

   added this to Issue triageon Oct 13, 2025
2. github-project-automation

   moved this to 🆕 New in Issue triageon Oct 13, 2025
3. TomHennen commented on Oct 13, 2025

   

   TomHennen

   on Oct 13, 2025

   ContributorAuthor

   More actions

   My suggestion:

   The build artifact's VSA can take the lower-common-denominator properties over all of the source repos listed as dependencies.

   E.g.

   Source Repo 1: SLSA_SOURCE_LEVEL_4, ORG_SOURCE_TESTED
   Source Repo 2: SLSA_SOURCE_LEVEL_3, ORG_SOURCE_FUZZED, ORG_SOURCE_TESTED

   Binary artifact built with an L3 builder: SLSA_BUILD_LEVEL_3, SLSA_SOURCE_LEVEL_3, ORG_SOURCE_TESTED.
4. arewm commented on Oct 13, 2025

   

   arewm

   on Oct 13, 2025

   Member

   More actions

   I think I made the same assumptions.

   We merged a change where source VSAs can have dependencies of other sources (i.e. submodules).

   I had always thought of artifact dependencies as being artifact-typed dependencies (i.e. wheels, RPMs, etc.).

   But our definition of resolvedDependencies likely supports @puerco's representation where sources are dependencies as well.

   All artifacts fetched during initialization or execution of the build process are considered dependencies, including those referenced directly by parameters. The resolvedDependencies captures these dependencies, if known. For example, a build that takes a git repository URI as a parameter might record the specific git commit that the URI resolved to as a dependency.

   We also migrated away from configSource in 1.0, now everything is contained within the buildDefinition section.

   configSource: No longer special-cased. Now represented as externalParameters + resolvedDependencies.

   and we defined externalParameters as

   externalParameters: the external interface to the build. In SLSA, these values are untrusted; they MUST be included in the provenance and MUST be verified downstream.

   @TomHennen 's logic makes sense, but that same logic would apply whether we represent the source level in the verifiedLevels or in the dependencyLevels.
5. TomHennen

   added

   source-track

   on Oct 23, 2025
6. github-project-automation

   added this to SLSA Source Trackon Oct 23, 2025