Hi Gary,

On 23.07.2025 13:18, Gary Gregory wrote:
> So, for Commons Compress for example, like this:
> 
> {
>   "@context": "https://openvex.dev/ns/v0.2.0";,
>   "id": "https://apache.org/vex/statement-commons-compress-001";,
>   "author": "apache.org",
>   "role": "Document Creator",
>   "timestamp": "2025-07-23T11:11:00Z",
>   "version": 1,
>   "statements": [
>     {
>       "vulnerability": {
>         "name": "CVE-2025-48924"
>       },
>       "products": [
>         "pkg:maven/org.apache.commons/commons-compress@1.28.0"
>       ],
>       "status": "not_affected",
>       "justification": "vulnerable_code_not_in_execute_path",
>       "timestamp": "2025-07-23T11:11:00Z"
>     }
>   ]
> }

Hi Gary,

Yes, exactly, that's the idea. However, I'd prefer *not* to use OpenVEX
or CycloneDX as the input format. Instead, my goal is to define a
simpler, more human-friendly input that we can use to generate both:

- A human-readable security description on the website, listing:
  - The Commons Compress versions depending on the vulnerable Commons
Lang, and
  - The vulnerable dependency versions (e.g., Commons Lang),
  similar to what Apache Solr does here:


https://solr.apache.org/security.html#cve-reports-for-apache-solr-dependencies

- A machine-readable OpenVEX or CycloneDX VEX document, like this one:

  https://solr.apache.org/solr.vex.json

For the input format, I’d like to follow the same approach I proposed
for Apache Solr [1]:

- One file per CVE of the project itself or its dependencies.
- Written in Markdown with a YAML preamble to capture the structured
metadata, similar to how Pelican works [2].

Here’s an example:

```
---
cve: CVE-2025-48924
dependency:
  group: org.apache.commons
  name: commons-lang3
  versions:
    - introduced: 3.0
      fixed: 3.18.0
group: org.apache.commons
name: commons-compress
versions:
  - introduced: 1.26.0
    last_affected: 1.27.1
    status: not_affected
    justification: vulnerable_code_not_in_execute_path
summary: Vulnerable `ClassUtils` class is not used
---

CVE-2025-48924 is **not** exploitable in Commons Compress versions
1.26.0 through 1.27.1, because the vulnerable `ClassUtils` class from
the `commons-lang3` dependency is not used in these versions.
```

I haven't thought about the details yet, but I believe we can use a
Python script to convert this format into a single `security.md` page or
generate a file suitable to be used with a Velocity template.

Best,
Piotr

[1] https://lists.apache.org/thread/o6bgxv996kfrmmy7odf226twsg9bnwbj
[2]
https://github.com/apache/solr-site/blob/main/content/solr/security/2021-12-10-cve-2021-44228.md?plain=1


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to