GitHub

---

Enabling Boost advisor

---

The Boost advisor let you address your findings backlog easier and faster. With it AppSec team can initiate a finding remediation from the Boost finding view.

The following describe how to set it on Bitbucket SCM.

1. Go to the .boost repository.

2. Create a new workflow at .github/workflows/boost-advisor.yml to include the following:

   name: Boost Advisor
   
   on:
     workflow_dispatch:
       inputs:
         payload:
           description: "JSON payload for boost-advisor"
           required: true
           type: string
   
   jobs:
     remediate:
       runs-on: ubuntu-latest
       steps:
         - name: Download boost-advisor
           run: |
             curl -sSL https://assets.build.boostsecurity.io/boost-advisor/get-boost-advisor | sh
         - name: Run boost-advisor
           env:
             BOOST_API_KEY: ${{ secrets.BOOST_API_TOKEN }}
             BOOST_SCM_TOKEN: ${{ secrets.BOOST_SCM_TOKEN }}
             BOOST_LLM_MODEL: ${{ secrets.BOOST_LLM_MODEL }}
             BOOST_LLM_KEY: ${{ secrets.BOOST_LLM_KEY }}
             PAYLOAD: ${{ inputs.payload }}
           run: |
             echo "$PAYLOAD" | /tmp/boost-advisor/latest -
   

3. Create a fine-grained Personal Access Token

   GitHub requires a fine-grained personal access token (PAT) so the advisor can read the repository content and open pull requests.

   Steps to generate the token:

   1. Sign in to GitHub as a user that has admin access to the target repository (or as a user the customer has chosen as the bot identity).

   2. Go to Settings → Developer settings → Personal access tokens → Fine-grained tokens. Direct link: https://github.com/settings/personal-access-tokens/new

   3. Click Generate new token.

   4. Set:

      • Token name: boost-advisor
      • Expiration: choose according to the customer's policy (90 days recommended)
      • Resource owner: the organization / user that owns the target repository
      • Repository access: All repositories or Only select repositories → pick the repository (or repositories) the advisor should run against

   5. Repository permissions - set the following to Read and write:

      • Contents — Read and write (clone and push branches)
      • Pull requests — Read and write (create remediation PRs)
      • Metadata — Read-only (mandatory, granted automatically)

   6. Click Generate token and copy the value — it will not be shown again.

4. Add the secrets to the .boost repository

   Navigate to Settings → Secrets and variables → Actions → New repository secret and create:

   Secret Name	Value
   BOOST_SCM_TOKEN	Workspace or repository access token
   BOOST_LLM_MODEL	LLM model identifier
   BOOST_LLM_KEY	LLM provider API key

   Note

   BOOST_API_TOKEN is provisioned automatically by ZTP and does not need to be added manually.

---

Manual security scans

---

Scanning steps can be added to your GitHub Actions workflow. A scanning step can be added, for example:

      - name: Run Boost Security Semgrep
        uses: boostsecurityio/boostsec-scanner-github@v4
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/semgrep

boostsecurityio/boostsec-scanner-github is the Boost Security action enabling running scanners and uploading results to the Boost Security service. The keyword api_token configures the API key for authenticating the scanner for an API key created from the dashboard Settings Page.

The keyword registry_module specifies the scanner module to use; In the example above, the scanner configured is the Semgrep module with the id boostsecurityio/semgrep.

---

GitHub Action Workflow for source scanning

---

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

Note

Even if the workflow is configured to run the SBOM scanner on pull requests, the SBOM scanner does not collect components inventory on pull requests.

• 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 Semgrep Scanner
        uses: boostsecurityio/boostsec-scanner-github@v4
        with:
          api_token: ${{ secrets.BOOST_API_TOKEN }}
          registry_module: boostsecurityio/semgrep
  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 that scan generated artifacts from the build process. For example, for scanner modules generating SBOM from container images or scanning for vulnerabilities, the container image needs to be generated first.

• Add the Boost Security 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. Your workflow is likely different from 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. If your image name needs to be created dynamically, a step can be inserted before 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.