Heya! You have reached the author of the blog. Thanks for the feedback first and foremost, you are bringing up some very insightful questions that I wasn’t able to address at the time. The TLDR of below is agreed, we’ll aim to add product specific help in future incident blogs to make thing easier
The main goal of the blog, much like during the ones we published with log4shell and spring4shell, was to create public clarity around very many conflicting messages in the industry around a vulnerability that had potentially a wide impact, but was yet unreleased. It was written as a point in time and intended at a wider audience, and we followed it up later with another post that talks about the vulnerabilities in depth.
I looked at some of these java librairies you quoted, and most of them seems to link openssl dynamically, it means that scanning these java librairies will not help us to detect openssl vulnerabilities, and even knowning that we use these java librairies in our organization seems useless.
In the cases of larger security vulnerabilities, we try and find ways of sharing information that is publicly useful, such as the impact assessment. In this case, the only affected packages really are the openssl 3.x versions, but historically a silent killer in many vulnerabilities is the potential inclusion of the package transitively. e.g. the JndiManager.class causing log4shell is also present in 19562 other packages. Having awareness of not just direct references can help assess true impact. 98% of all vulnerabilities downloaded have fixes, but for whatever reason are not chosen by the consumers. In the heat of the moment wanted to make sure there was a reference in there to stir up awareness that it might also come in via these inclusions.
Even if we suppose that a vulnerable openssl version is statically linked into a component xyz, then the maintainer of xyz should recompile it with openssl version 3.0.7 in order to publish a fixed version of xyz, and in this case it’s likely another CVE, different from the openssl one, that will be used to track vulnerable versions of xyz.
Although you can’t necessarily fix it yourself, awareness of these issues is key in an incident management response. Knowing something might be pulling in a vulnerability is important for containment and being open source our advice is to advocate for projects to issue fixes. We for example see a ton of transitive inclusions of vulnerable classes in static linking cases, not just in the above l4shell example, but also with things like jquery.js being bundled in dozens of times resulting in all sort of shenanigans.
In most cases with static linking like this, there wont be a separate CVE that the project opens, and instead the info is lost in bug trackers and issues in github. This is why the Data service exists in IQ and why we do secondary expansion to identify hidden issues like this.
- Nexus supports apk, apt, yum formats.
APK is a community format, Debian and RPM registries are supported in nexus: Formats
You can use NXRMs api to search for impacted packages. APIDOCS located in NEXUSBASEURL/#admin/system/api or Admin view - system - API - search
- I am not sure, but it also means that Nexus firewall is available for apk, apt, yum repos?
Nexus firewall supports the languages IQ server supports - yum is the only format IQ supports today.
can be achievable by doing a scan in Nexus IQ or through the continuous monitoring feature?
Yes, the recommendation is to be alerted by this via continuous monitoring. There is a great best practices guide on how to deal with 0-days hidden in the Lifecycle / Firewall documentation I recommend reading. 0-Day Vulnerability Best Practices
You can also run a specific scan as per the yum scanning docs in IQ help.
I hope this helps - I’ll try to make sure to include some readymade gists in future blogs - thanks for your message!