False positive in ubuntu openssl 3.0.2

Grype
1

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).

{
  "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 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.

2

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?

3

Hi @popey

Here’s a set of steps

  1. goto 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
1 Like
4

Thanks @tbilou - I think I have reproduced your issue here.

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.

5

yes, that’s exactly what I see :slight_smile:

6

Hm, not sure what’s going on. I have uploaded the SBOM here if someone with more skills than I can see what’s going on.

7

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:

[
  {
    "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 <ubuntu-devel-discuss@lists.ubuntu.com>",
      "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:

{
  "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?

8

Starting with version 3.4 spring boot switched to packet-buildpacks/builder-jammy-java-tiny that uses 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 :frowning:

I guess it’s by design because it’s trying to be a distroless container.

The “easy fix” is to switch to Base.

Tiny

 "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 <ubuntu-devel-discuss@lists.ubuntu.com>",
        "installedSize": 1981,
        "depends": [
          "libc6 (>= 2.34)",
          "libssl3 (>= 3.0.2-0ubuntu1.2)"
        ],
        "files": []
      }

Base and Full

 "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 <ubuntu-devel-discuss@lists.ubuntu.com>",
        "installedSize": 2053,
        "depends": [
          "libc6 (>= 2.34)",
          "libssl3 (>= 3.0.2-0ubuntu1.2)"
        ],
        "files": [
           {
            "path": "/usr/bin/openssl",
            "digest": {
              "algorithm": "md5",
              "value": "728d08afd18da93f8256ec7884140a0e"
            },
            "isConfigFile": false
          }