I've used the OWASP dependency check Maven plugin: https://owasp.org/www-project-dependency-check/
Is this the kind of checks we're talking about? Gary On Thu, Mar 20, 2025, 06:16 Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > Hi Craig, > > On 19.03.2025 21:11, Craig Russell wrote: > > 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. > > There is software that does that kind of matching. Unless I am mistaken > Arnout have tried Guac and DependencyTrack. I never used Guac, but > DependencyTrack downloads advisories from multiple databases and tries > to match them with the SBOMs. It has a REST API, so in the future it > could be integrated with Tooling infrastructure. > > There are however several challenges to "know whether the products that > they use are subject to known vulnerabilities": > > 1. For a product to be "subject to known vulnerabilities" two conditions > must occur: the vulnerable code must be included and the vulnerability > must be exploitable. > > 2. To find if the vulnerable code is included some identifier in the > SBOM must match an identical identifier in the vulnerability disclosure. > This actually is much harder than it looks: > > * Vulnerability databases used CPEs[1] for a very long time, which > is a very crude identifier that marks hundreds of packages as vulnerable > (e.g. `cpe:2.3:a:apache:camel`). It's hard to match those with package > names. > > * Currently package names can be submitted to the CVE database, but > they are not always correct or complete. For example the recent > CVE-2025-27636[2] points at `org.apache.camel:camel` as the vulnerable > component. This is a POM file, so you won't find it in an SBOM. [Beyond > this small inaccuracy, I was impressed in seeing how Apache Camel > handled the vulnerability, with PRs reviewed and merged within 5 minutes > and a 3 hours release vote]. > > * SBOMs are notably incomplete even for Open Source projects (for > commercial products this is intentional). In the Java world we currently > don't have a way to handle "shaded" dependencies that are embedded in a > library and disappear from a POM file. I believe that Python SBOM > generators are not able to disclose native libraries that are shipped in > some packages. > > A lot of initiatives are currently in place to fix these problems: > > * Package URL will become an ECMA standard at the end of this year and > provides a precise identifier that can be used in vulnerability reports. > > * Some vulnerability databases enrich the information submitted by > reporters with IDs. The NVD[3] used to do it for a long time, but > suddenly stopped for an unknown reason (lack of funding? Not sure if the > current USA administration is willing to address this). GitHub > Advisories[4] seems to be doing a good job, but to use it we don't need > to integrate it into ATR. Submitting SBOMs to GitHub is enough. A lot of > other vulnerability databases exists, but are far from being free from > false positive and false negatives. > > * Personally I think that the solution should come from the community. I > am currently looking for funding to produce some Vulnerability > Disclosure Reports(VDR)[5] for Apache projects, which in my > understanding are the right tool to disclose that a product **contains** > a vulnerable dependency even if that dependency does not appear in an > SBOM or there is no SBOM for that version of the project. > > Summarizing: we could use a solution like DependencyTrack to match SBOMs > with vulnerabilities, but I think it would be too soon for ATR to > propose its own solution. > > > 3. To find if a vulnerability in an application is **exploitable** is an > even harder problem. IMHO, the appropriate tool for that is a > Vulnerability Exploitability eXchange(VEX)[6] and it should also be > handled by the community. I wrote a small example[7] on how this kind of > document could help downstream consumers to evaluate the exploitability > of a CVE in their own applications. > > > Whenever some progress occurs in these areas, I will be certainly ping > Dave to see if some of those advances can be integrated into ATR. > However, without additional funding, I am not sure if there is enough > work power to pursue these goals now. At the end of the year, 3 ECMA > standards are expected (Transparency Exchange API, Common Lifecycle > Enumeration and Package URL). These standards should help with > vulnerability handling, so whenever some final drafts are available, I > will try to use my Puss in Boots Eyes with Apache Tooling. > > > Piotr > > [1] https://nvd.nist.gov/products/cpe > > [2] https://www.cve.org/CVERecord?id=CVE-2025-27636 > > [3] https://nvd.nist.gov/ > > [4] https://github.com/advisories > > [5] https://cyclonedx.org/capabilities/vdr/ > > [6] https://cyclonedx.org/capabilities/vex/ > > [7] https://github.com/copernik-eu/vexation/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: > security-discuss-h...@community.apache.org > >
