False positives on Bitnami packages due to versions with revisions

[juan131]

IDs

none

Description

Bitnami packages use semver for versioning. This versioning is built based on the upstream project's versioning appending a revision (-X) to reflect changes on Bitnami packaging (e.g. if the compilation recipe used to build binaries changed).

For instance, if we inspect this Dockerfile used to build bitnami/apache container, we can see the versioning for "apache" package is 2.4.58-1, where -1 indicates the revision.

However, according to the semver spec, these revision are considered pre-releases and this is problematic since the semver package used by Trivy for comparing versions will consider any x.y.z-R version lower than x.y.z. And, reverting this versioning would have a high cost on Bitnami systems.

Currently, this is not a problem given both vulnerabilities listed at Bitnami Vulnerability Database and SPDX files shipped on Bitnami containers ignore revisions when listing packages. That said, we (Bitnami team) would like to start using revisions on both the vulnerability feed and SBOM(s) since there are use cases where a CVE can be fixed at a specific revision (e.g. using certain compilation flags to mitigate it).

Let's use this issue to discuss possible alternatives to avoid false positives detections if revisions are used.

Reproduction Steps

1. Given the SBOM below (SPDX format):

{
    "SPDXID": "SPDXRef-XXX",
    "spdxVersion": "SPDX-2.3",
    "creationInfo": {
        "created": "2023-11-10T15:04:13.848Z",
        "creators": [
            "Organization: VMware, Inc."
        ]
    },
    "name": "SPDX document for XXX 0.1.0",
    "dataLicense": "CC0-1.0",
    "documentDescribes": [
        "SPDXRef-XXX"
    ],
    "documentNamespace": "XXX-0.1.0",
    "packages": [
        {
          "SPDXID": "SPDXRef-gdal",
          "name": "GDAL",
          "versionInfo": "3.4.0",
          "downloadLocation": "https://github.com/OSGeo/gdal/releases/download/v3.4.0/gdal-3.4.0.tar.gz",
          "licenseConcluded": "MIT",
          "licenseDeclared": "MIT",
          "filesAnalyzed": false,
          "externalRefs": [
            {
              "referenceCategory": "SECURITY",
              "referenceType": "cpe23Type",
              "referenceLocator": "cpe:2.3:*:osgeo:gdal:3.4.0:*:*:*:*:*:*:*"
            },
            {
                "referenceCategory": "PACKAGE_MANAGER",
                "referenceType": "purl",
                "referenceLocator": "pkg:bitnami/[email protected]"
            }
          ],
          "copyrightText": "NOASSERTION"
        }
    ],
    "files": [],
    "relationships": []
}

2. $ trivy -q sbom gdal.spdx shows no vulnerabilities.
3. Now, apply the change below on SPDX file

34c34
<                 "referenceLocator": "pkg:bitnami/[email protected]"
---
>                 "referenceLocator": "pkg:bitnami/[email protected]"

4. Run $ trivy -q sbom gdal.spdx again:

$ trivy -q sbom gdal.spdx

 (bitnami)

Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 0)

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version │                            Title                             │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ gdal    │ CVE-2021-45943 │ MEDIUM   │ fixed  │ 3.4.0-1           │ 3.4.0         │ GDAL 3.3.0 through 3.4.0 has a heap-based buffer overflow in │
│         │                │          │        │                   │               │ PCIDSK::C ......                                             │
│         │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2021-45943                   │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴──────────────────────────────────────────────────────────────┘

Target

Container Image or SBOM

Scanner

Vulnerability

Version

$ trivy --version
Version: 0.47.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-11-21 06:12:44.049179772 +0000 UTC
  NextUpdate: 2023-11-21 12:12:44.049179481 +0000 UTC
  DownloadedAt: 2023-11-21 09:25:40.550015 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-11-06 00:56:11.785628882 +0000 UTC
  NextUpdate: 2023-11-09 00:56:11.785628382 +0000 UTC
  DownloadedAt: 2023-11-06 12:09:20.615331 +0000 UTC

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[juan131]

In the branch below on my fork, I implemented a possible solution for this based on a new "comparer" for Bitnami packages:

• https://github.com/juan131/trivy/tree/feat/bitnami-version-comparer

This is based on some changes I introduced at a go-version module fork, see:

• https://github.com/juan131/go-version

[knqyf263]

From the Trivy perspective, it's not false detection as Trivy just follows the semantic versioning. If Bitnami wants to use revisions, you should define another versioning or pick up the existing versioning compatible with Bitnami's versioning.

For example, RPM has revisions (called release).
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/

DEB also has debian-revision.
https://manpages.debian.org/wheezy/dpkg-dev/deb-version.5.en.html

If Bitnami versioning is different from any existing versioning, then it should clearly define the versioning specifications (e.g. PEP440. The versioning is crucial for vulnerability scanning.

IMHO, I hope no more new versioning will appear 😄 Many vendors and languages adopt different versioning, and I implemented a bunch of libraries.
https://github.com/knqyf263/go-deb-version
https://github.com/knqyf263/go-rpm-version
https://github.com/knqyf263/go-apk-version
https://github.com/aquasecurity/go-version
https://github.com/aquasecurity/go-pep440-version
https://github.com/aquasecurity/go-gem-version
https://github.com/aquasecurity/go-npm-version

[juan131]

Thanks @knqyf263 ! I think we can use debian versioning.
Please check the draft PR I created based on the go-deb-version library: #5633

[knqyf263]

Looks good!

[juan131]

I can confirm this issue is solved on 0.48.1 that includes the fix below:

• abf227e fix(bitnami): use a different comparer for detecting vulnerabilities (#5633)