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 syft is executed multiple times against the same image with a Java artifact (e.g., jdom 1.1) I receive slightly different purls on each run. This seems somewhat similar to the recent issue #1944 which was fixed in Syft v0.91.0.
What you expected to happen:
I expect the purl generated by syft to be consistent between runs of the same image with the same set of artifacts and versions.
Anything else we need to know?:
This can also result in different vuln results when the sbom is evaluated by grype.
For example if we copy/modify the sbom to have the correct purl: "purl": "pkg:maven/org.jdom/[email protected]", we get both the CVE and the GHSA match. With the original purls we do not get the GHSA result (Yes, I understand that the GHSA result maps to the same CVE id).
Example:
> cp jdom-purl.syft.run2.json jdom-purl.syft.edit.json && sed -i 's@jdom\..*\/@jdom\/@' jdom-purl.syft.edit.json
> grep purl.*org\.jdom jdom-purl.syft.*.json
jdom-purl.syft.edit.json: "purl": "pkg:maven/org.jdom/[email protected]",
jdom-purl.syft.run1.json: "purl": "pkg:maven/org.jdom.filter/[email protected]",
jdom-purl.syft.run2.json: "purl": "pkg:maven/org.jdom.input/[email protected]",
> for sbom in `ls jdom-purl.syft.*.json`; do echo "Scanning sbom: ${sbom}:"; grype -q sbom:${sbom} | grep jdom; done
Scanning sbom: jdom-purl.syft.edit.json:
jdom 1.1 java-archive GHSA-2363-cqg2-863c High
jdom 1.1 java-archive CVE-2021-33813 High
Scanning sbom: jdom-purl.syft.run1.json:
jdom 1.1 java-archive CVE-2021-33813 High
Scanning sbom: jdom-purl.syft.run2.json:
jdom 1.1 java-archive CVE-2021-33813 High
NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.9 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.9:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.9
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.9"
The text was updated successfully, but these errors were encountered:
I suspect the bug affects all Java/Maven purl generation, nothing to do with jdom in particular, but that was just how I came across it based on the missing GHSA vuln. Thanks for confirming.
What happened:
When syft is executed multiple times against the same image with a Java artifact (e.g.,
jdom 1.1
) I receive slightly differentpurls
on each run. This seems somewhat similar to the recent issue #1944 which was fixed in Syft v0.91.0.What you expected to happen:
I expect the
purl
generated by syft to be consistent between runs of the same image with the same set of artifacts and versions.Steps to reproduce the issue:
Build an image recreating the issue:
Scan the image multiple times with syft, creating multiple sbom files for each run:
Validate the
purl
generated for thejdom
artifact in each syft sbom:Note that the
purl
is showing a different sub-artifact on each run?! I believe the expectedpurl
should be:"purl": "pkg:maven/org.jdom/[email protected]",
Anything else we need to know?:
This can also result in different vuln results when the sbom is evaluated by grype.
For example if we copy/modify the sbom to have the correct purl:
"purl": "pkg:maven/org.jdom/[email protected]",
we get both the CVE and the GHSA match. With the original purls we do not get the GHSA result (Yes, I understand that the GHSA result maps to the same CVE id).Example:
Environment:
syft version
:cat /etc/os-release
or similar):The text was updated successfully, but these errors were encountered: