Add '--version' param for Syft (for when project version is unclear)

[bardenstein]

What would you like to be added:
Like the --name param, add an optional --version param so denote the version of a project (e.g. 1.0, 1.0.1, etc.)

Why is this needed:
If we run syft on a python project, for example, we can manually hardcode the name of the project, but the resulting SBOM doesn't have any metadata on the version. So if we update the project and create an updated SBOM, we can't easily tell which SBOM relates to which version.

Additional context:

[kzantow]

@bardenstein -- there is already a syft --version, which prints the version. Maybe we could augment the --name to have the format name@version or something similar?

[kzantow]

@jedevc -- is this something that would be useful for your usage? (and if we did modify --name, maybe it would be better to rename it to --root-package or something?)

[bardenstein]

@kzantow it's less about printing the version of syft, but about adding 'version' data to an SBOM, given that the syft generator doesn't have any context about the version of a software project when its run.

Here's the full story:

1. We run syft on a python repository, pointing to the requirements.txt file
2. The resulting SBOM didn't have any 'name' or 'version' metadata
3. We then updated the syft command to add the --name param, where we hard code the name of the python project (call it 'my-python-project')
4. However, our 'my-python-project' SBOM still doesn't have any version information. For example, if I generate an SBOM for my-python-project version 2.1, it should say '2.1' somewhere in the SBOM. Then when we make changes and publish, we'll automatically generate an SBOM for 2.2 and can tell which SBOM corresponds to version 2.1 versus 2.2.

What we'd love to see is some param so I could run something like:
syft /path/to/my-python-project/requirements.txt -o sbom-syft.json -f outputBom.json --name "my-python-project" --add-version 2.2

[kzantow]

Yes, @bardenstein I understand the ask here -- the point is that there already is a --version flag at the global level. And it almost seems like the --name flag would do what you want, if it could also include a version. I'm not opposed to another flag, either, just suggesting.

[bardenstein]

@kzantow Got it. For SBOM consistency and matching the spec, having the target version number in its own "version" field (as supposed to being lumped in with name) would be ideal.

Is that something the syft team is willing to add on or build out? Understand not wanting to conflict the nomenclature of the existing --version command. More broadly, it could be helpful to have an 'add' command, that allows a user to add in field:value pairs within the SBOM to incorporate other relevant context.

[jedevc]

Agreed, I think it would be good if version info could be "somewhere in the sbom". Though actually, I think (in the context of buildkit-syft-scanner) we probably won't aim for the idea of a "globally unique name", more one that is locally unique within the context of the image (e.g. the image stage name, or the name of the local context).

This is for the same reason that we have to do moby/buildkit#3258 with layers in buildkit - we don't know the name of the image (or even if there is an image name) until the very end of the export, so we'll likely place logic for naming explicitly in there (though we'll try and set --name to something reasonable before that).

Maybe we could augment the --name to have the format name@version or something similar?

Hm, so this is challenging. I like the succinctness, but this means that because this value is parsed explicitly, we have to avoid @ in the name directly. Does the version number actively need to be a separate field? If not, the user can just put it in the --name field, where it should be propagated through to the end result. Then it's up to the user how to notate versioning info.

[tgerla]

We just discussed this as a team and we think that this would be a useful feature to add but we would need a better option than "--version" since that is usually used to report to the version of the tool itself. Something like "--pkg-version" or "--name-version" might work.

[tgerla]

@jedevc, what if we parsed out the last @ in the --name parameter? That would allow you to have an @ in the package name and also include a version. Happy to hear your thoughts.

[jedevc]

@tgerla yup that seems good to me 🎉

[kzantow]

Quick implementation note:

@org/package is something that might be typically seen in NPM, so we would not want to use the trailing information if the package name starts with @. If there are packages with an @ in the middle, a simple workaround should be to append an @ with no version, if you do not want to provide a version, like: p@ackage@

[sej7278]

i'd actually like an extension of this - a metadata name,value facility, so we could pass in for example:

--metadata=publisher,simon --metadata=version,1.0

or perhaps with a delimiter:

-m copyright,"do what you want";licence,Apache-2.0

imho we should be able to pass in any of the top-level tags in cases where syft is not identifying them correctly. maybe even have a csv file or somesuch as input?

[kzantow]

Hi @sej7278 -- I've implemented this feature request with the --source-version flag, but it doesn't cover the ask in your comment above. Could you open a new issue to track that?

[sej7278]

@kzantow done, see #1869