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 analyseurs et d'envoyer les résultats au service BoostSecurity.
Le mot-clé api_token configure la clé API pour authentifier l'analyseur avec une clé API créée depuis le Settings Page.
Le mot-clé registry_module spécifie le module de l'analyseur à utiliser ; dans l'exemple ci-dessus, l'analyseur 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 analyseurs 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 l'analyseur SBOM sur les pull requests, l'analyseur 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' # L'analyseur 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 analyser des artefacts générés¶
Cette configuration est appropriée pour les analyseurs qui analysent des artefacts générés par le processus de build. Par exemple, pour des analyseurs 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 analyseur 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.