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"
}
]
}
?
Gary
On Sun, Jul 20, 2025 at 5:23 PM Piotr P. Karwasz <pi...@mailing.copernik.eu>
wrote:
> Hi all,
>
> As you know, we released CVE-2025-48924 for Commons Lang a few days ago.
> Due to the widespread use of the library, the CVE has already triggered
> some user responses: for example, in [1], users reported being forced to
> upgrade Commons Lang and remove deprecated method usage due to internal
> policy.
>
> I'd like to propose publishing an **experimental** Vulnerability
> Exploitability eXchange (VEX) file for the Apache Commons components. A
> VEX file is a machine-readable document that assesses the
> **exploitability** of a known vulnerability in the context of a specific
> product or environment.
>
> While VEX was originally designed for complete applications, I believe
> we can use it in an experimental capacity for libraries to clarify the
> impact of vulnerabilities such as this one. For instance:
>
> * Although Commons Compress depends on Commons Lang [2], the affected
> `ClassUtils` class is **not** reachable through Commons Compress.
> * Conversely, other Commons components might expose or transitively
> allow exploitation of the vulnerability.
>
> I'm currently involved in maintaining Apache Solr's VEX file [3], and
> would be happy to take the lead on maintaining one for Commons as well.
>
> ### VEX Files for Libraries: Why "Experimental"?
>
> I've used the term “experimental” deliberately. VEX files are typically
> phrased like this:
>
> "This component contains CVE-XXXX-YYYY but is not **exploitable**
> in this product."
>
> But in our case, what we'd want to express is closer to:
>
> "Even if an application includes both Commons Foo and a vulnerable
> Commons Lang, the vulnerability *may* or *may not* be exploitable
> *through* Commons Foo."
>
> That distinction makes VEX for libraries a bit of a stretch, but
> potentially still valuable for downstream users and security tooling.
>
> Thoughts?
>
> Best,
> Piotr
>
> References:
> [1] https://lists.apache.org/thread/15trh8n443s4rnmtj95oh0vlbb8dr2h1
> [2] https://lists.apache.org/thread/qrdg69njp87fgwf09qfdbm94hytm7mh7
> [3] https://lists.apache.org/thread/8yzoyn4xxy25x9thd7bcq1cz5soj619q
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
