Skip to content

Configuring Boost scanner modules with your CI

Boostsecurity, through a modularized approach, supports a large number of specialized scanners enabling security automation for several security types such static analysis (SAST), software composition (SCA), container scanning and software bill of material inventory (SBOM). Consequently, Boostsecurity enables security automation to be integrated in development workflows, for many programming languages and ecosystems.

You can easily add the Boostsecurity scanner and begin scanning your source code and related artifacts by using one of our officially supported CI plugins:

If you're using a different CI system you can use the Boost CLI to setup the workflow.

Scanner Authentication to the Boostsecurity service

In order to allow the Boostsecurity scanner to upload results, an API token must be configured. To do so, you first must generate an API Key by visiting the Boostsecurity dashboard's Settings Page.

Once you have the API key, we recommend you use the your CI environment's native secrets management system and we recommend you give it the name BOOST_API_TOKEN. We will refer to this secret in the examples below.

GitHub Actions

The Boost integration for GitHub is packaged as GitHub Action you can use as step in your workflow jobs. The example of configuration for GitHub Actions depends on whether the scan needs to be done on the project's source code or on produced artifacts. The principal components from enabling the Boostsecurity scasnner, in the workflow, is:

      - name: Run Native Scanner
        uses: boostsecurityio/boostsec-scanner-github@v4
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/native-scanner

boostsecurityio/boostsec-scanner-github is the Boostsecurity action enabling to run scanners and uploading results to the Boostsecurity service. The keyword api_token configures the API key for authenticating the scanner to the backend. The keyword registry_module specifies the scanner module to use, in the example above, the scanner configured is the Boostsecurity native scanner with id boostsecurityio/native-scanner.

Github Action Workflow for source scanning

This configuration is appropriate for scanner modules for SAST scanning or SBOM inventory from source code.

Note: Even if the workflow is configured to run the SBOM scanner on PRs, the SBOM scanner does not collect components inventory on PRs.

  • Create a new workflow: .github/workflows/boost.yml:
name: boostsecurity.io
on:
  workflow_dispatch:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
    types:
      - opened
      - synchronize
jobs:
  boost-sast:
    name: SAST
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Run Native Scanner
        uses: boostsecurityio/boostsec-scanner-github@v4
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/native-scanner
  boost-sbom:
    name: SBOM
    if: github.event_name != 'pull_request'  # SBOM scanner only runs on default branch.
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Upload SBOM from Trivy
        uses: boostsecurityio/boostsec-scanner-github@v4
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/trivy-sbom

Github Action Workflow for scanning generated artifacts

This configuration is appropriate for scanner modules requiring to scan generated artifact from the build process. For example scanner modules generating SBOM from container images, or scanning for vulnerabilities, the container image needs to be generated first.

  • Add the Boostsecurity scanner module related stanza to your build workflow

An example of workflow configuration for container image scanning is provided below.

name: build acme docker image
on:
  workflow_dispatch:
  push:
    branches:
      - main
  ...
jobs:
  generate-acme-image:
    name: Container
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Build Image   # Build your image here
        run: docker build . -t acme-analytics
      - name: Run Boost Trivy Image Scanner
        uses: boostsecurityio/boostsec-scanner-github@v4
        env:
          BOOST_IMAGE_NAME: acme-analytics  # set image name to scan
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/trivy-image
The step Build Image is where your image is built. It is likely your workflow is different than the example below, the part that needs to be inserted in your workflow is the step after, i.e. Run Boost Trivy Image Scanner. In the example above, the container image name set in the environment variable BOOST_IMAGE_NAME is static. In the case where your image name needs to be created dynamically, a step can be inserted prior to the scan step, to set the environment variable. I.e. replace
      - name: Build Image   # Build your image here
        run: docker build . -t acme-analytics
      - name: Run Boost Trivy Image Scanner
        uses: boostsecurityio/boostsec-scanner-github@v4
        env:
          BOOST_IMAGE_NAME: acme-analytics  # set image name to scan
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/trivy-image
with
      - name: Build Image   # Build your image here
        run: docker build . -t <some image name>
      - name: Set Image Name
        run: echo "BOOST_IMAGE_NAME=<some image name>" >> $GITHUB_ENV
      - name: Run Boost Trivy Image Scanner
        uses: boostsecurityio/boostsec-scanner-github@v4
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/trivy-image
Note the Set Image Name step setting the environment variable and the key env removed from step Run Boost Trivy Image Scanner.

Buildkite

The Boost integration for Buildkite is packaged as a plugin that runs as a command hook. The plugin executes the Boost Scanner to scan repositories for vulnerabilities and uploads results to the Boost platform. Adding Boostsecurity scanning into your workflow is just a matter of adding a stanza to your Buildkite pipeline configuration file. The configuration options and location to add the stanza depends on whether the scanning needs to be done on the project's source code or on generated artifact, such as container images.

The first step in setting Boost for Buildkite is to define the environment variable BOOST_API_TOKEN for your Buildkite Agent. Refer to the Buildkite documentation for how to do it.

Buildkite Pipeline Steps for scanning source code

