Added SpringBootAnalyzer

[henrikplate]

Added SpringBootAnalyzer to inspect and instrument Spring Boot applications packaged as executable, self-contained JARs (with folders BOOT-INF/lib and BOOT-INF/classes). For example, a given executable target/foo.jar will be rewritten to target/vulas/target/foo-steady-instr.jar.

In this context, the following other improvements were implemented:

• Java instrumentation in ClassVisitor sets the major version of the instrumented class to major of the original file, unless that is bigger than the JVM at hand (in which case this major is taken).
• The instrumentation deny list vulas.core.instr.blacklist.classes has been reduced to the packages org.apache.maven.surefire,org.junit,org.eclipse.steady,org.jacoco., which makes that more traces will be collected, esp. for jackson and javassist. This is possible because the instrumentation agent lang-java...with-dependencies repackages many more classes than before.
• plugin-maven does not depend any more on lang-java...with-dependencies, which requires that this file has to be copied explicitly before any instrumentation (the corresponding command is printed to the console).
• Added check for malformed configuration keys in VulasConfiguration.
• Reduced the log level of ZipSlipAnalyzer log messages in case of non-problematic files.
• Fixed bug related to reading config settings from properties files in nested JARs.
• Simplified the creation of agent options inVulasAgentMojo.

TODOs

• [x] Tests
• [x] Documentation

[henrikplate]

@serenaponta I updated the JavaDoc of SpringBootAnalyzer, please merge if you're fine with the changes.

[henrikplate]

@serenaponta please wait a little more before merging, I might have found another problem in the meantime

[henrikplate]

Found it: If the appContext config settings were not provided as env. variables or system properties, i.e. when calling the instr goal on a project having the profile, they were not visible to AbstractInstrumentor and its sub classes, which called new VulasConfiguration(). Some of those sub classes, however, depend on having the application context, e.g. to read the change list of vulnerabilities.

Fixed by calling VulasConfiguration.getGlobal(), to which the profile/plugin configuration settings are added in AbstractVulasMojo.