Copilot commented on code in PR #211:
URL: https://github.com/apache/solr-site/pull/211#discussion_r3758356753


##########
content/solr/vex/2026-07-31-cve-2026-8384.md:
##########
@@ -0,0 +1,34 @@
+---
+cve: CVE-2026-8384
+category:
+  - solr/vex
+versions: "7.3.0-10.0.0"

Review Comment:
   The PR title/description references coverage for 9.11-SNAPSHOT and 
10.1-SNAPSHOT, but the new VEX statements cap `versions` at `10.0.0`. If the 
VEX tooling uses this range to match findings, these statements likely won’t 
apply to 10.1-SNAPSHOT images. Consider switching to a range that includes 10.1 
(or an open-ended upper bound, if supported by your VEX pipeline) so snapshot 
scans can actually be suppressed.



##########
content/solr/vex/2026-07-31-cve-2026-54512.md:
##########
@@ -0,0 +1,26 @@
+---
+cve:
+  - CVE-2026-54512
+  - CVE-2026-54513
+category:
+  - solr/vex
+versions: "4.7.0-10.0.0"
+jars:
+  - jackson-databind-2.12.7.1.jar

Review Comment:
   The body text indicates the scanner finding is for a Hadoop-shaded 
jackson-databind, but the `jars` list names a standalone 
`jackson-databind-2.12.7.1.jar`. If the runtime image doesn’t actually contain 
this jar as a discrete artifact (because it’s shaded into a Hadoop jar), 
suppression based on this `jars` entry may not match. Consider aligning the 
identifier in `jars` (or whatever key your pipeline matches on) to the actual 
packaged artifact present in the image/SBOM that raised the CVE.



##########
content/solr/vex/2026-07-31-cve-2026-56740.md:
##########
@@ -0,0 +1,26 @@
+---
+cve:
+  - CVE-2026-56740
+  - CVE-2026-56741
+category:
+  - solr/vex
+versions: "9.0.0-10.0.0"
+jars:
+  - jline-remote-telnet-3.9.0.jar
+analysis:
+  state: not_affected
+  justification: code_not_present

Review Comment:
   This front matter is internally inconsistent: it lists 
`jline-remote-telnet-3.9.0.jar` under `jars`, but the justification is 
`code_not_present` and the body says Solr ships no such jar (it’s only 
mentioned in ZK metadata). If `jars` is used for matching/suppression, this may 
fail or be misleading. Consider either (a) removing the jar entry if the 
artifact is not actually shipped, or (b) changing `jars` to the real shipped 
artifact that triggers the finding (e.g., the ZooKeeper jar) and adjusting the 
justification accordingly.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to