Detect Zulu CVEs: Should I add a custom database or rules for containers vulnerability scanning?

[brendalf]

Question

Hello folks.

trivy don't detect known vulnerabilities on Azul/Zulu packages (Zulu CVEs).
I need to detect them, but I'm not sure how is the best way to do so.

This is related to #4238 and the comment made by @breun #4238 (reply in thread).

Trivy detects that zulu packages are installed, but don't recognizes the vulnerabilities.

$ trivy image --list-all-pkgs --format json azul/zulu-openjdk:11.0.17   | jq '.Results[].Packages[]'

So my hypothesis is the following:

Trivy detects the packages, but there is no information about Zulu on trivy default vulnerabilities database.

If that's true, then the following questions comes to mind:

1. Does Azul have a custom database that I can pass to trivy image scan command? I did a quick search on it, but I couldn't find it.
2. Should I create and maintain my own custom rules or database? If so, do you have any tips on how to do that?
3. Could we add the Zulu CVEs into trivy database?

ps: I knew into security related topics, so forgive me if I'm asking something silly or if my premises are wrong.

Target

Container Image

Scanner

Vulnerability

Output Format

JSON

Mode

Standalone

Operating System

No response

Version

Version: 0.44.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-09-13 12:16:15.667000619 +0000 UTC
  NextUpdate: 2023-09-13 18:16:15.667000119 +0000 UTC
  DownloadedAt: 2023-09-13 12:40:07.842065 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-09-13 01:08:37.307740232 +0000 UTC
  NextUpdate: 2023-09-16 01:08:37.307739532 +0000 UTC
  DownloadedAt: 2023-09-13 11:43:11.067416 +0000 UTC

[knqyf263]

Custom vulnerabilities are not yet supported in Trivy. The vulnerability is in public. I think it would be helpful for Trivy users if you contribute to public databases like GHSA.

[breun]

Yes, Azul Zulu builds are distributed as both APT and RPM packages via Azul’s APT and Yum repositories. Azul Zulu is also distributed as plain .tar.gz archives, but we use the APT repository to install on Debian.

[knqyf263]

Hmm. You're right, then. GitHub and GitLab databases accept only ecosystem-specific packages.

[knqyf263]

Should I create and maintain my own custom rules or database? If so, do you have any tips on how to do that?

There is no easy way, but you can insert custom data by using the bbolt library as Trivy DB is BoltDB.

[breun]

It looks like NVD is open for suggestions for adding extra CPEs to vulnerabilities, so maybe that is a way to get OpenJDK vulnerabilities detected in Azul Zulu packages. I don’t know yet if these packages can be identified using a CPE, but if so, I think this should be at least technically possible.

[breun]

I've contacted NVD to ask what's possible here.

[MprBol]

@knqyf263

I think it would be helpful for Trivy users if you contribute to public databases like GHSA.

The company I work for build a lot of in-house software. If a vulnerability is found it would be useful to use Trivy to detect any running vulnerable versions in our landscape. As the software is private, there would be no benefit to expose that information in a public advisory.

[brendalf]

Hello there!
I managed to append our company custom CVEs (including Zulu) to trivy bbolt database and now everything works.
I'm planning to write a small article on how to do it, but I can also share the code here if anyone wants.

I also tried creating a VEX file with the affected status, but looking at the source code it seems that trivy only uses VEX to filter vulnerabilities with not_affected. Would it will be possible to create a vulnerability when the VEX status is affected and the PURL matches to a package running in the image?

For example:

1. Running packages:

$ trivy image --list-all-pkgs --format json azul/zulu-openjdk:11.0.17   | jq '.Results[].Packages[].Identifier.PURL'

"pkg:deb/ubuntu/[email protected]?arch=all&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"
"pkg:deb/ubuntu/[email protected]?arch=amd64&distro=ubuntu-20.04"

VEX file:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://openvex.dev/docs/public/vex-2e67563e128250cbcb3e98930df948dd053e43271d70dc50cfa22d57e03fe96f",
  "author": "Test",
  "timestamp": "2023-08-29T19:07:16.853479631-06:00",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2020-14583" },
      "products": [{ "@id": "pkg:deb/ubuntu/[email protected]" }],
      "status": "affected"
    }
  ]
}

BTW, this discussion is a duplicated of #4238.

[knqyf263]

Would it will be possible to create a vulnerability when the VEX status is affected and the PURL matches to a package running in the image?

Trivy uses VEX for filtering for now.
It's possible, but we need to carefully consider the implementation. Since VEX is currently used in filtering section, we need to consider how to use VEX in detection section.

[brendalf]

Is it ok if I create a proposal and a MR for that or is it something that needs to be discussed internally first?

[knqyf263]

If you have a good idea, we welcome it.