Java & Kotlin - Gradle and Maven

We support a couple of ways of tracking Java/Kotlin dependencies, both Gradle and Maven. There are two ways of using Debricked:

1. We either require access to your source code, as well as your dependencies file, due to the way Gradle and Maven work or
2. You may use the source-codeless feature, see below.

As long as you have one or more build.gradle/build.gradle.kts (Gradle) or pom.xml (Maven) in your repository we will automatically scan it/them for dependencies when you have done any of our integrations to your CI/CD pipeline.

We also support Java projects using Bazel, see here for more information.

Source-codeless scans

Debricked supports scanning Maven and Gradle projects without access to the source code. This is done by introducing an extra step in your CI/build pipeline. Next, we will show how to use this feature in GitHub and GitLab for both Maven and Gradle.

Gradle - GitHub

For the GitHub integration you need to set up a GitHub Action. An example of a setup for Gradle is found here (opens new window).

Add the DEBRICKED_TOKEN secret, then add an action. When the pipeline has completed, you should see the following

Note that you can use the environment variables USERNAME and PASSWORD instead of the token if you choose. Do not forget to mask the password so that it does not show up in the logs.

Gradle - GitLab

For GitLab, instead of a workflow file, we need to add or modify your existing GitLab CI configuration in the root folder named .gitlab-ci.yml. An example of such file is given below, full details of the vulnerabilities step can be found here.

stages:
- build
- test

build:
  stage: build
  image: gradle:6.5

  script:
  - sh ./gradlew dependencies > .debricked-gradle-dependencies.txt

  artifacts:
    paths:
    - .debricked-gradle-dependencies.txt
    expire_in: 1 day

vulnerabilities:
  stage: test
  image:
    name: debricked/debricked-scan
    entrypoint: ["/gitlab-ci.sh"]
  script: echo "Done"
  variables:
    USERNAME: $DEBRICKED_USERNAME
    PASSWORD: $DEBRICKED_PASSWORD

Add the environment variables DEBRICKED_USERNAME and DEBRICKED_PASSWORD, and do not forget to mask the password so that it does not show up in the logs. See here for how to add the variables.

Note that wildcards may be used in the artifacts path, e.g., to scan recursively after a file, you may write:

build:
  artifacts:
    paths:
    - **/.debricked-gradle-dependencies.txt

More information regarding artifacts can be found in the GitLab documentation (opens new window).

Gradle - CircleCI

For CircleCI, start by configuring the workflow with credentials as described on our integrations page. Then, to enable source-codeless scans, use a config like this:

workflows:
  version: 2
  flow:
    jobs:
      - sourcecodeless
      - scan:
          requires:
            - sourcecodeless

jobs:
  sourcecodeless:
    docker:
      # specify the version you desire here
      - image: circleci/openjdk:11-jdk

    working_directory: ~/repo

    environment:
      TERM: dumb

    steps:
      - checkout
      - run: sh ./gradlew dependencies > .debricked-gradle-dependencies.txt
      # it is important that the generated dependency tree is persisted and attached to the following scan step
      - persist_to_workspace:
          root: ~/repo
          paths:
            - .debricked-gradle-dependencies.txt

  scan:
    docker:
      # circleci ignores the entrypoint of debricked-scan, so start the scan manually with a step
      - image: debricked/debricked-scan
    
    working_directory: ~/repo
    
    # set debricked username and password as DEBRICKED_USERNAME and DEBRICKED_PASSWORD respectively,
    # inside project settings, to avoid storing them in config
    steps:
      - checkout
      - attach_workspace:
          at: ~/repo
      - run: bash /circleci.sh

Note that wildcards may be used in the "persist" path, e.g., to scan recursively after a file, you may write:

jobs:
    steps:
        - persist_to_workspace:
            paths:
                - **/.debricked-gradle-dependencies.txt

Maven - GitHub

A GitHub example of a setup using Maven can be found here (opens new window). Check the Gradle example above to see how to add GitHub actions.

Add the DEBRICKED_TOKEN secret, and do not forget to mask the token so that it does not show up in the logs.

Note that you can use the environment variables USERNAME and PASSWORD instead of the token if you choose. Do not forget to mask the password so that it does not show up in the logs.

Maven - GitLab

For GitLab, instead of a workflow file, we need to add or modify your existing GitLab CI configuration in the project folder named .gitlab-ci.yml. An example of such file is given below, full details of the vulnerabilities step can be found here (opens new window).

stages:
- build
- test

build:
  stage: build
  image: maven:3.6.3-jdk-11

  script: 
  - mvn dependency:tree
    -DoutputFile=.debricked-maven-dependencies.tgf
    -DoutputType=tgf

  artifacts:
    paths:
    - .debricked-maven-dependencies.tgf
    expire_in: 1 day

vulnerabilities:
  stage: test
  image:
    name: debricked/debricked-scan
    entrypoint: ["/gitlab-ci.sh"]
  script: echo "Done"
  variables:
    USERNAME: $DEBRICKED_USERNAME
    PASSWORD: $DEBRICKED_PASSWORD

Add the environment variables DEBRICKED_USERNAME and DEBRICKED_PASSWORD, and do not forget to mask the password so that it does not show up in the logs. See here for how to add the variables.

Note that wildcards may be used in the artifacts path, e.g., to scan recursively after a file, you may write:

build:
  artifacts:
    paths:
    - **/.debricked-gradle-dependencies.txt

More information regarding artifacts can be found in the GitLab documentation (opens new window).