This configuration is appropriate for scanner modules for SAST scanning or SBOM inventory from source code for example.

Note: Even if the workflow is configured to run the SBOM scanner on PRs, the SBOM scanner does not collect components inventory on PRs.

When configuring your Buildkite to run the Boostsecurity scanning from the project's source code, add the following stanza to your pipeline.yml:

steps:
  - label: "boostsecurity scanner"
    plugins:
      - boostsecurityio/boostsec-scanner#v4:
          registry_module: boostsecurityio/trivy-sbom
        if: build.branch == "main"
      - boostsecurityio/boostsec-scanner#v4:
          registry_module: boostsecurityio/native-scanner

Buildkite Pipeline Steps for scanning generated artifact

This configuration is appropriate for scanner modules requiring to scan generated artifact from the build process. For example scanner modules generating SBOM from container images, or scanning for vulnerabilities, the container image needs to be generated first.

When configuring your Buildkite to run the Boostsecurity scanning from the generated artifacts, add the following stanza to your pipeline.yml:

steps:
  - command: echo 'BOOST_IMAGE_NAME=myimage:tag' >> $BUILDKITE_ENV_FILE
  - wait
  - label: "Building the Image"
    command: docker build -t ${BOOST_IMAGE_NAME} .
    branches: "main"
  - wait
  - label: "boostsecurity scanner"
    plugins:
      - boostsecurityio/boostsec-scanner#v4:
          registry_module: boostsecurityio/trivy-image
    branches: "main"

In the first step, the docker image is built. In the second step, the image is scanned with the Boost image scanning module. In order to scan the image, the environment variable BOOST_IMAGE_NAME is set to the image name.

CircleCI

The Boost CI integration for CircleCI provides an orb with both a job running on a machine executor and a command to use within your pipeline configurations. Both invocation methods will execute the Boost Scanner to scan repositories for vulnerabilities and uploads the results to the Boost service.

The CircleCI Orb is published on the registry and may be found here. The configuration that needs to be added to your .circleci/config.yml depends on whether the scanner runs on the project's source code or on a produced artifact such as built container image.

The first step in setting Boost for CircleCI is to create a CircleCI context called boost-security containing a secret named BOOST_API_TOKEN with your organization's API KEY.

CircleCi Job for source scanning

This configuration is appropriate for scanner modules for SAST scanning or SBOM inventory from source code for example.

Note: Even if the workflow is configured to run the SBOM scanner on PRs, the SBOM scanner does not collect components inventory on PRs. When configuring your CircleCI to run the Boostsecurity scanning from the project's source code, add the following stanza to your .circleci/config.yml:

version: '2.1'
orbs:
  boost-security-scanner: boostsecurityio/scanner@4

workflows:
  build:
    jobs:
      steps:
        - boost-security-scanner/scan:
            context: boost-security
            registry_module: boostsecurityio/native-scanner
        - when:
            condition:
              or:
                - equal: [ main, << pipeline.git.branch >> ]
            steps:
              - boost-security-scanner/scan:
                  context: boost-security
                  registry_module: boostsecurityio/trivy-sbom             

  version: 2
In the example above, the native-scanner module runs on both commits on the main branch and on pull requests. However the scanner module trivy-sbom for the SBOM service, runs only on commits on the main branch. Note that in the example above, the scanner modules native-scanner and trivy-sbom are configured to be used, however, you can configure the scanner module required, refer to Registry Modules for the available scanner modules.

CircleCi Job for scanning generated artifacts

This configuration is appropriate for scanner modules requiring to scan generated artifact from the build process. For example scanner modules generating SBOM from container images, or scanning for vulnerabilities, the container image needs to be generated first.

In order to enable scanning of generated artifacts, add the Boostsecurity scanner module related stanza to your build workflow in .circleci/config.yml, in the appropriate location after the step where the afterfact was generated. Note that the example below is related to scanning a container image for vulnerabilities.

version: '2.1'
orbs:
  boost-security-scanner: boostsecurityio/scanner@4

workflows:
  ... some environment specific declarations and steps

jobs:
  ... some test and other jobs

  build-push:
    executor: default
    steps:
      ... some steps specific to your environment
      - checkout
      - run:
          command: make docker.build
      - run:
          command: make docker.push
      - when:
          condition:
            or:
              - equal: [ main, << pipeline.git.branch >> ]
          steps:
            - run:
                name: make docker.echo.tag
                command: |
                  BOOST_IMAGE_NAME=$(make docker.echo.tag)
                  echo "export BOOST_IMAGE_NAME=${BOOST_IMAGE_NAME}" | tee -a $BASH_ENV
            - boost-security-scanner/scan:
                registry_module: boostsecurityio/trivy-image
  version: 2
The condition - equal: [ main, << pipeline.git.branch >> ] makes the image scanning module run on commit to main only, after the image was built. The command BOOST_IMAGE_NAME=$(make docker.echo.tag) and echo "export BOOST_IMAGE_NAME=${BOOST_IMAGE_NAME}" | tee -a $BASH_ENV sets the environment variable required by the boost trivy scanner module to know which image to scan.