Generate CycloneDX SBOMs using our own JSON generation

[imjasonh]

Example output: https://gist.github.com/imjasonh/16185e53200bed16470e5d27e17f261e 👀

cosign download sbom $(go run ./ build ./ --sbom=cyclonedx)                                                                                                                                  

[imjasonh]

Compare this output to that generated by the cyclonedx-gomod library proposed in #573: https://gist.github.com/imjasonh/31002f904a28166c9c8c9b6cedd07d96

[codecov-commenter]

Codecov Report

Merging #587 (23a499c) into main (89ede91) will decrease coverage by 0.39%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #587      +/-   ##
==========================================
- Coverage   48.92%   48.53%   -0.40%     
==========================================
  Files          43       43              
  Lines        2228     2246      +18     
==========================================
  Hits         1090     1090              
- Misses        954      972      +18     
  Partials      184      184              

Impacted Files	Coverage Δ
pkg/build/gobuild.go	56.69% <0.00%> (-0.91%)	⬇️
pkg/build/options.go	69.38% <0.00%> (-4.53%)	⬇️
pkg/commands/deps.go	14.28% <0.00%> (-0.91%)	⬇️
pkg/commands/resolver.go	30.41% <0.00%> (-0.29%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 89ede91...23a499c. Read the comment docs.

[mattmoor]

cc @puerco for thoughts

[puerco]

I think it makes sense to write the small generator for both formats. Since the SBOM is only listing the dependencies for now, pulling in the full spdx/cycloneDX libraries seems like overkill.

@imjasonh how much further do you see ko acquiring more sbom functions? I can think of three main areas which would be good to have, but maybe are out of scope for ko to do these:

1. Licensing information
2. Describing the image(s) structure
3. System packages from the base images

[imjasonh]

I think it makes sense to write the small generator for both formats. Since the SBOM is only listing the dependencies for now, pulling in the full spdx/cycloneDX libraries seems like overkill.

@imjasonh how much further do you see ko acquiring more sbom functions?

Honestly, I hope we don't get too much more sophisticated than this, unless someone needs us to. The cyclonedx-gomod package is huge, but it's also very complete in its functionality. I'd like ko to target a smaller balance: less code, "enough" functionality.

I can think of three main areas which would be good to have, but maybe are out of scope for ko to do these:

1. Licensing information

If we include license information, I'd like to depend on some other service/metadata to look it up. cyclonedx-gomod's bloat largely comes from complex multilingual probabilistic license detection; I don't want to reimplement that, at all.

2. Describing the image(s) structure
3. System packages from the base images

For both of these, I'm hoping to more completely implement cosign's stated SBOM spec (even though AFAIK nobody implements that today). This would let us report this SBOM only for the ko layer(s), and depend on base images to report their own SBOMs, which we can detect and carry forward.

I don't want ko to be responsible for looking into base images and generating SBOMs for them, but I wouldn't mind if it detected existing base image SBOMs and carried those forward.

[puerco]

This would let us report this SBOM only for the ko layer(s), and depend on base images to report their own SBOMs, which we can detect and carry forward.

Awesome, I am currently working on that part. An important feature will be to be able to reference external documents from the deps SBOM generated by ko, I can add that feature for the next release.