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 fichier de définition de pipeline nommé boost-advisor.yml, par défaut à la racine du dépôt boost.

Boost Security exécute le pipeline nommé boostsecurityio.boost-advisor. Si aucun pipeline ne porte ce nom, Boost Security le crée à partir du fichier boost-advisor.yml situé à la racine du dépôt boost, vous n'avez donc pas besoin d'enregistrer le pipeline manuellement.

Conserver le fichier ailleurs dans le dépôt

Pour stocker la définition du pipeline à un autre emplacement du dépôt boost, enregistrez le pipeline vous-même :

Allez dans Pipelines → New pipeline → Azure Repos Git, sélectionnez le dépôt boost, choisissez Existing Azure Pipelines YAML file, puis sélectionnez votre fichier.
Dans le menu déroulant Run, cliquez sur Save au lieu d'exécuter le pipeline.
Depuis le menu ⋮ du pipeline, cliquez sur Rename/move et nommez-le exactement boostsecurityio.boost-advisor. Boost Security n'exécute que le pipeline portant ce nom.
Ouvrez Pipelines → Library → boostsecurityio → Pipeline permissions et ajoutez le pipeline boostsecurityio.boost-advisor, afin que ses exécutions ne soient pas bloquées en attente de l'autorisation d'utiliser le groupe de variables.

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: |
      set -euo pipefail
      # A variable missing from the group is passed as its unexpanded macro text.
      defined() { [ -n "$1" ] && [[ "$1" != '$('* ]]; }
      if defined "$BOOST_SCM_TOKEN"; then
        echo "Authenticating to Azure DevOps with the BOOST_SCM_TOKEN personal access token"
      elif defined "$AZURE_TENANT_ID" && defined "$AZURE_CLIENT_ID" && defined "$AZURE_CLIENT_SECRET"; then
        echo "Authenticating to Azure DevOps with the service principal"
        ACCESS_TOKEN=$(curl -sS --fail-with-body -X POST "https://login.microsoftonline.com/$AZURE_TENANT_ID/oauth2/v2.0/token" \
          -H "Content-Type: application/x-www-form-urlencoded" \
          -d "grant_type=client_credentials" \
          -d "client_id=$AZURE_CLIENT_ID" \
          --data-urlencode "client_secret=$AZURE_CLIENT_SECRET" \
          -d "scope=499b84ac-1321-427f-aa17-267ca6975798/.default" | jq -er .access_token)
        echo "##vso[task.setvariable variable=BOOST_SCM_TOKEN;issecret=true]$ACCESS_TOKEN"
      else
        echo "##vso[task.logissue type=error]Define BOOST_SCM_TOKEN, or AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET, in the boostsecurityio variable group."
        exit 1
      fi
    displayName: Resolve Azure DevOps credentials
    env:
      BOOST_SCM_TOKEN: $(BOOST_SCM_TOKEN)
      AZURE_TENANT_ID: $(AZURE_TENANT_ID)
      AZURE_CLIENT_ID: $(AZURE_CLIENT_ID)
      AZURE_CLIENT_SECRET: $(AZURE_CLIENT_SECRET)
  - script: |
      export BOOST_SCM_TOKEN=$(BOOST_SCM_TOKEN)
      export BOOST_API_KEY=$(BOOST_API_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)

Par défaut, Boost advisor s'authentifie auprès d'Azure DevOps avec un jeton d'accès personnel (PAT). Pour vous authentifier avec un principal de service Microsoft Entra ID à la place, consultez Authentification avec un principal de service.
1. 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).
2. Cliquez sur votre icône de profil (en haut à droite) → Personal access tokens → + New Token. Lien direct : https://dev.azure.com/{organization}/_usersSettings/tokens
3. 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)
4. 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 personnel créé à l'étape précédente

BOOST_LLM_MODEL Identifiant du modèle LLM

BOOST_LLM_KEY Clé API du fournisseur LLM

Note

BOOST_API_TOKEN est fourni automatiquement par ZTP et n'a pas besoin d'être ajouté manuellement.

Authentification avec un principal de service¶

