5 ms·
Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tre
by spockz 5y ago
Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tree from there. Problem solved. (Except for shaded dependencies…, but scanning for that should happen at build time anyway.)
- lazide 5y agoGood luck doing that on the custom software some vendor provided you 5 years ago and since has gone out of business.. and that’s a GOOD scenario for a lot of enterprise software. Sometimes it’s 20 years.
- Too 5y agoLesson learned. Never buy closed source. Imagine the vulnerability would have been in the vendor code instead of in the log4j jar. You’d. still need a way to fix and rebuild it. Note that this doesn’t have to mean a public MIT repo on GitHub. You can have more restrictive gray box licenses between your b2b partners only.
- tormeh 5y agoIf it's a 20 year old closed source application, there probably aren't any exploits in the wild. You can bet there are exploits for log4j.
- hamilyon2 5y agoWe need some sort of escrow for source code of closed-source product. Whenever there is practical need to have access to source code, it should be available.
- spockz 5y agoOkay. Just like any other software that should be firewalled in to only connect to what it should connect to. Moreover, I think meta sploit already has this vulnerability built in so it should be trivial to test/fuzz the application.