ppkarwasz opened a new issue, #27: URL: https://github.com/apache/logging-site/issues/27
## Background A year ago I [wrote about VEX](https://logging.apache.org/blog/20250728-introduction-to-vex-files.html) and why it's a more useful artifact than our current VDR. This issue tracks actually shipping it. Briefly, to motivate the work: - **Our VDR duplicates public data.** Everything in it is already in the public CVE feeds; downstream consumers gain nothing from reading ours. - **VEX statements add real signal.** They let us tell downstream projects whether a CVE in one of our *dependencies* actually affects users of our components — which is the question downstream maintainers are actually trying to answer. - **Production can be largely automated.** The [VEX Generation Toolset](https://github.com/vex-generation-toolset) generates candidate statements from SBOMs + callgraph analysis, and gives useful feedback on the quality of our SBOM data as a side effect. - **The volume is low.** Vulnerabilities in our upstream dependencies typically surface as a Dependabot security PR (recognizable by the "You can disable automated security fix PRs…" footer even without Security Alerts access). One CVE corresponds to one VEX statement. This is not a large ongoing burden. ## Roadmap - [ ] **Publish SBOMs to `callgraph-metadata` post-release.** Add a workflow step that uploads the release SBOMs to the [`vex-generation-toolset/callgraph-metadata`](https://github.com/vex-generation-toolset/callgraph-metadata) repo, so callgraphs are extracted from our JARs and dependencies are monitored for CVEs upstream. - [x] **Store each VEX statement in its own file.** Enables clean separation between CVEs in our own components (`metadata.component == vulnerability.affects`) and CVEs in third-party components. Done for existing VDR entries in #26. - [ ] **Add vulnerability-monitoring + VEX-generation workflow.** A scheduled workflow that monitors our published SBOMs for new CVEs and opens a PR with a draft VEX statement for each one, ready for a maintainer to review and complete the `justification` / `response` fields. - [ ] **Document the VEX authoring process** in the contributor guide. - [ ] **Publish VEX statements alongside releases**: the path / URL scheme for downstream consumers to fetch them should be decided and documented. -- 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]
