Azure DevOps¶

Activer Boost advisor¶

Boost advisor vous permet de traiter votre arriéré de résultats plus facilement et rapidement. Grâce à lui, l'équipe AppSec peut initier une remédiation depuis la vue des résultats Boost.

Voici comment le configurer sur Azure DevOps.

Accédez au dépôt boost.

Ajoutez un nouveau fichier de définition de pipeline (par exemple : .azuredevops/boost-advisor.yml) et enregistrez-le comme nouveau pipeline :

Dans le projet Azure DevOps, allez dans Pipelines → New pipeline.
Sélectionnez Azure Repos Git (ou GitHub, selon l'emplacement du code) → choisissez le dépôt.
Choisissez Existing Azure Pipelines YAML file → sélectionnez le chemin vers boost-advisor.yml.
Enregistrez (ne l'exécutez pas encore — les secrets doivent d'abord être configurés).

Le pipeline attend un groupe de variables nommé boostsecurityio (déclaré dans le YAML à variables.group). Créez-le sous Pipelines → Library → + Variable group.

Contenu du fichier :

trigger: none

parameters:
  - name: payload
    type: string
    default: ""

variables:
  - group: boostsecurityio

pool:
  vmImage: ubuntu-latest

steps:
  - script: |
      set -euo pipefail
      curl -sSL https://assets.build.boostsecurity.io/boost-advisor/get-boost-advisor | sh
    displayName: Download boost-advisor
  - script: |
      export BOOST_SCM_TOKEN=$(BOOST_SCM_TOKEN)
      export BOOST_API_KEY=$(BOOST_SCM_TOKEN)
      export BOOST_LLM_MODEL=$(BOOST_LLM_MODEL)
      export BOOST_LLM_KEY=$(BOOST_LLM_KEY)
      echo "$PAYLOAD" | /tmp/boost-advisor/latest -
    displayName: Run boost-advisor
    env:
      PAYLOAD: ${{ parameters.payload }}

Créer le jeton d'accès personnel (Personal Access Token) Azure DevOps utilise un jeton d'accès personnel (PAT) pour l'authentification SCM.
Connectez-vous à Azure DevOps en tant qu'utilisateur disposant au moins d'un accès Basic au projet (et de droits admin sur le dépôt, afin que la création de PR soit autorisée).
Cliquez sur votre icône de profil (en haut à droite) → Personal access tokens → + New Token. Lien direct : https://dev.azure.com/{organization}/_usersSettings/tokens
Définissez :
- Name : boost-advisor
- Organization : l'organisation cible
- Expiration : selon la politique du client (1 an maximum)
- Scopes : cliquez sur Custom defined et accordez :
  - Code → Read & write (clone et push)
  - Code → Status (optionnel, pour définir les statuts de commit)
  - Pull Request Threads → Read & write (publier des commentaires de revue, optionnel)
Cliquez sur Create et copiez le jeton (affiché une seule fois).

Les PAT ADO respectent les permissions de l'utilisateur. Assurez-vous que l'utilisateur propriétaire du PAT est membre du groupe Contributors du dépôt cible, sinon les push et les PR échoueront avec une erreur 403.
Ajouter les secrets au groupe de variables

Ouvrez Pipelines → Library → boostsecurityio et ajoutez ces variables. Cliquez sur l'icône de cadenas pour marquer chacune comme secrète.

Nom de la variable Valeur

BOOST_SCM_TOKEN Jeton d'accès de l'espace de travail ou du dépôt

BOOST_LLM_MODEL Identifiant du modèle LLM

BOOST_LLM_KEY Clé API du fournisseur LLM

Note

BOOST_API_TOKEN est provisionné automatiquement par l'Orchestration Zero Touch et n'a pas besoin d'être ajouté manuellement.

Analyses de sécurité manuelles¶

Des étapes d'analyse peuvent être ajoutées à vos pipelines Azure DevOps en installant l'extension Boost Security.

Pour ce faire :

Accédez à l'Marketplace.
Cliquez sur Obtenir gratuitement.
Sélectionnez votre organisation et cliquez sur Installer.

De plus, il est nécessaire de rendre le Boost API Token disponible dans vos Variables. Si vous n'avez pas encore créé de jeton API, vous pouvez en créer un sur la page Paramètres du tableau de bord.

Une fois tout prêt, une étape d'analyse peut être ajoutée, par exemple :

  - stage: Run Security Scanners
    variables:
      - group: boostsecurity
      - name: boostApiToken
        value: $[variables.BOOST_API_TOKEN]
    jobs:
      - job:
        steps:
          - task: BoostSecurityScan@1
            inputs:
              apiToken: $(boostApiToken)
              registryModule: boostsecurityio/semgrep

BoostSecurityScan est la tâche de pipeline Boost Security permettant d'exécuter les analyseurs et de téléverser les résultats vers le service Boost Security.

L'entrée apiToken configure la clé API pour authentifier le scanner.

Le mot-clé registry_module spécifie l'analyseur à utiliser. L'exemple ci-dessus configure l'analyseur Semgrep avec l'ID boostsecurityio/semgrep.

Azure DevOps pour l'analyse du code source¶

Cette configuration convient aux modules d'analyse pour le SAST ou pour l'inventaire Nomenclature logicielle à partir du code source.

Remarque : Même si le pipeline 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.

  - stage: Run Security Scanners
    variables:
      - group: boostsecurity
      - name: boostApiToken
        value: $[variables.BOOST_API_TOKEN]
      - name: isMainBranch
        value: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
    jobs:
      - job:
        steps:
          - task: BoostSecurityScan@1
            inputs:
              apiToken: $(boostApiToken)
              registryModule: boostsecurityio/semgrep
          - task: BoostSecurityScan@1
            condition: eq(variables.isMainBranch, 'true')
            inputs:
              apiToken: $(boostApiToken)
              registryModule: boostsecurityio/trivy-sbom

Azure DevOps pour l'analyse des artefacts générés¶

Cette configuration convient aux analyseurs qui analysent des artefacts générés par le processus de build. Par exemple, les analyseurs qui génèrent des Nomenclature logicielle à partir d'images conteneurs ou qui recherchent des vulnérabilités doivent d'abord générer l'image conteneur.

Ajoutez la section relative au analyseur Boost Security à votre pipeline de build, par exemple :

  - stage: Build Step
    variables:
      - group: boostsecurity
      - name: boostApiToken
        value: $[variables.BOOST_API_TOKEN]
    jobs:
      - job:
        steps:
          - task: Bash@3
            displayName: Build Image
            inputs:
              targetType: "inline"
              script: |
                docker build . -t acme-analytics
          - task: BoostSecurityScan@1
            env:
              BOOST_IMAGE_NAME: acme-analytics  # définir le nom de l'image à analyser
            inputs:
              apiToken: $(boostApiToken)
              registryModule: boostsecurityio/trivy-image

Dans l'exemple ci‑dessus, le nom de l'image conteneur défini dans la variable d'environnement BOOST_IMAGE_NAME est statique. Si le nom de votre image doit être créé dynamiquement, vous pouvez insérer une étape avant l'étape d'analyse pour définir la variable d'environnement. Par exemple, remplacez :

  steps:
    - task: Bash@3
      displayName: Build Image
      inputs:
        targetType: "inline"
        script: |
          docker build . -t acme-analytics
    - task: BoostSecurityScan@1
      env:
        BOOST_IMAGE_NAME: acme-analytics  # définir le nom de l'image à analyser
      inputs:
        apiToken: $(boostApiToken)
        registryModule: boostsecurityio/trivy-image

par

  steps:
    - task: Bash@3
      displayName: Build Image
      inputs:
        targetType: "inline"
        script: |
          docker build . -t acme-analytics
          echo "##vso[task.setvariable variable=BOOST_IMAGE_NAME]my_image_name_and_tag"
    - task: BoostSecurityScan@1
      inputs:
        apiToken: $(boostApiToken)
        registryModule: boostsecurityio/trivy-image

Note

L'étape task.setvariable définit la variable d'environnement, et la clé env est supprimée de l'étape BoostSecurityScan.

Nom de la variable	Valeur
`BOOST_SCM_TOKEN`	Jeton d'accès de l'espace de travail ou du dépôt
`BOOST_LLM_MODEL`	Identifiant du modèle LLM
`BOOST_LLM_KEY`	Clé API du fournisseur LLM