java-audit-pipeline

Follow a five-phase pipeline: map all routes and entry points, model authentication coverage, trace data flow from user-controlled sources to dangerous sinks, audit by vulnerability category, then assemble a scored report. Every confirmed finding needs a complete evidence chain.

Extract the JAR with jar -xf, then run CFR against BOOT-INF/classes for business code and selectively decompile suspicious dependencies in BOOT-INF/lib. CFR handles modern Java syntax best; use Procyon or FernFlower as fallbacks.

Key sinks include Runtime.exec and ProcessBuilder for command injection, Statement.executeQuery and MyBatis ${} for SQL injection, ObjectInputStream.readObject and FastJSON parseObject for deserialization, and DocumentBuilderFactory.parse for XXE. Each requires verifying user input reachability.

Semgrep is faster for pattern-based initial screening with customizable rules, while CodeQL supports deeper cross-file data flow queries but requires building a database from compilable code. Tool results are only candidates and must be manually verified against the evidence chain.

Use an evidence contract approach: never mark a vulnerability confirmed without a complete Source-to-Sink trace showing user input reaching the sink with insufficient filtering. Mark incomplete traces as pending verification rather than confirmed findings.

Yes, decompile .class, JAR, or WAR files with CFR first. Decompiled output can serve as evidence, but paths involving lambdas, reflection, or obfuscated code should be downgraded to pending verification status.