Au lieu d'un jeton d'accès personnel, Boost advisor peut s'authentifier auprès d'Azure DevOps avec un principal de service Microsoft Entra ID. Un principal de service n'est pas lié à un compte utilisateur, et un seul peut être ajouté à chaque organisation Azure DevOps connectée au locataire Microsoft Entra ID dans lequel il est enregistré. À chaque exécution, le pipeline échange le secret du principal de service contre un jeton d'accès Azure DevOps.

L'advisor peut utiliser le principal de service de votre intégration de compte ADO Boost Security, ou un principal de service dédié à l'advisor. Quel que soit celui que vous utilisez, il doit disposer du niveau d'accès Basic et être membre du groupe Project Contributors des projets hébergeant les dépôts que l'advisor corrige, sinon les push et les PR échoueront avec une erreur 403.

Réutiliser le principal de service de l'intégration de compte ADO

Cette option s'applique lorsque votre intégration de compte ADO utilise la méthode App Registration. Avec la méthode Microsoft Entra ID, l'application BoostSecurity.io appartient à Boost Security et vous ne détenez pas son secret ; créez plutôt un principal de service dédié.

Dans le portail Azure, allez dans Microsoft Entra ID → App registrations et ouvrez l'enregistrement d'application de l'intégration, créé lors de la Configuration Entra ID.
Sur la page Overview de l'application, copiez l'Application (client) ID et le Directory (tenant) ID.
Allez dans Certificates & secrets → + New client secret, et copiez la Value du secret (affichée une seule fois). Un secret dédié vous permet de faire pivoter le secret de l'advisor sans toucher à l'intégration. Lorsque le secret expire, le pipeline de l'advisor échoue jusqu'à ce que vous mettiez à jour AZURE_CLIENT_SECRET dans le groupe de variables.
Vérifiez que le principal de service est membre du groupe Project Contributors de chaque projet hébergeant des dépôts que l'advisor corrige. La Configuration Azure DevOps de l'intégration l'ajoute avec un accès Basic au groupe Project Contributors, et recommande tous les projets.

Créer un principal de service dédié

Dans le portail Azure, allez dans Microsoft Entra ID → App registrations → + New registration, nommez-le boost-advisor, conservez Accounts in this organizational directory only, puis cliquez sur Register.
Sur la page Overview de l'application, copiez l'Application (client) ID et le Directory (tenant) ID.
Allez dans Certificates & secrets → + New client secret, définissez une expiration selon votre politique, et copiez la Value du secret (affichée une seule fois). Lorsque le secret expire, le pipeline de l'advisor échoue jusqu'à ce que vous mettiez à jour AZURE_CLIENT_SECRET dans le groupe de variables.
Dans chaque organisation Azure DevOps hébergeant des dépôts que l'advisor corrige, allez dans Organization settings → Users → Add users en tant que Project Collection Administrator. Recherchez boost-advisor, donnez-lui le niveau d'accès Basic, et ajoutez-le au groupe Project Contributors des projets cibles.

Le principal de service propre à l'intégration doit également rester membre du groupe Project Contributors : le principal de service dédié s'ajoute à celui-ci et ne le remplace pas.

Ensuite, ouvrez Pipelines → Library → boostsecurityio et ajoutez ces variables, à la place de BOOST_SCM_TOKEN. Cliquez sur l'icône de cadenas pour marquer chacune comme secrète. BOOST_LLM_MODEL et BOOST_LLM_KEY de l'étape 4 ci-dessus restent nécessaires.

Nom de la variable	Valeur
`AZURE_TENANT_ID`	Directory (tenant) ID du principal de service
`AZURE_CLIENT_ID`	Application (client) ID du principal de service
`AZURE_CLIENT_SECRET`	Valeur du secret client du principal de service

Note

Le pipeline utilise BOOST_SCM_TOKEN dès qu'elle est définie dans le groupe de variables. Pour passer d'un jeton d'accès personnel au principal de service, supprimez la variable BOOST_SCM_TOKEN.

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  # set image name to scan
            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  # set image name to scan
      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 personnel créé à l'étape précédente
`BOOST_LLM_MODEL`	Identifiant du modèle LLM
`BOOST_LLM_KEY`	Clé API du fournisseur LLM