Add support for package supplier in SBOM

[LaurentGoderre]

The purpose of this field is to help differentiate when a software can have the same name as another. Best example of this is Compose. There are many Compose so being able to specify that it's the Docker package named compose.

Example

{
    "name": "compose",
    "versionInfo": "v2.23.0-desktop.1",
    "supplier": "Docker Inc.",
    ...
}

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ff6b5f2) 73.10% compared to head (5a86c34) 73.10%.
Report is 2 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #86   +/-   ##
=======================================
  Coverage   73.10%   73.10%           
=======================================
  Files           7        7           
  Lines         714      714           
=======================================
  Hits          522      522           
  Misses        162      162           
  Partials       30       30           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yosifkit]

I'm not certain what this field improves or what values would be used for it. Can you add an example to the PR description? And maybe add a field to the jq comment to make it clear that a string is expected?

---

Assuming it isn't a spec-required field, it'd be nice if a new field isn't automatically injected unless opted-in since that would change any generated Dockerfiles (and eventually require some rebuilds). I haven't figured out how to conditionally include a field within creation of the object, but maybe we save the input to a variable and then pipe the object result to a filter to delete fields?

. as $input | { ... } | (if $input.supplier then . else del(.packages[].supplier) end)

🤔 Not certain about this, if we move anything using this SBOM helper to use a specific commit, then "opting-in" is just updating the commit; on the other hand, is a "noassertion" field that useful if this file might also have other helpers that could be the reason for updating.

[LaurentGoderre]

@yosifkit updaterd description.

I haven't been able to conditionally add a field so this a spec compliant way to do it with the noassertion (The Scout Scanner already does it a lot with license info etc...)

[tianon]

I haven't been able to conditionally add a field

👀

{
   ...
} + if .supplier then { supplier: .supplier } else {} end

[LaurentGoderre]

Done!