On Sat, Jul 26, 2025, 17:38 Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote:
> 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. > Hi Piotr, Thanks for sharing your experience and experiments. All of this tells me this new VEX/VDR ecosystem is not fully baked yet. Especially around tooling and sharing data across application stack hierarchies. It'll be interesting to see how this plays out with infrastructure like GitHub/GitLab, Maven Central, and the like. Gary > Piotr > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
