It let log4j pass for as long as it was known to be good. Within hours of the CVE opening the tool was blocking it. The purpose of dependency firewalls is to avoid two things: known badly vulnerable packages AND known malicious packages that serve no other purpose than to steal data or drop a trojan. No security is 100% bulletproof, but it's really surprising how much of the damage is done by 7 year old CVEs. Firewalls can be useful in exactly that.
This exact same sentiment came through in the National Cyber Security Strategy the US released. It describes a minimum acceptable level of software development, called safe harbours, based on e.g. the NIST Secure Development Standards.
Whether we like it or not, it seems legislation is forming on how to code and ship software.
Nexus Lifecycle / Nexus Auditor tends to be useful for this - in absence of a package.json it crawls the raw js files and finds their source. It can help figure out things like embedded jqueries etc. That being said, it has the same limitation as other tools - minification and bundling obfuscates origins and makes it harder to assign identity to the source package.
The only way that I can think of getting around this is to have a hard requirement for a source registry - or asking the premium plugin producers to produce a SBOM like cyclonedx or spdx and evaluate that in lieu.
Yeah oddly the outcome of MTTU is a maintained transitive tree seems to be a better indicator of security status than any other more complex framework. How to do it effectively is a matter on to itself