VEX files are what may be used to report vulnerabilities. It’s somewhat orthogonal to a release’s SBOM,
Piotr, VP, ECMA and Arnout from Security are discussing this topic. ATR will make recommendations as Security policies evolve. Best, Dave > On Mar 19, 2025, at 1:27 PM, Dominik Psenner <dpsen...@gmail.com> wrote: > > Hi Craig > > At dayjob this has been part of a antivirus solution we have in production > use for long. It scans computers, knows software and versions, knows what > is running and aligns that with CVEs. Don't know if that is already > scraping SBOMS to gain a better picture about the software. Since it is a > source of live event data, it is also well suited to feed the SOC and > detect malicious actors in the wild. AFAIC, it would be unfeasible in real > world if a human would have to feed a service with all software items and > their versions manually, and further even keep that aligned with reality. > The only doable solution in every medium sized environment are agents that > continuously scan and inventorize all systems. > > Best regards > Dominik > > On Wed, 19 Mar 2025, 21:12 Craig Russell, <apache....@gmail.com> wrote: > >> I was thinking about why we have SBOMs and took it to the next level. >> >> Users use SBOMs in order to know the entire stack of software they are >> running. This allows them to know whether the products that they use are >> subject to known vulnerabilities. But in order to take advantage of this, >> they need to monitor CVE activity and manually scan their products' SBOMs >> every time a CVE is announced. >> >> Is there any thought given to automate this process? Perhaps users could >> register their list of products on a service such that any time any of >> their products had a CVE they would receive a specific notice of that CVE? >> >> This is out of scope for Tooling. Anyone know if such a service exists out >> in the wild? >> >> Craig >> >> Craig L Russell >> c...@apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org >> For additional commands, e-mail: >> security-discuss-h...@community.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
