3 ms·

I'm not as familiar with Go... I do know that we use a dependency scan that looks at the docker images and recognizes vulnerable versions of various Java librar

by shagie 4y ago

I'm not as familiar with Go... I do know that we use a dependency scan that looks at the docker images and recognizes vulnerable versions of various Java libraries. With Go, can you look at a compiled binary in an image on the artifact repo and identify what libraries it used and if those libraries have vulnerabilities? (and it appears that my question was answered in a sibling comment)

hedora 4y ago
Java's "statically link then scan" approach doesn't really work though. (Some sibling threads explain why.) Even Linux distributions where rebuilding the world is easy (like Debian) insist on breaking dependencies out into shared libaries, since tracking ad hoc vendored dependencies is just too difficult. For example, sometimes people play dynamic loading and renaming tricks to allow multiple versions of the same Java library to coexist. That can usually be detected by vulnerability scanners, but not always.
- shagie 4y ago
  I'm not sure what you mean by "statically link then scan" in the Java context. The fingerprint of the vulnerable class files are the same no matter where they are stored. They could be bundled together, or shoved in a fat jar, or exploded into all their classes -- but the class file always is distinct and identifiable.
  - hedora 4y ago
    What if the project recompiled them from source with some other version of javac, and prepended "My" to each class name?
    - shagie 4y ago
      I am not familiar with any project that goes through such extremes to avoid vulnerability scanners. I am also not aware of any Java developers who build 3rd party libraries from source and avoid using maven (or gradle, or the odd one with ivy). Your "what if..." doesn't describe any workflow that I have ever experienced with Java in a professional (and even hobbyist) context.
      - brabel 4y ago
        I think OP is basically describing shading, which is actually quite common. https://maven.apache.org/plugins/maven-shade-plugin/ https://maven.apache.org/plugins/maven-shade-plugin/
        shagie 4y ago
        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-deployment 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://owasp.org/www-project-dependency-check/ // https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ 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.

by shagie 4y ago

hedora 4y ago

Java's "statically link then scan" approach doesn't really work though. (Some sibling threads explain why.) Even Linux distributions where rebuilding the world is easy (like Debian) insist on breaking dependencies out into shared libaries, since tracking ad hoc vendored dependencies is just too difficult. For example, sometimes people play dynamic loading and renaming tricks to allow multiple versions of the same Java library to coexist. That can usually be detected by vulnerability scanners, but not always.

shagie 4y ago
I'm not sure what you mean by "statically link then scan" in the Java context. The fingerprint of the vulnerable class files are the same no matter where they are stored. They could be bundled together, or shoved in a fat jar, or exploded into all their classes -- but the class file always is distinct and identifiable.
- hedora 4y ago
  What if the project recompiled them from source with some other version of javac, and prepended "My" to each class name?
  - shagie 4y ago
    I am not familiar with any project that goes through such extremes to avoid vulnerability scanners. I am also not aware of any Java developers who build 3rd party libraries from source and avoid using maven (or gradle, or the odd one with ivy). Your "what if..." doesn't describe any workflow that I have ever experienced with Java in a professional (and even hobbyist) context.
    - brabel 4y ago
      I think OP is basically describing shading, which is actually quite common. https://maven.apache.org/plugins/maven-shade-plugin/ https://maven.apache.org/plugins/maven-shade-plugin/
      - shagie 4y ago
        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-deployment 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://owasp.org/www-project-dependency-check/ // https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ 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.