Allow users to set primary component metadata as part of the generation

[vpetersson]

Description

I'm part of the CISA Tiger Team for SBOM Reference Implementation. We've adopted Trivy as part of our tool chain for the first iteration of our reference implementation.

While Trivy works well in general, we have some feedback that would make it easier to generate NTIA Minimum Element compliant SBOMs (which is the goal of the Tiger Team).

The feedback is as follows:

• Allow users to specify a the following as command line arguments:
  • Version
  • Name
  • License
  • Manufacturer
  • Supplier

(Note: Using CycloneDX just as an example)

We've worked around these constraints using sbomasm (example), but it would streamline things a lot of this could be provided as part of the generation phase.

Target

Filesystem

Scanner

None

[knqyf263]

We've adopted Trivy as part of our tool chain for the first iteration of our reference implementation.

We're glad to hear that! Thanks for sharing.

Allow users to specify a the following as command line arguments:

While this suggestion makes sense, it will add too many CLI flags and is not flexible. If users have another need, like specifying components[].purl, we need to add a new flag.

So, I'd suggest using JSON Patch or JSON Merge Patch. Users create a JSON patch and pass it to Trivy when generating SBOM, like trivy image --format cyclonedx --sbom-json-patch ./my-sbom-template.patch my-image:latest. It wouldn't work with SPDX text format, but I think it's acceptable. I personally prefer JSON Merge Patch, but need to check if it meets the requirements. I'm just thinking out loud. Any feedback is welcome.

[knqyf263]

Just to be clear, we're not talking about adding elements for components, just the top level component.

Yes, I understand. I meant needs will continue to expand. It may be just the top-level component at the moment, but users may want to specify other metadata, and it is not practical to add a new flag each time they do so.

It's good to know that there's support for JSON patching in Trivy.

I'm talking about a feature enhancement. It's not supported in Trivy now.

We initially used jq for patching the JSON, but it's really cumbersome when you need to deliver both SPDX and CycloneDX, which is the deliverable for our working group.

If you need a format-agnostic approach, we need to consider something else because the idea I suggested requires JSON patches for SPDX and CycloneDX, respectively.

What if creating a new plugin for sbomasm? Here is the plugin list. People can call sbomasm as part of Trivy, like trivy sbomasm edit --subject primary-component --name "cool-app" --version "v1.0.0" --type "application" --output cool-app-mod.spdx.json cool-app.spdx.json. It's just a wrapper of sbomasm, but it looks more integrated into Trivy and may provide a better user experience.

Another idea is that since Trivy has an intermediate representation of SBOM, it might be possible to patch against it and convert it to SPDX or CycloneDX format independently.

[vpetersson]

I completely understand that this might be a slippery slope.

The plugin approach might be the cleanest solution. I like that. Let me ponder on this for a bit. Maybe a simple Bash plugin would suffice.

[knqyf263]

The developer documentation is here.
https://aquasecurity.github.io/trivy/v0.57/docs/plugin/developer-guide/

Some plugins are written in a shell script.

• https://github.com/aquasecurity/trivy-plugin-kubectl/blob/main/trivy-kubectl
• https://github.com/fatihtokus/scan2html/blob/main/scan2html.sh

[knqyf263]

If you agree on the plugin approach, we can help with that.

[knqyf263]

FYI: Trivy also supports output plugins. It provides a more integrated UX, like

$ trivy image --format cyconedx --output plugin=sbomasm --output-plugin-arg "--subject primary-component --name "cool-app" --version "v1.0.0" --type "application" --output cool-app-mod.spdx.json myimage:latest"

This is the reference implementation.