And just to add to that: > 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.
This part is very real and I think we are yet to see how it plays out when CRA and others come into force. There is a very high risk of false positives if we just rely on SBOM and CVEs, and IMHO this is a high risk for the Open-Source maintainers, because commercial users will be tempted to get a free-ride and exploit an open source by demanding to open source maintainers to always react and make a release every time a vulnerable dependency - even 10 steps down in the tree will turn to be vulnerable. To some extent VDR/VEX can mitigate it, but IMHO we have to have some ways (we - open source maintainers) to assess if a CVE in a dependency X affects us. This is a lot of work sometimes, that our commercial users will not want to pay us, they will demand IMHO definitive answers. We discussed it recently and while we might attempt to hand-wave it a bit and try to say "we are not vulnerable, but not really sure", and - as discussed in https://issues.apache.org/jira/browse/LEGAL-698, legally we can make similar statement like we do in our software LICENCE ("we are not responsible for anything"), the question is how actual legislation from CRA will define it, and I foresee that this will become also some of a decisive factor by the users of our software if they choose it or not - if they will get more definite statements for CVE, they might rank higher software where the statements are a bit more than "we are probably not affected". I think such tooling is missing and I've been discussing it recently with Michael Winser from Alpha-Omega, they are working on funding an idea which will: a) allow to derive functionality of the software (networking, file access, more fine-grained functionality for some apps) b) allow to attach CVEs to particular functionalities c) automatically derive a graph of not only SBOM dependencies but also overlay the graph of "which functionalities we are using from the library" which in turn will enable to narrow-down the number of potential CVEs that are affecting the software Ideally this should not be "us" to do it, but there should be public tooling available for anyone to check it. And there is some prior art Alpha-Omega is building on top of. But this is a multi-year programme, not a project even, that - if successful - will have to involve a lot of people from a lot of ecosystems, and extensions on CVEs so that's something far in the future. I am going to vulncon in Raleigh in April https://www.first.org/conference/vulncon2025/ - 7-10 April and I am quite sure there will be a lot of discussion about this, I might want to write a report what I will learn there after I am back. J. On Thu, Mar 20, 2025 at 11:16 AM 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 > >
