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

[TomHennen]

Per this discussion we haven't really identified how to do this yet. I don't think we need to for SLSA 1.2, but should try to address soon-ish?

[TomHennen]

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.

[arewm]

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.