Introduction to Source-Codeless Scan for Gradle and Maven

“I want to scan my Gradle and Maven projects without sharing my source code and without compromising even the slightest on scan result quality, can you help me? “

Yes! Now we can! ✨

Debricked always strives to give you the best results of the vulnerability scans, while at the same time minimize the amount of sensitive source code our customers send us. For most languages, such as JavaScript and Python, this means that we only require the build files describing the dependencies, no other code.

However, for certain languages and build systems, such as Maven and Gradle, commonly used by Java, we have until now required a full copy of the repository. This has been required to be able to find all dependencies used in the project. While the repository is only kept for the duration of the scan, typically a very brief time, we realise that this makes some customers feel uncomfortable, and we have been working on a solution to this problem.

Introducing Source-Codeless Scan

However, starting today, we introduce another option for customers using these build systems, and wish to reduce information sent to Debricked. We call this Source-Codeless Scan.

Briefly, what needs to be done is to introduce an extra step, executed in the customer pipeline, that computes the complete dependency tree and stores it in an extra file. This step runs within the customers repository, so it does not communicate with Debricked in any way, thus guaranteeing the confidentiality of your code.

In the next step, this generated file, together with other build files are uploaded to Debricked, without any other parts of the repository. In this way, no application source code will be uploaded. Thus, Debricked has minimal access to your repository.

To show what needs to be done, let’s look at a practical example on how to implement this in your pipeline.

Steps to perform the Debricked integration

This example will use a tiny Java application, using Gradle as a build system. We will use Github Actions to integrate with Debricked, but the same idea can be applied with other providers as well. For further information about other tools, please head to our documentation.

The example code used in this blog post can be found on Github as well .

Briefly, these steps are required:

-Generate the list of dependencies as a part of the pipeline

-Run the Debricked integration which uploads that file to Debricked

Let’s look at these steps in more detail.

Gradle dependencies

For Gradle, this can be achieved quite simply by running the command gradle dependencies, which will print out a dependency tree in the terminal. Instead of just printing it, however, we store it in a special file called .debricked-gradle-dependencies.txt. The filename is important, since Debricked will look for this as a part of the next scanning step.

In the example repository above, we need to modify the Github Action workflow file in  .github/workflow/vulnerabilites.yml. We can simply include the following line to run the required command, assuming you use a Gradle wrapper.

    - run: ./gradlew dependencies > .debricked-gradle-dependencies.txt

If you use any other tool, such as Gitlab, you need to modify it appropriately to ensure you run the equivalent command. You also need to ensure your build step has Java available for Gradle to be able to run. However, if your regular build pipeline is already building your Java application, this is usually already solved.

Upload generated files to Debricked

This step is very similar, if not identical, to how you would normally perform the integration. For Github Actions, which we use in this example, you can simply follow the steps described at Github Actions for integrating with Debricked. In short, you need to add this step after the step above. The integration will automatically detect your generated file, and only upload them.

    - uses: debricked/actions/scan@v1
      env:
         USERNAME: ${{ secrets.DEBRICKED_USERNAME }}
         PASSWORD: ${{ secrets.DEBRICKED_PASSWORD }}

Especially, note that you should not include the UPLOAD_ALL_FILES option, since this would revert to the behaviour where all files are uploaded!

You have now successfully integrated with Debricked, without uploading your source code to the service!

Some final words

At Debricked we naturally take security very seriously, and strive to offer our customers solutions that provide excellent results, while at the same time being easy to use with high security.

With the introduction of this feature, we allow our customers who use build systems such as Gradle, to make adjustments to their pipeline to reduce the information sent to Debricked, which might be required by company policies. Customers can still choose to use the other approach, described in our documentation, which requires less pipeline customization.