Emit package_metadata

[arjantop-cai]

Emit package_metadata from https://github.com/bazel-contrib/supply-chain for apko packages.

This allows bazel SBOM tooling to include apko packages in the produced SBOM using tooling in supply-chain.

While chainguard packages already have SBOM and apko produces SBOM for the built image that cannot currently be wired in the supply-chain tooling. This is an attempt to get at least some metadata that can be included in final image SBOM (base image + eg. Go dependencies from service).

Resolves #306

[xnox]

i am not sure i like this. apko is capable of producing very rich sboms in spdx format with a lot of purl references. With more data than just synthesized pkg:apk.

Have you seen the spdx sboms that apko can produce natively? Can that be attached verbantim, or as an extracted flat list of external refs & purls?

[xnox]

Opened:

• Best way to integrate into rules_apko bazel-contrib/supply-chain#172

I hope to have some better way to reuse the rich SBOM we provide.

[arjantop-cai]

As I mentioned above that is not possible right now.
Unlikely the aspect can even access apko built SBOM as that is a built action.
Extracting from APK might be possible but there is currently no such support in baze; supply chain tooling.

[xnox]

@alexeagle is there a way to integrate apko generated sboms, higher up with bazel supply-chain etc? Because apko produces very rich SBOM and it is best for it to remain published and accessible and bubble up. Alternatively, I wonder if we should develop a better pattern to publish sbom along side the containers as an attestation.

[darkrift]

@xnox supply-chain is still in it's infancy, but what I can see is that rules_apko is not stitching dependencies together which could help with SBOM relationship.

Also, there is a notion of "attributes" on package_metadata that is being worked on that could help keep lots of information associated to that package in addition to what is in the PURL.

[xnox]

the sbom and packages have accurate purls, please reuse them without reconstruction. Also ideally existing sbom should be propagated. If need be we can make it at lock creation; rather than at bazel build time. That way prebuilt sbom could be parsed and reused.

[xnox]

The current approach is ok, if it works for you. And do use it and iterate on it by using patch against fetching rules_apko. However, this doesn't quite fit the apko/melange already rich SBOM.