How to run dynamic analysis successfully

eclipse / steady

Analyses your Java applications for open-source dependencies with known vulnerabilities, using both static analysis and testing to determine code context and usage for greater accuracy. https://eclipse.github.io/steady/

Apache License 2.0

518 stars 123 forks source link

How to run dynamic analysis successfully #592

Open ZupeiNie opened 1 year ago

ZupeiNie commented 1 year ago

I used steady's maven scan by adding configuration in the project's pom file. In use, app and a2c program analysis can succeed and obtain results, but upload, instr, t2c, etc. cannot run successfully. There is a running problem with Dynamic instrumentation (JUnit). At the same time, t2c needs to run during JUnit, so the results cannot be obtained. I would like to ask whether the configuration information in the pom needs to be improved or the source code format and configuration of the project need to be modified, or how to successfully perform t2c program analysis. The github address of the steady test sample is https://github.com/11111821/steady_proj, this includes test sample source code and related command logs. Here is the command execution history.

Here is the front-end interface.

ZupeiNie commented 1 year ago

I checked the log of the a2c command and found that the successfully executed project should have a class file here, and the unsuccessful one will be "Found [0] files"

At the same time, the callgraph of the unsuccessful project cannot be built. The reason for the failure is as follows. Do I need to get the compiled class file before I analyze it? steady.cg.ReachabilityAnalyzer - Call graph cannot be constructed or analyzed, reachability analysis will be interrupted: No entry points could be set, which will not allow to build the callgraph Many failed projects are "No sources to compile", as shown in the figure below, is this the cause of the project or the reason for the configuration?

henrikplate commented 1 year ago

Yes, it is important to compile the project before running a2c. The compiled classes are the entry points for a2c call graph construction.
The instr goal creates a modified version of the project's JAR file. This goal only makes sense if the project JAR can be run stand-alone or deployed in some application container. This goal complements the trace collection happening during the JUnit test execution.
The t2c goal is run after JUnit test execution, not during. It basically takes the collected traces as entry points for the call graph construction. Again, it is important to compile the project beforehand (which is anyhow required for the tests).
The Steady profile included in your POM file looks OK to me.