Add openvex format for our VEX statements.#204
Conversation
…orks with lower bounded statements.
dsmiley
left a comment
dsmiley
left a comment
There was a problem hiding this comment.
thanks for working on this
| # Maven groupIds for the artifacts our VEX entries reference, so a JAR name can | ||
| # be emitted as a proper purl subcomponent. Artifacts not listed here (or JARs | ||
| # whose version can't be parsed, e.g. "guava-*.jar") fall back to a bare @id. | ||
| JAR_GROUPS = { |
There was a problem hiding this comment.
Why hard-code this when we can extract it from the JAR metadata in META-INF ?
The approach you are taking assumes each JAR origins/identify is unambiguously identified by the file name.
There was a problem hiding this comment.
Totally! I'm currently looking for better ways then this hard coded stuff, which obviously is totally brittle. One thing I am struggling with is that this "runtime" file generates the vex stuff, and isn't part of the main solr site's gradle build etc. I've never really look into the META-INF stuff... I will.
| # Scanners (e.g. Docker Scout) match VEX statements on the product purl, | ||
| # so the vulnerable JAR(s) are the products. For an entry with no JAR | ||
| # (e.g. a Solr-native CVE), the product is Solr itself: a versioned purl | ||
| # per affected release when the range is closed, else version-less. The | ||
| # human-readable Solr version range is carried in status_notes below. | ||
| if v['jars']: |
There was a problem hiding this comment.
bigger question here: Hopefully we can associate CVEs to individual JARs? For example some vulnerabilities might be in SolrJ, which is used outside Solr. Some vulnerabilities are in a specific module, which means a JAR. Overall point I'm making is that "Solr" as a product is really a set of products that are divisible / composable.
There was a problem hiding this comment.
fair point. That we don't have one "solr", we have multiple.
There was a problem hiding this comment.
okay, I just pushed up adding modules:[] to the front matter. if it's empty then it's solr-core, thogh maybe I want to make it explicit and just update existing vex files...
|
@dsmiley I've dug into the |
| "l:live:Live build and reload source changes on localhost:8000" | ||
| "b:build:Force rebuild of the local Docker image" | ||
| ":lock:Regenerate requirements.txt from requirements.in (use with -b to also rebuild image)" | ||
| ":update-deps:Regenerate solr-dependency-versions.json (needs python3; pass versions after --, default is all)" |
There was a problem hiding this comment.
don't love the command name at all...
|
Using OpenVex statements with Solr 9.9.0 means that of 240 CVE's, 14 are suppressed as not actually needed using Even better, with Solr 10, the CVEs are |
2 participants
OpenVex is another standard for communicating VEX statements. The big difference between it and CycloneDX format is that OpenVEX requires a purl identifier for each version of Solr. You can't just do a range.
For example, CVE-2012-0881 impacts from after 2.9 up to 9.10. We document it as
versions: "2.9-9.10".This expands that range to list each one out in the actual openvex file that you download:
This lets us keep our concise version information, but meet the OpenVEX standard. Since some of our vex files don't have a lower bound of Solr, only an upper, then they get skipped so we don't list all the way back to 1.0! I will in a separate PR investigate existing vex statements to idenfity when the vulnerablity was introduced into solr.
Hopefully this also lets us control better the narrative of what vulnerablities are out there that impact Solr by making these statements machine readable. This way, as we make fixes etc, we can update our VEX statements and direct people to them.