Scanning Java apps built with Gradle


  1. JDK 7 or later
  2. URLs of the backend service and apps Web frontend
  3. The token of a Eclipse Steady workspace

Workspace creation

If you do not have a workspace yet, you can easily create one by going on the application frontend and clicking on the third button in the lower left corner:

Setup workspace button

For a detailed description of workspaces and of the inputs you have to provide in the form that is displayed when you click that button, please see this section of the manual.


The plugin for Gradle requires changes of the following two files:


    buildscript {
        repositories {

        dependencies {
            classpath('') { changing = true }

    allprojects {
        apply plugin: "vulas"

    // Used to identify the scan in the apps Web frontend
    group = <GROUP>
    version = <VERSION>

    // Replace token of test space = <WORKSPACE-TOKEN>

    vulas.shared.backend.serviceUrl = http://localhost:8033/backend/

Note: Rather than adding configuration settings to, they can also be passed as project properties in the command line, e.g., The use of -D system properties for changing configuration settings is discouraged (because of the cache of the Gradle daemon).

The configuration is correct if the Eclipse Steady analysis goals app, a2c etc. are listed among Other tasks when running the following command:

    ./gradlew tasks --all

The Gradle plugin only works with later releases of Gradle. How to upgrade is described here.

Goal execution

See here for a description of all analysis goals.


  1. ./gradlew assemble vulasApp

  2. Connect to the apps Web frontend, then select your workspace and application. The table in tab Dependencies is populated. Dependencies with known vulnerabilities are shown in tab Vulnerabilities.

Assess and mitigate

Once app has been run, the assessment of findings can already start: Each finding shown on the Vulnerabilities tab corresponds to a dependency of an application on a component with a known security vulnerability. See here for more information on how to assess and mitigate findings. Other analysis goals can be used to collect further evidence concerning the reachability of vulnerable code.


  1. ./gradlew vulasReport

  2. A summary report is written to disk (in HTML, XML and JSON format), by default into folder target/vulas/report. By default a build exception is thrown if the application includes a library subject to known vulnerabilities.


  1. ./gradlew vulasClean

  2. All application-specific data in the Eclipse Steady backend are deleted.

Run clean whenever the application changes

If you already scanned your project in the past, you should run the clean goal prior to new analyses in order to delete the old analysis results in the backend. Otherwise, old analysis results will be shown together with new results. For example, if you updated a dependency from a vulnerable to a non-vulnerable version, both versions will be shown in the apps Web frontend.