GitHub Actions

In this section, you will learn how to integrate the GitHub actions in to your CI pipeline to trigger a Bright scan on every new commit automatically.

A full working example of a GitHub Actions pipeline with Bright can be found here.

Bright provides several actions on the GitHub marketplace. The actions allow you to run a scan, wait until a security issue is detected, and stop the scan without leaving your development environment. You can configure a .yaml file with the available actions and add the file to your pipeline. Once you make a commit to your GitHub Actions pipeline, a scan will be initiated automatically.

More information about the Bright GitHub Actions can be found here:

• Brightsec Github: run-scan
• Brightsec Github: stop-scan
• Brightsec Github: wait-for

You can also integrate the scan results into the “Code Scanning Alerts”. This will significantly facilitate the management of detected issues.

📘

Note:

Although it is possible to configure a CI pipeline with our REST API, it is recommended to use our Bright CLI for an easier, more robust configuration of your pipeline.

Integration configuration guide

Here is a sample .yaml file where we have already set the actions in a workflow.

on:
  push:
    branches:
      - main

jobs:
  wait_for:
    name: Wait for any issues, gh-int + code_scanning_alerts on
    runs-on: ubuntu-latest
    container: node:16
    steps:
      - name: Scan Start
        id: start
        uses: NeuraLegion/run-scan@release
        with:
          api_token: ${{ secrets.BRIGHT_TOKEN}}
          hostname: app.brightsec.com
          name: Bright Scan - ${{ github.sha }}
          restart_scan: $SCAN_ID
      - name: Wait for breakpoint
        id: wait
        uses: NeuraLegion/wait-for@release
        with:
          api_token:  ${{ secrets.BRIGHT_TOKEN }}
          hostname: app.brightsec.com
          scan: ${{ steps.start.outputs.id }}
          wait_for: any
          code_scanning_alerts: true
          github_token: ${{ secrets.GITHUB_TOKEN }}
          timeout: 600 # time in seconds

We are using two actions, which are configured as steps.

Step 1. Run a scan

The first step runs a scan with a name, an API token and a target hostname. In this example, we are re-runing a previous scan by its ID.

- name: Scan Start
        id: start
        uses: NeuraLegion/run-scan@release
        with:
          api_token: ${{ secrets.BRIGHT_TOKEN}}
          hostname: app.brightsec.com
          name: Bright Scan - ${{ github.sha }}
          restart_scan: $SCAN_ID

The scan ID (SCAN_ID), as well as the API token (BRIGHT_TOKEN), is taken from the Bright app. These are the basic inputs needed for scan configuration. For a full list of available inputs and expected outputs, check out a specific action on the GitHub marketplace.

Step 2. Poll the scan status and open the detected vulnerabilities as code scanning alerts

Then we proceed to polling the scan status until it returns a detected issue.

- name: Wait for breakpoint
        id: wait
        uses: NeuraLegion/wait-for@release
        with:
          api_token:  ${{ secrets.BRIGHT_TOKEN }}
          hostname: app.brightseec.com
          scan: ${{ steps.start.outputs.id }}
          wait_for: any
          code_scanning_alerts: true
          github_token: ${{ secrets.GITHUB_TOKEN }}
          timeout: 600 # time in seconds

The wait_for action allows you to follow the “fail-fast” approach by interrupting the build with the first issue found. Moreover, you can set the severity of the first issue to wait for. In our example, it is set to any, meaning that the build will stop automatically once a low, medium, or high severity issue is found. You will also be able to manage the polling duration by specifying the timeout in seconds. The scan will stop upon the timeout expiration if no issue is detected so far. The GitHub token is a required input for the polling action.

We set the code_scanning_alerts to true in order to open the detected issue as a “Code Scanning Alert” that can be viewed and managed in the Security tab for the target of the scan.

After you configure a similar file and add it to your pipeline, it will trigger a scan on every commit made to that pipeline.