You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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?
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:
Inspecting the SBOM will show the digest for the version instead of 'latest', e.g.:
The same happens when passing 'latest' as version explicitly:
Anything else we need to know?:
I believe the code that causes the replacement of 'latest' with the digest can be found here:
syft/syft/source/stereoscopesource/image_source.go
Line 63 in 25f5c67
Subsequently being called, below, e.g.:
syft/syft/source/stereoscopesource/image_source.go
Line 87 in 25f5c67
I.e., it treats the value of 'latest' as if the version has not been set.
Environment:
Output of
syft version
:Application: syft
Version: 1.13.0
BuildDate: 2024-09-24T13:28:58Z
GitCommit: 01de99b
GitDescription: v1.13.0
Platform: linux/amd64
GoVersion: go1.22.7
Compiler: gc
OS (e.g:
cat /etc/os-release
or similar):NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
The text was updated successfully, but these errors were encountered: