Hi Gary, On 26.07.2025 14:35, Gary Gregory wrote: > Inventing a custom schema seems like a bad idea to me when formats like > OpenVEX have a well-defined schema. If we need to use Markdown as an > intermediary step, then maybe. YAML is gross IMO due to its use of > significant whitespace, causing too many problems unless you have X-ray > eyes.
The challenge I’m facing is that current formats, such as CycloneDX and OpenVEX, are primarily designed for applications, container images, and similar artifacts that bundle their dependencies. As a result, they don't easily accommodate some important use cases, such as: * Expressing conditional exploitability: For example, CVE-2025-48924 is only exploitable in `commons-text` version 1.13.1 (or 1.14.0) if `commons-lang3` version 3.17.0 is also on the classpath. * Referencing other VEX files: There’s no straightforward way for one VEX (e.g., for `log4j-core`) to reference another (e.g., `commons-compress`) to support a non-exploitability claim. * Including rich-text vulnerability descriptions: I’d prefer to write these in Markdown for better expressiveness and readability, which isn't well-supported today. * Capturing additional metadata not currently covered by existing schemas. Given these limitations, I’m leaning toward using a slightly extended metadata format that fits our needs more closely, and then generating both CycloneDX and OpenVEX documents from it as needed. Regarding YAML: most modern editors provide good support for it, making it relatively easy to work with. That said, without a suitable editor, even formats like JSON and XML can be difficult to edit effectively. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
