GitHub¶
Activation de Boost advisor¶
Boost advisor vous permet de traiter votre arriéré de résultats plus facilement et plus rapidement. Avec cet outil, l'équipe AppSec peut lancer une remédiation depuis la vue de résultats Boost.
Ce qui suit décrit comment le configurer sur GitHub.
- Accédez au dépôt
.boost. -
Créez un nouveau workflow à
.github/workflows/boost-advisor.ymlincluant ce qui suit :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 - -
Créez un jeton d'accès personnel à grain fin (fine-grained Personal Access Token)
GitHub nécessite un jeton d'accès personnel à grain fin (PAT) afin que l'advisor puisse lire le contenu du dépôt et ouvrir des Pull Request.
Étapes pour générer le jeton :
-
Connectez-vous à GitHub en tant qu'utilisateur disposant d'un accès administrateur au dépôt cible (ou en tant qu'utilisateur choisi par le client comme identité du bot).
-
Accédez à Settings → Developer settings → Personal access tokens → Fine-grained tokens. Lien direct : https://github.com/settings/personal-access-tokens/new
-
Cliquez sur Generate new token.
-
Définissez :
- Token name : boost-advisor
- Expiration : choisissez selon la politique du client (90 jours recommandés)
- Resource owner : l'organisation / l'utilisateur propriétaire du dépôt cible
- Repository access : All repositories ou Only select repositories → sélectionnez le(s) dépôt(s) sur lesquels l'advisor doit s'exécuter
-
Repository permissions - définissez les éléments suivants sur Read and write :
- Contents — Read and write (cloner et pousser des branches)
- Pull requests — Read and write (créer des Pull Request de remédiation)
- Metadata — Read-only (obligatoire, accordé automatiquement)
-
Cliquez sur Generate token et copiez la valeur — elle ne sera plus affichée par la suite.
-
-
Ajoutez les secrets au dépôt
.boostAccédez à Settings → Secrets and variables → Actions → New repository secret et créez :
Nom du secret Valeur BOOST_SCM_TOKENJeton d'accès à l'espace de travail ou au dépôt BOOST_LLM_MODELIdentifiant du modèle LLM BOOST_LLM_KEYClé API du fournisseur LLM Note
BOOST_API_TOKENest provisionné automatiquement par l'Orchestration Zero Touch (ZTP) et n'a pas besoin d'être ajouté manuellement.
Scans de sécurité manuels¶
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 Boost Security 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 Boost Security permettant d'exécuter des analyseurs et d'envoyer les résultats au service Boost Security. 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 modules d'analyse pour l'analyse SAST ou l'inventaire Nomenclature logicielle à partir du code source sur Boost Security.
Note
Même si le workflow est configuré pour exécuter l'analyseur Nomenclature logicielle sur les pull requests, l'analyseur Nomenclature logicielle 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 Nomenclature logicielle 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 modules d'analyse qui analysent des artefacts générés par le processus de build. Par exemple, pour des modules d'analyse générant des Nomenclatures logicielles à 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 d'analyse Boost Security 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
env:
BOOST_IMAGE_NAME: acme-analytics # définissez le nom de l'image à analyser
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-dessous. 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 acme-analytics
- name: Run Boost Trivy Image Scanner
uses: boostsecurityio/boostsec-scanner-github@v4
env:
BOOST_IMAGE_NAME: acme-analytics # définissez le nom de l'image à analyser
with:
api_token: ${{ secrets.BOOST_API_TOKEN }}
registry_module: boostsecurityio/trivy-image
par
- 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.