Since releasing Grype 3 years ago (in September 2020), one of the most frequent questions we’ve gotten is, “why is image X vulnerable to vulnerability Y?” Today, we’re introducing a new sub-command to help users answer this question: Grype Explain.
Now, when users are surprised to see some CVE they’ve never heard of in their Grype output, they can ask Grype to explain itself: grype -o json alpine:3.7 | grype explain --id CVE-2021-42374
. We're asking the community to please give it a try, and if you have feedback or questions, let us know.
The goal of Grype Explain is to help operators evaluate a reported vulnerability so that they can decide what, if any, action to take. To demonstrate, let’s look at a simple scenario.
First, an operator who deploys a file called fireline.hpi into production sees some vulnerabilities:
❯ grype fireline.hpi| grep Critical
✔ Vulnerability DB [no update available]
✔ Indexed file system
✔ Cataloged packages [35 packages]
✔ Scanned for vulnerabilities [36 vulnerabilities]
├── 10 critical, 14 high, 9 medium, 3 low, 0 negligible
└── 14 fixed
bcel 6.0-SNAPSHOT 6.6.0 java-archive GHSA-97xg-phpr-rg8q Critical
commons-collections 3.1 3.2.2 java-archive GHSA-fjq5-5j5f-mvxh Critical
dom4j 1.6.1 2.0.3 java-archive GHSA-hwj3-m3p6-hj38 Critical
fastjson 1.2.9 1.2.31 java-archive GHSA-xjrr-xv9m-4pw5 Critical
fastjson 1.2.9 java-archive CVE-2022-25845 Critical
fastjson 1.2.9 java-archive CVE-2017-18349 Critical
log4j-core 2.11.1 2.12.2 java-archive GHSA-jfh8-c2jp-5v3q Critical
log4j-core 2.11.1 2.12.2 java-archive GHSA-7rjr-3q55-vv33 Critical
log4j-core 2.11.1 java-archive CVE-2021-45046 Critical
log4j-core 2.11.1 java-archive CVE-2021-44228 Critical
Wait, isn’t CVE-2021-44228 log4shell? I thought we patched that! The operator asks for an explanation of the vulnerability:
❯ grype -q -o json fireline.hpi| grype explain --id CVE-2021-44228
[0000] WARN grype explain is a prototype feature and is subject to change
CVE-2021-44228 from nvd:cpe (Critical)
Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1)
JNDI features used in configuration, log messages, and parameters do not protect against attacker
controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log
message parameters can execute arbitrary code loaded from LDAP servers when message lookup
substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From
version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely
removed. Note that this vulnerability is specific to log4j-core and does not affect log4net,
log4cxx, or other Apache Logging Services projects.
Related vulnerabilities:
- github:language:java GHSA-jfh8-c2jp-5v3q (Critical)
Matched packages:
- Package: log4j-core, version: 2.11.1
PURL: pkg:maven/org.apache.logging.log4j/[email protected]
Match explanation(s):
- github:language:java:GHSA-jfh8-c2jp-5v3q Direct match (package name, version, and
ecosystem) against log4j-core (version 2.11.1).
- nvd:cpe:CVE-2021-44228 CPE match on `cpe:2.3:a:apache:log4j:2.11.1:*:*:*:*:*:*:*`.
Locations:
- /fireline.hpi:WEB-INF/lib/fireline.jar:lib/firelineJar.jar:log4j-core-2.11.1.jar
URLs:
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
Right away this gives us some information an operator might need:
- Where’s the vulnerable file?
- /fireline.hpi:WEB-INF/lib/fireline.jar:lib/firelineJar.jar:log4j-core-2.11.1.jar
- Seeing the location inside a jar inside the .hpi file tells the operator that a jar inside a jar inside the .hpi file is responsible for the vulnerability.
- How was it matched?
- Seeing both a CPE match on cpe:2.3:a:apache:log4j:2.11.1:*:*:*:*:*:*:* and a GHSA match on pkg:maven/org.apache.logging.log4j/[email protected] gives the operator confidence that this is a real match.
- What’s the URL where I can read more about it?
- Links to the NVD and GHSA sites for the vulnerability are printed out so the operator can easily learn more.
Based on this information, the operator can assess the severity of the issue, and know what to patch.
We hope that Grype Explain will help users better understand and respond faster to vulnerabilities in their applications. Do you have feedback on how Grype Explain could be improved? Please let us know!