Anchore grype EPSS fix

[valentijnscholten]

Fixes #12819

When the original vulnerability id is not a CVE, the parser must look harder in the related vulnerability data to find the EPSS data.
This might not be a 100% complete fix as for that the parser needs to be changed to parse all related vulnerabilities instead of just the first one. Anyone with Grype knowledge please advise :-) For now this at least fixes the one known problem case.

[dryrunsecurity]

This pull request contains a potential information disclosure vulnerability in the Anchore Grype parser, where debug logging may expose sensitive system details such as file paths, software component information, and vulnerability specifics, which could be exploited by an attacker if debug logs are enabled in non-development environments.

Information Disclosure via Debug Logging in dojo/tools/anchore_grype/parser.py

Vulnerability

Information Disclosure via Debug Logging

Description

The line logger.debug(f"data: {data}") logs the entire content of the parsed JSON file from the Anchore Grype scan. This data includes sensitive information such as internal file paths (artifact.locations.path), precise software component names and versions (artifact.name, artifact.version), and detailed vulnerability information (IDs, descriptions, CVSS/EPSS scores). Logging this comprehensive data, even at a debug level, poses a significant information disclosure risk if debug logs are enabled or accessible in a non-development environment. An attacker could use this information to map the system's attack surface and identify specific vulnerabilities to exploit.

django-DefectDojo/dojo/tools/anchore_grype/parser.py

Lines 30 to 38 in 42f319f

	)
	def get_findings(self, file, test):
	logger.debug(f"file: {file}")
	data = json.load(file)
	logger.debug(f"data: {data}")
	dupes = {}
	for item in data.get("matches", []):
	vulnerability = item["vulnerability"]

---

All finding details can be found in the DryRun Security Dashboard.

[mtesauro]

Approved

[spiffcs]

👋 Hey all! A team member at Anchore mentioned this PR to us over in our tools discussion and I thought I would chime in here to maybe give some Grype knowledge on the thread. I saw this was approved already, but hopefully this comment clarifies the orientation of results and how we do the EPSS data.

Let's start with an example we can all follow along that gives examples of the data shape we want to inspect:

git clone https://github.com/anchore/grype.git
cd grype
grype -o json dir:. > grype-dir-scan.json

This isn't the best scan target for a "real" vulnerability scan, but because grype has lots of test cases locally that will display a good number of findings it is a good way to look at some example data.

So the first thing we can look at this result is by default how many GHSA results did we get here?

[I] ~/d/grype (main)> jq '[.matches[] | select(.vulnerability.id | startswith("GHSA"))] | length' grype-dir-scan.json
83

This PR correctly identifies that you can find the related cve(s) if they exist under the related vulnerabilities field for the given GHSA result:

  {
    "vulnerability": {
      "id": "GHSA-qxp5-gwg8-xv66",
      "dataSource": "https://github.com/advisories/GHSA-qxp5-gwg8-xv66",
      "namespace": "github:language:go",
      "severity": "Medium",
      "urls": [],
      "description": "HTTP Proxy bypass using IPv6 Zone IDs in golang.org/x/net",
      "cvss": [
        {
          "type": "Secondary",
          "version": "3.1",
          "vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
          "metrics": {
            "baseScore": 4.4,
            "exploitabilityScore": 1.9,
            "impactScore": 2.6
          },
          "vendorMetadata": {}
        }
      ],
      "epss": [
        {
          "cve": "CVE-2025-22870",
          "epss": 0.00014,
          "percentile": 0.01482,
          "date": "2025-07-20"
        }
      ],
      "fix": {
        "versions": [
          "0.36.0"
        ],
        "state": "fixed"
      },
      "advisories": [],
      "risk": 0.00658
    },
    "relatedVulnerabilities": [
      {
        "id": "CVE-2025-22870",
        "dataSource": "https://nvd.nist.gov/vuln/detail/CVE-2025-22870",
        "namespace": "nvd:cpe",
        "severity": "Medium",
        "urls": [
          "https://go.dev/cl/654697",
          "https://go.dev/issue/71984",
          "https://pkg.go.dev/vuln/GO-2025-3503",
          "http://www.openwall.com/lists/oss-security/2025/03/07/2",
          "https://security.netapp.com/advisory/ntap-20250509-0007/"
        ],

Grype has another option though where you can orient --by-cve

Let's run our example scan again to see how many GHSA we get when we include this option.

grype -o json --by-cve dir:. > grype-dir-scan.json
jq '[.matches[] | select(.vulnerability.id | startswith("GHSA"))] | length' grype-dir-scan.json
13

Note here that we didn't totally eliminate GHSA from the list since there will be some entries from the GHSA DB that don't have a related CVE.

Your milage may also vary based on scan targets as far as absolute number of results when enabling this option. The links between NVD --> GHSA and vise versa are not always 1:1.

A GHSA might have multiple CVE linked. This would mean that a scan result where we orient around CVE could expand the absolute number of vulnerability results when a single GHSA that covers multiple related CVE was presented as the top level result.

I haven't had time to look at the full PR chain here regarding how defect dojo is integrating grype, but my guess is that if you're looking for CVE --> EPSS/KEV data in the most streamlined JSON result then --by-cve is your best bet here 😄

Happy to answer other questions or take a look at specific examples where we might have to make changes or update grype!

[bwt-sloanj]

Thanks for the fix @valentijnscholten - apologies for the oversight in my original PR!

And thanks for the insight @spiffcs - I'll soon be relying on DD + Grype with EPSS data going forward so I'll report cases when they arise. --by-cve sounds like the best bet for reliably getting the right EPSS data.

Maybe we'll see it in action at the "Using Anchore & DefectDojo to Stand Up Your DevSecOps Function" webinar...

[valentijnscholten]

Thank you @spiffcs for jumping in. Should we add some notes to our anchore grype docs to advise users to use the --by-cve option? I noticed anchore/grype#1454 which seems to imply it's not yet always up-to-par with the default output setting.

[spiffcs]

👋 @valentijnscholten - I'd say you can update the docs to show that --by-cve is an alternative view users can look at to give the CVE oriented results.

The first point of that issue should be fixed soon when we get some of our fixed in dates updated.

I would highlight these points from the issue as potential side affects to orienting by this view:

--by-cve reorients everything (severity, cvss, etc) around the NVD score, which is not always clear
--by-cve can cause a significant increase in the number of reported vulns for Amazon and Oracle since a single ELSA or ALSA identifier may fix a huge number of CVE’s

[valentijnscholten]

I think with the fix for the EPSS in place there's no real reason to instruct users to use the --by-cve option.

[valentijnscholten]

@spiffcs wdyt about #12874

[spiffcs]

LGTM

@spiffcs wdyt about #12874