# False positive in ubuntu openssl 3.0.2 **URL:** \ **Category:** Grype\ **Created:** [January 22, 2025, 5:13pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312 "2025-01-22T17:13:45Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![tbilou](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/tbilou/32/230_2.png) [@tbilou](https://anchorecommunity.discourse.group/u/tbilou)\ **Post date:** [January 22, 2025, 5:13pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/1 "2025-01-22T17:13:45Z")
Hello, We run Grype as part of our CI pipelines in GitHub and if a critical vulnerability is detected the build fails. Recently I moved a Spring boot project (3.4.1) to GitHub and Grype flagged a couple of critical vulnerabilities on openssl (docker). ```auto { "package": "openssl", "type": "binary", "cve": "CVE-2024-5535", "location": "/usr/bin/openssl" } { "package": "openssl", "type": "binary", "cve": "CVE-2022-2068", "location": "/usr/bin/openssl" } { "package": "openssl", "type": "binary", "cve": "CVE-2022-1292", "location": "/usr/bin/openssl" } ``` The docker image was built with paketobuildpacks using builder-jammy-java-tiny (spring-boot defaults) I checked the repo and found an [issue](https://github.com/paketo-buildpacks/builder-jammy-java-tiny/issues/32) about this exact thing. It there is states that: "As all Paketo stacks are currently based on Ubuntu, please also check their security tracker. Often times Canonical fixes security issues “out of band” which is not known to all scanners. - CVE-2022-1292: `22.04 LTS jammy, Fixed 3.0.2-0ubuntu1.1 ` - CVE-2022-2068: `22.04 LTS jammy, Fixed 3.0.2-0ubuntu1.5` - CVE-2024-5535: `22.04 LTS jammy Fixed 3.0.2-0ubuntu1.17` The builder currently ships version `3.0.2-0ubuntu1.18` of the openssl package." So it looks like the openssl package from ubuntu is patched, but Grype is still reporting it which is failing the build. I can disable Grype in the workflow to make the build pass, but I’m wondering if there’s something else that can be done in this case. ---
**Author:** ![popey](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/popey/32/429_2.png) [@popey](https://anchorecommunity.discourse.group/u/popey)\ **Post date:** [January 23, 2025, 11:36am UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/2 "2025-01-23T11:36:36Z")
Hi @tbilou Thanks for the report. Do you have a reproducible set of steps so we can run to replicate the issue and debug it here? ---
**Author:** ![tbilou](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/tbilou/32/230_2.png) [@tbilou](https://anchorecommunity.discourse.group/u/tbilou)\ **Post date:** [January 23, 2025, 12:23pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/3 "2025-01-23T12:23:44Z")
Hi @popey Here’s a set of steps 1. goto [https://start.spring.io](https://start.spring.io) and click the generate button 2. unzip the demo.zip 3. run `./gradlew bootBuildImage -x test` to build the docker image 4. run `grype docker.io/library/demo:0.0.1-SNAPSHOT` to get the report ---
**Author:** ![popey](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/popey/32/429_2.png) [@popey](https://anchorecommunity.discourse.group/u/popey)\ **Post date:** [January 23, 2025, 4:57pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/4 "2025-01-23T16:57:09Z")
Thanks @tbilou - I think I have reproduced your issue here. ```auto grype demo.json ✔ Scanned for vulnerabilities [49 vulnerability matches] ├── by severity: 3 critical, 17 high, 20 medium, 6 low, 1 negligible (2 unknown) └── by status: 41 fixed, 8 not-fixed, 0 ignored NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY golang.org/x/net v0.32.0 0.33.0 go-module GHSA-w32m-9786-jp63 High libc6 2.35-0ubuntu3.8 deb CVE-2025-0395 Medium libc6 2.35-0ubuntu3.8 deb CVE-2016-20013 Negligible libssl3 3.0.2-0ubuntu1.18 deb CVE-2024-9143 Low libssl3 3.0.2-0ubuntu1.18 deb CVE-2024-41996 Low libssl3 3.0.2-0ubuntu1.18 deb CVE-2024-13176 Low openjdk 17.0.13+12-LTS 1.8.0_441, 11.0.26, 17.0.14, 21.0.6, 23.0.2, 8.0.441 binary CVE-2025-21502 Medium openssl 3.0.2 1.0.2zk, 1.1.1za, 3.0.15, 3.1.7, 3.2.3, 3.3.2 binary CVE-2024-5535 Critical openssl 3.0.2 1.0.2zf, 1.1.1p, 3.0.4 binary CVE-2022-2068 Critical openssl 3.0.2 1.0.2ze, 1.1.1o, 3.0.3 binary CVE-2022-1292 Critical openssl 3.0.2 3.0.15, 3.1.7, 3.2.3, 3.3.2 binary CVE-2024-6119 High openssl 3.0.2 1.1.1y, 3.0.14, 3.1.6, 3.2.2, 3.3.1 binary CVE-2024-4741 High openssl 3.0.2 3.0.12, 3.1.4 binary CVE-2023-5363 High openssl 3.0.2 1.1.1w, 3.0.11, 3.1.3 binary CVE-2023-4807 High openssl 3.0.2 1.0.2zh, 1.1.1u, 3.0.9, 3.1.1 binary CVE-2023-0464 High openssl 3.0.2 3.0.8 binary CVE-2023-0401 High openssl 3.0.2 1.0.2zg, 1.1.1t, 3.0.8 binary CVE-2023-0286 High openssl 3.0.2 3.0.8 binary CVE-2023-0217 High openssl 3.0.2 3.0.8 binary CVE-2023-0216 High openssl 3.0.2 1.0.2zg, 1.1.1t, 3.0.8 binary CVE-2023-0215 High openssl 3.0.2 1.1.1t, 3.0.8 binary CVE-2022-4450 High openssl 3.0.2 3.0.8 binary CVE-2022-3996 High openssl 3.0.2 3.0.7 binary CVE-2022-3786 High openssl 3.0.2 3.0.7 binary CVE-2022-3602 High openssl 3.0.2 3.0.6 binary CVE-2022-3358 High openssl 3.0.2 3.0.3 binary CVE-2022-1473 High openssl 3.0.2 1.0.2zl, 1.1.1zb, 3.0.16, 3.1.8, 3.2.4, 3.3.3 binary CVE-2024-9143 Medium openssl 3.0.2 3.0.14, 3.1.6, 3.2.2, 3.3.1 binary CVE-2024-4603 Medium openssl 3.0.2 1.0.2zj, 1.1.1x, 3.0.13, 3.1.5 binary CVE-2024-0727 Medium openssl 3.0.2 3.0.13, 3.1.5, 3.2.1 binary CVE-2023-6237 Medium openssl 3.0.2 3.0.13, 3.1.5, 3.2.1 binary CVE-2023-6129 Medium openssl 3.0.2 1.0.2zj, 1.1.1x, 3.0.13, 3.1.5 binary CVE-2023-5678 Medium openssl 3.0.2 3.0.10, 3.1.2 binary CVE-2023-3817 Medium openssl 3.0.2 1.0.2zi, 1.1.1v, 3.0.10, 3.1.2 binary CVE-2023-3446 Medium openssl 3.0.2 3.0.10, 3.1.2 binary CVE-2023-2975 Medium openssl 3.0.2 1.0.2zh, 1.1.1u, 3.0.9, 3.1.1 binary CVE-2023-2650 Medium openssl 3.0.2 3.0.9, 3.1.1 binary CVE-2023-1255 Medium openssl 3.0.2 1.0.2zh, 1.1.1u, 3.0.9, 3.1.1 binary CVE-2023-0466 Medium openssl 3.0.2 1.0.2zh, 1.1.1u, 3.0.9, 3.1.1 binary CVE-2023-0465 Medium openssl 3.0.2 1.0.2zg, 1.1.1t, 3.0.8 binary CVE-2022-4304 Medium openssl 3.0.2 3.0.8 binary CVE-2022-4203 Medium openssl 3.0.2 1.1.1q, 3.0.5 binary CVE-2022-2097 Medium openssl 3.0.2 3.0.3 binary CVE-2022-1434 Medium openssl 3.0.2 3.0.3 binary CVE-2022-1343 Medium openssl 3.0.2 1.1.1y, 3.0.14, 3.1.6, 3.2.2 binary CVE-2024-2511 Unknown openssl 3.0.2 1.0.2zl, 1.1.1zb, 3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.1 binary CVE-2024-13176 Unknown openssl 3.0.2-0ubuntu1.18 deb CVE-2024-9143 Low openssl 3.0.2-0ubuntu1.18 deb CVE-2024-41996 Low openssl 3.0.2-0ubuntu1.18 deb CVE-2024-13176 Low ``` I tried adding `--distro ubuntu:22.04` but that didn’t help. ---
**Author:** ![tbilou](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/tbilou/32/230_2.png) [@tbilou](https://anchorecommunity.discourse.group/u/tbilou)\ **Post date:** [January 24, 2025, 5:59pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/5 "2025-01-24T17:59:36Z")
yes, that’s exactly what I see 🙂 ---
**Author:** ![popey](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/popey/32/429_2.png) [@popey](https://anchorecommunity.discourse.group/u/popey)\ **Post date:** [January 28, 2025, 3:53pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/6 "2025-01-28T15:53:14Z")
Hm, not sure what’s going on. I have uploaded the SBOM [here](https://popey.com/~alan/demo.json) if someone with more skills than I can see what’s going on. ---
**Author:** ![willmurphy](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/willmurphy/32/12_2.png) [@willmurphy](https://anchorecommunity.discourse.group/u/willmurphy)\ **Post date:** [January 28, 2025, 4:22pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/7 "2025-01-28T16:22:41Z")
The first piece of the puzzle is that the SBOM contains 2 openssl packages: - `pkg:generic/openssl@3.0.2` - `pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.18?arch=amd64&distro=ubuntu-22.04` That means that Grype is matching the `pkg:generic` one against NVD CPE data (because we don’t have information about where it came from). This package was identified by the binary classifier cataloger in Syft (in other words, Syft emitted this package because a binary file named `openssl` matched a regex). The `pkg:deb` one is from Syft inspecting the OS package manager state and finding that this package was installed. Because we found a `deb` on an Ubuntu image, Grype knows to match against Ubuntu CVE data, and we _don’t_ get these extra matches on this package. Normally, Syft should subsume the binary classifier package into the openssl package. Here’s a subset of the SBOM JSON showing both packages: ```json [ { "name": "openssl", "purl": "pkg:generic/openssl@3.0.2", "metadata": { "matches": [ { "classifier": "openssl-binary", "location": { "path": "/usr/bin/openssl", "layerID": "sha256:39dea526828532c102c61520b6925455da5ab79811424534c2dad3a4a1b60a64", "accessPath": "/usr/bin/openssl", "annotations": { "evidence": "primary" } } } ] } }, { "name": "openssl", "purl": "pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.18?arch=amd64&distro=ubuntu-22.04", "metadata": { "package": "openssl", "source": "", "version": "3.0.2-0ubuntu1.18", "sourceVersion": "", "architecture": "amd64", "maintainer": "Ubuntu Developers ", "installedSize": 2053, "depends": [ "libc6 (>= 2.34)", "libssl3 (>= 3.0.2-0ubuntu1.2)" ], "files": [] } } ] ``` The way Syft decides that a binary classifier package (`/usr/bin/openssl` matching a regex) and the dpkg entry for the dep `openssl` are “the same” and should be deduplicated is by path operations: If the dpkg `files` field includes the path to the binary, they are “the same”. So the reason you’re getting these FPs is: 1. Syft finds a binary package at `/usr/bin/openssl` and a dpkg `openssl` 2. Syft would like to deduplicate these, but Syft _doesn’t_ find any information about what files are owned by the dpkg 3. Both files are passed on to Grype 4. Grype compares the dpkg version to the Ubuntu data and doesn’t omit matches on openssl, and then compares the binary version to the NVD CPE data and _does_ find matches, so the matches are emitted. To me, step 2 is the mystery: why isn’t Syft finding the file ownership info for the dpkgs? Just to confirm, I ran Syft on `ubuntu:latest`, and Syft _does_ generally find dpkg file ownership info. For example, here’s a package with the files we expected to see: ```json { "name": "zlib1g", "purl": "pkg:deb/ubuntu/zlib1g@1:1.2.11.dfsg-2ubuntu9.2?arch=arm64&distro=ubuntu-22.04&upstream=zlib", "files": [ { "path": "/lib/aarch64-linux-gnu/libz.so.1.2.11", "digest": { "algorithm": "md5", "value": "9f585f77c82caf29915fb7f7c4d895f8" }, "isConfigFile": false ... snip ... ] } ``` So the question is: On your image/sbom, why _don’t_ we see anything in the `.metadata.files` field on the Syft artifact that represents the dpkg metadata? Is your dpkg data getting cleared or partially cleared during a docker build maybe? Any other ideas? ---
**Author:** ![tbilou](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/tbilou/32/230_2.png) [@tbilou](https://anchorecommunity.discourse.group/u/tbilou)\ **Post date:** [January 28, 2025, 8:48pm UTC](https://anchorecommunity.discourse.group/t/false-positive-in-ubuntu-openssl-3-0-2/312/8 "2025-01-28T20:48:32Z")
Starting with version 3.4 spring boot switched to _packet-buildpacks/builder-jammy-java-tiny_ that uses [jammy-tiny-stack](https://github.com/paketo-buildpacks/jammy-tiny-stack). I ran syft against all 3 stacks Jammy Tiny, Jammy Base and Jammy Full In the Base and Full stack the `.metadata.files` is there, but in the Tiny it’s not ☹ I guess it’s [by design](https://github.com/paketo-buildpacks/jammy-tiny-stack/blob/50305798894de776ac83d469ef693f1d99a62b49/stack/run/run.Dockerfile#L46) because it’s trying to be a distroless container. The “easy fix” is to switch to Base. ### Tiny ```auto "purl": "pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.18?arch=arm64&distro=ubuntu-22.04", "metadataType": "dpkg-db-entry", "metadata": { "package": "openssl", "source": "", "version": "3.0.2-0ubuntu1.18", "sourceVersion": "", "architecture": "arm64", "maintainer": "Ubuntu Developers ", "installedSize": 1981, "depends": [ "libc6 (>= 2.34)", "libssl3 (>= 3.0.2-0ubuntu1.2)" ], "files": [] } ``` ### Base and Full ```auto "purl": "pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.18?arch=amd64&distro=ubuntu-22.04", "metadataType": "dpkg-db-entry", "metadata": { "package": "openssl", "source": "", "version": "3.0.2-0ubuntu1.18", "sourceVersion": "", "architecture": "amd64", "maintainer": "Ubuntu Developers ", "installedSize": 2053, "depends": [ "libc6 (>= 2.34)", "libssl3 (>= 3.0.2-0ubuntu1.2)" ], "files": [ { "path": "/usr/bin/openssl", "digest": { "algorithm": "md5", "value": "728d08afd18da93f8256ec7884140a0e" }, "isConfigFile": false } ```