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
