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.
If I remember correctly, it says that memory unsafety is not tolerated anymore, which is far the most important issue we have.
The ,,rewrite in Rust'' crowd was mocked here, but there are just too many cyber attacks with growing damage and targeting politicians in power that memory unsafe code shouldn't be accepted anymore.
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
This is exactly right. Low MTTU and keeping up-to-date across the transitive dependency tree makes it less likely that vulnerabilities creep in due to those transitive dependencies. I think there's also a certain aspect of "faster is better" akin to what we see in Forsgren et al's Accelerate / State of DevOps research. If you have the team structure, development discipline, and release infrastructure required to update dependencies frequently then that probably benefits other aspects of project quality as well.
I think that works provided the cadence isn't too slow. We see an average of 8 to 12 project versions per year being published depending on ecosystem. That matches nicely with the 28 day average MTTU for 2021 in the Maven ecosystem. I wouldn't want to see projects releasing less frequently than that. But I think the right answer also depends on where in the dependency chain your project tends to live. Projects near the "leaves" should aim to update faster so that downstream consumers aren't blocked waiting on them to remediate issues. Projects more toward the base of the tree might update every month or so and not worry about releasing a new version every time a transitive dependency changes, as that would be too much version churn.
I would really love to see these stats broken out by the type of update. Non-breaking changes (UI, interface, or otherwise) and transparent updates (filling some security holes, UI tweaks / alignment, performance, etc), though I wouldn't quite know how to mechanically label updates myself.
Basically, I'm advocating for slower user facing releases in general. We're getting overwhelmed on the flip side here.
