GitHub Actions¶
Des étapes de scan peuvent être ajoutées à votre workflow GitHub Actions. Par exemple, une étape de scan peut être ajoutée ainsi :
- name: Run BoostSecurity Semgrep
uses: boostsecurityio/boostsec-scanner-github@v4
with:
api_token: ${{ secrets.BOOST_API_TOKEN }}
registry_module: boostsecurityio/semgrep
boostsecurityio/boostsec-scanner-github est l'action BoostSecurity permettant d'exécuter des scanners et d'envoyer les résultats au service BoostSecurity.
Le mot-clé api_token configure la clé API pour authentifier le scanner avec une clé API créée depuis le Settings Page.
Le mot-clé registry_module spécifie le module du scanner à utiliser ; dans l'exemple ci-dessus, le scanner configuré est le module Semgrep avec l'identifiant boostsecurityio/semgrep.
Workflow GitHub Action pour l'analyse du code source¶
Cette configuration est appropriée pour les modules de scanner pour l'analyse SAST ou l'inventaire SBOM à partir du code source sur BoostSecurity.
Note
Même si le workflow est configuré pour exécuter le scanner SBOM sur les pull requests, le scanner SBOM ne collecte pas l'inventaire des composants sur les pull requests.
- Créez un nouveau 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' # Le scanner SBOM ne s'exécute que sur la branche par défaut.
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
Workflow GitHub Action pour scanner des artefacts générés¶
Cette configuration est appropriée pour les modules de scanner qui analysent des artefacts générés par le processus de build. Par exemple, pour des modules de scanner générant des SBOM à partir d'images conteneur ou analysant les vulnérabilités, l'image conteneur doit d'abord être générée.
- Ajoutez le bloc lié au module de scanner BoostSecurity dans votre workflow de build.
Un exemple de configuration de workflow pour l'analyse d'image conteneur est fourni ci-dessous.
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 # Construisez votre image ici
run: docker build . -t acme-analytics
- name: Run Boost Trivy Image Scanner
uses: boostsecurityio/boostsec-scanner-github@v4
with:
api_token: ${{ secrets.BOOST_API_TOKEN }}
registry_module: boostsecurityio/trivy-image
L'étape Build Image est l'endroit où votre image est construite. Votre workflow est probablement différent de l'exemple ci-dessus. La partie à insérer dans votre workflow est l'étape suivante, c'est-à-dire Run Boost Trivy Image Scanner.
Dans l'exemple ci-dessus, le nom de l'image conteneur défini dans la variable d'environnement BOOST_IMAGE_NAME est statique. Si votre nom d'image doit être créé dynamiquement, une étape peut être insérée avant l'étape de scan pour définir la variable d'environnement, c.-à-d. remplacer.
- name: Build Image # Construisez votre image ici
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
L'étape Set Image Name définit la variable d'environnement et la clé env est supprimée de l'étape Run Boost Trivy Image Scanner.