Relationship between resolvedDependencies and an SBOM?

[ralphbean]

I'm unsure about something about resolvedDependencies (in the build track) and how it does or doesn't overlap with an SBOM.

From https://slsa.dev/spec/v1.2/build-provenance, resolvedDependencies is an:

Unordered collection of artifacts needed at build time. Completeness is best effort, at least through SLSA Build L3. For example, if the build script fetches and executes “example.com/foo.sh”, which in turn fetches “example.com/bar.tar.gz”, then both “foo.sh” and “bar.tar.gz” SHOULD be listed here.

I think of the SBOM of an artifact as "the list of dependencies" of an artifact. If a particular project pulls in libfoo at build time, then a resolved reference to the specific version of libfoo should appear in the SBOM. In the example above, I would think that at least "example.com/bar.tar.gz" should appear in the SBOM. Possibly "example.com/foo.sh" too.

I tend to think of the SLSA resolvedDependencies as the dependencies of the build process, not necessarily the dependencies of the artifact the way we normally talk about dependencies. For example, for a github workflow run, in my opinion, a good list of items to have in the resolvedDependencies would be the specific digests of the specific GH actions that ran as a part of that workflow. Specific identities of the runners or their images would be a solid bonus.

But, should the SLSA build provenance resolvedDependencies also include the (possibly hundreds of) other software dependencies that a build pulls in?

• Should the SLSA build provenance always be a superset of the SBOM, such that while the SBOM represents the "software dependencies" of the build and the SLSA build provenance includes both that and resolved build system details?
• Should the SLSA build provenance always be disjoint from the SBOM, such that the SBOM represents the "software dependencies" of the build and the SLSA build provenance includes only resolved build system details?

Is it an exercise deliberately left to implementers?

[arewm]

Thanks for this issue, @ralphbean. I agree that it is something that can be clearer.

With the build L3, this does not matter as much because there are no claims to completeness of the resolvedDependencies. With where I would like to see L4 (i.e. resolvedDependencies are complete), however, this will become more important.

I have asked this question myself as well. Based on the following, I believe that the intention was for resolvedDependencies to be a superset of the SBOM (i.e. it includes all software dependencies):

• SLSA v1.0 renamed materials to resolvedDependencies

• In SLSA v0.1, we have:

  metadata.reproducible boolean, optional

  If true, the builder claims that running recipe on materials will produce bit-for-bit identical output.

  materials array of objects, optional

  The collection of artifacts that influenced the build including sources, dependencies, build tools, base images, and so on.

  This is considered to be incomplete unless metadata.completeness.materials is true. Unset or null is equivalent to empty.

• In the current terminology, we have

  • package: Artifact that is distributed. In the model, it is always the output of a build process, though that build process can be a no-op.
  • dependency: Artifact that is an input to a build process but that is not a source. In the model, it is always a package.

• The model of the build provenance indicates

  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.
  During execution, the build process might communicate with the build platform’s control plane and/or build caches. This communication is not captured directly in the provenance, but is instead implied by builder.id and subject to SLSA Requirements. Such communication SHOULD NOT influence the definition of the build; if it does, it SHOULD go in resolvedDependencies instead.

Therefore, according to the spec, foo.sh should be in the resolvedDependencies if it is fetched, however if that script is in the source then it wouldn't be there. I would imagine that the same rules would apply to the SBOM too.

What this essentially means is that the provenance essentially becomes another SBOM format even if it is not standardized/extensible like other popular SBOM formats. I don't feel like this is really the role that provenance should be filling though. Further complicating matters is that many build platforms don't have the ability to produce accurate build-time SBOMs. Instead, the build processes use tools to analyze the sources and built artifacts in order to construct the SBOM.

My thoughts on the matter are that if we want to be able to claim completeness of resolved dependencies in the provenance then we need to allow for flexibility in the resolvedDependencies within the provenance. If the build platform is capable of producing an accurate and complete build-time SBOM then we should enable that to sit on its own and include it in the "completeness" claims. I see that this might be able to take at least a couple of forms:

• Referring to an SBOM from within the provenance
• Generating an SBOM attestation using the same identity as the provenance (there are already published predicates for cyclonedx and spdx)

The former would be simpler to discover from the provenance but the latter feels cleaner. If a build platform does not generate and reference an appropriate SBOM then completeness would be judged just on the resolvedDependencies.

---

My hope was that we would be able to clarify it as part of the dependency track work (the current requirements draft is here). But it I think we definitely need to clarify it before a SLSA build L4.

[arewm]

@adriandiglio @tombedfordgit, I meant to tag you in that last post when I mentioned the dependency track but I forgot.