Provenance: add ability to differentiate between different types of `materials`, e.g. build tool vs library

[MarkLodato]

[Copied from in-toto/attestation/issues/29]

Currently all materials are lumped together (except recipe.definedInMaterial). It would be useful to be able to differentiate between different types of materials. We can probably look to SPDX Relationships for prior art and inspiration.

Example classifications:

• "source" = application-specific code
• "library" / "dependency" = code that was compiled in but part of another project
• "build tool" / "dev dependency" = thing that was used as part of the build invocation but did not get "compiled in"
• "base image" = starting point for the build invocation
• "build orchestrator" = thing that ran on the build orchestrator (not sure if this is even in scope; see in-toto/attestation/issues/25)

Example use cases:

• Supply chain integrity / SLSA: better prioritize the "most important" materials.
• Licensing: identify how the license of the material transfers to the product.
• Vulnerably tracing: better identify which materials are likely to have affected the product.

Currently this can be done ad-hoc using extension fields, but it is probably valuable to standardize this. The main challenge is coming up with something that works well for most cases and can be done in practice by generic builders like GitHub Actions and Google Cloud Build.

[TomHennen]

I think having an explicit/implicit 'unknown' relationship would make it easier to adopt. WDYT?

[MarkLodato]

One question is whether we should go in this territory. An alternative solution is to defer to an SBOM format (CycloneDX or SPDX) for this information, since that is their bread and butter.

[TomHennen]

Leaving to an SBOM makes sense to me.

[MarkLodato]

Sounds good. I'll close as "not planned for now".