Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That leaves the original class file intact. Dependency vulnerability scanners can then identify the class file that is problematic.

I have exploded war deployments ( https://www.jrebel.com/learn/what-exploded-and-packaged-depl... ) put in a Tomcat image and the scanner is able to identify the libraries that the classes came from and their vulnerabilities.

I've also got fat jars for Spring Boot batch jobs that are single jars with all of the dependencies packaged in them for ease of copying around a single thing on the server... and the dependency checker is able issues there to based on fingerprints of individual class files.

These work on the "you downloaded this from a known package management server". As long as you are using maven to download the dependencies, a vulnerability checker will be able to identify it. One built into maven ( https://owasp.org/www-project-dependency-check/ // https://jeremylong.github.io/DependencyCheck/dependency-chec... ) will be able to catch these as part of the build itself - irrespective of the shading of the final artifact.

If you are building from source, and obscuring the class names - yes, you can foil an external vulnerability checker (and since you're doing it from source, you are also not downloading it and thus avoiding a maven plugin use)... however, I don't know any projects that go through such lengths to compile 3rd party Java code themselves rather than using a jar, and are trying to evade vulnerability (and license) checkers.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: