Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syft always replaces 'latest' version with digest, even when passed explicitly with --source-version #3303

Open
dbrugman opened this issue Oct 7, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@dbrugman
Copy link

dbrugman commented Oct 7, 2024

What happened:
When generating SBOMs (at least for the CycloneDX XML format) for images with the 'latest' tag, the 'version' element in the SBOM gets assigned the value of the image digest instead of the value 'latest'. This causes regressions in our automation pipelines, where the value 'latest' is expected for the image versions. This even happens when the 'latest' version is explicitly passed via the --source-version argument. (Not sure exactly when this was introduced, the issue remained unnoticed for at least a few months)

I understand that the 'latest' tag is typically volatile, given that the 'latest' tag will likely point to different images over time. However, in our process we regenerate the 'latest' SBOMs for the 'latest' images automatically, and in addition we have to cater for some images where the 'latest' tag is not properly used. Our current workaround is to set a dummy version-token as the 'source-version', and then post-process the SBOM with sed, replacing the token with the actual tag (e.g., 'latest').

What you expected to happen:
I would expect that the version element in the SBOM reflects the version/tag of the image as specified via the image argument. E.g., when I invoke 'syft scan myimage:latest', explicitly specifying 'latest', I expect that the SBOM will also include 'latest' as the version. Only when I invoke syft without specifying an image tag (e.g., 'syft scan myimage'), and syft automatically infers 'latest' internally, I think it makes sense to use the digest instead.

Also, when passing 'latest' explicitly as the 'source version', I would definitely expect that to be honored, and not getting replaced with the digest.

A command-line argument that would prevent the replacement of 'latest' by the digest could be an alternative solution.

Steps to reproduce the issue:
This can be reproduced by generating an SBOM for the 'latest' Ubuntu image:

syft -q scan -o cyclonedx ubuntu:latest > ubuntu_latest.bom.xml

Inspecting the SBOM will show the digest for the version instead of 'latest', e.g.:

    <component bom-ref="66f265fe5d67425c" type="container">
      <name>ubuntu</name>
      <version>sha256:19022ba720af5cb90755e0ed007dd9729c76db322e17dd292cc993ae0b8a020d</version>
    </component>

The same happens when passing 'latest' as version explicitly:

syft -q scan -o cyclonedx --source-name "ubuntu" --source-version "latest" ubuntu:latest > ubuntu_latest.bom.xml

Anything else we need to know?:
I believe the code that causes the replacement of 'latest' with the digest can be found here:

if version != "" && version != "latest" {

Subsequently being called, below, e.g.:

versionIfUnset(s.metadata.ManifestDigest)

I.e., it treats the value of 'latest' as if the version has not been set.

Environment:

@dbrugman dbrugman added the bug Something isn't working label Oct 7, 2024
@spiffcs
Copy link
Contributor

spiffcs commented Oct 7, 2024

@dbrugman - thanks so much for filing the issue!

I think we agree on the 2nd part of your issue where you mention that "latest" should be the version and respected when using the --source-version flag.

However, when it comes to the out of the box behavior we believe it is correct to interpret the version from the command

syft -q scan -o cyclonedx ubuntu:latest > ubuntu_latest.bom.xml

as the digest given the points made about how unstable latest is and the inability for the documents to be distinct across the moving tag.

If we were to fix syft so that the --source-version flag respected latest and did not include digest as the version would that be a solution for your current issue?

@dbrugman
Copy link
Author

dbrugman commented Oct 7, 2024

@spiffcs - thanks for the reply! I understand your point. Respecting the source-version flag would be an adequate solution I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Backlog
Development

No branches or pull requests

2 participants