Comment bloquer les fusions en cas d'échec d'un contrôle Boost Security¶

Lorsqu'une règle de politique utilise l'action Échouer le contrôle, Boost Security signale un contrôle échoué sur la pull request (merge request sur GitLab) dont les modifications enfreignent la règle. Le contrôle échoué empêche la fusion de la pull request uniquement lorsque votre fournisseur de gestion de code source (SCM) est configuré pour l'exiger.

Ce guide configure la branche par défaut d'un dépôt afin qu'une pull request avec un contrôle Boost Security échoué ne puisse pas être fusionnée, sur GitHub, GitLab, Bitbucket et Azure DevOps.

Avant de commencer¶

Le dépôt est analysé par Boost Security.
La politique assignée au dépôt comporte au moins une règle avec l'action Échouer le contrôle. Voir Comment créer une nouvelle politique.
Vous disposez des permissions d'administrateur nécessaires pour modifier les paramètres de branche du dépôt dans votre SCM.

Exigences communes à tous les SCM¶

Quel que soit votre SCM, deux paramètres de la branche par défaut fonctionnent ensemble :

La branche par défaut est protégée. Personne ne peut y pousser directement, de sorte que chaque modification y parvient via une pull request. Sans cela, un push direct contourne entièrement le contrôle Boost Security.
Le contrôle Boost Security est requis. Une pull request ne peut pas être fusionnée tant que le contrôle Boost Security n'a pas réussi. Un contrôle échoué ou toujours en cours d'exécution bloque la fusion.

Boost Security signale un contrôle par scanner, nommé boostsecurity - <scanner>, par exemple boostsecurity - boostsecurityio/scanner ou boostsecurity - boostsecurityio/gitleaks. Exigez le contrôle de chaque scanner dont les résultats doivent bloquer une fusion.

Note

Une analyse ignorée par une politique de scanner signale un contrôle réussi, elle ne bloque donc jamais la fusion.
Dans un monorepo, les contrôles d'un même scanner dans différents sous-dépôts partagent un nom, vous ne pouvez donc pas exiger le contrôle d'un sous-dépôt spécifique.

GitHub¶

Sur GitHub, un ensemble de règles de branche (branch ruleset) protège la branche par défaut et exige les contrôles Boost Security. Voir About rulesets dans la documentation GitHub.

Dans le dépôt, allez dans Settings → Rules → Rulesets, puis cliquez sur New ruleset → New branch ruleset.
Nommez l'ensemble de règles et définissez son Enforcement status sur Active.
Sous Target branches, cliquez sur Add target et sélectionnez Include default branch.
Sous Branch rules, sélectionnez :
- Restrict deletions
- Require a pull request before merging
- Block force pushes
Sélectionnez Require status checks to pass, puis :
1. Facultativement, sélectionnez Require branches to be up to date before merging, afin que les contrôles s'exécutent par rapport au code le plus récent de la branche par défaut.
2. Cliquez sur Add checks, et saisissez le nom du contrôle de chaque scanner qui doit bloquer une fusion, par exemple boostsecurity - boostsecurityio/scanner.
3. Assurez-vous que la source affichée à côté de chaque contrôle est BoostSecurity.io, afin que seul Boost Security puisse le signaler.
Sous Bypass list, ajoutez uniquement les rôles ou équipes qui doivent pouvoir fusionner sans les contrôles, ou laissez-la vide. Toute personne figurant dans la liste de contournement peut fusionner une pull request dont le contrôle Boost Security a échoué.
Cliquez sur Create.

GitLab¶

Sur GitLab, Boost Security signale ses contrôles sous forme de statuts de commit sur le pipeline de la merge request. Une branche par défaut protégée et le contrôle de fusion Pipelines must succeed bloquent une merge request dont le contrôle Boost Security a échoué.

Protégez la branche par défaut. Dans le projet, allez dans Settings → Repository → Protected branches, et protégez la branche par défaut avec :
- Allowed to merge : les rôles pouvant fusionner les merge requests, par exemple Maintainers.
- Allowed to push and merge : No one.
- Allowed to force push : désactivé.
Voir Protected branches dans la documentation GitLab.
Exigez la réussite du pipeline. Allez dans Settings → Merge requests, et sous Merge checks :
- Sélectionnez Pipelines must succeed.
- Laissez Skipped pipelines are considered successful décoché.
Cliquez sur Save changes.

Note

Lorsque Pipelines must succeed est défini pour l'ensemble du groupe ou de l'instance, il apparaît sélectionné et verrouillé dans les paramètres du projet.

Bitbucket¶

Sur Bitbucket, Boost Security signale ses contrôles sous forme de statuts de build sur le dernier commit de la pull request. Une restriction de branche sur la branche par défaut bloque les push directs, et ses contrôles de fusion bloquent une pull request dont le build Boost Security a échoué. Voir Suggest or require checks before a merge dans la documentation Bitbucket.

Dans le dépôt, allez dans Repository settings → Workflow → Branch restrictions, puis cliquez sur Add a branch restriction.
Sous Select branches, sélectionnez By branch name or pattern et saisissez le nom de la branche par défaut, par exemple main.
Sur l'onglet Branch permissions :
- Sous Write access, sélectionnez Only specific people, groups or pipeline branches have write access, et laissez la liste vide, afin que personne ne pousse directement vers la branche.
- Laissez Allow rewriting branch history et Allow deleting this branch décochés, et laissez Pipelines write access vide.
- Sous Merge access via pull requests, sélectionnez les personnes ou groupes pouvant fusionner les pull requests.
Sur l'onglet Merge settings, sous Merge checks :
- Sélectionnez Minimum number of successful builds for the last commit with no failed builds and no in progress builds, et définissez le nombre à 1. Puisqu'aucun build ne peut être échoué ou en cours, chaque build Boost Security doit réussir, quel que soit le nombre de scanners.
Sous Merge conditions, sélectionnez Prevent a merge with unresolved merge checks.
Cliquez sur Save.

Note

Prevent a merge with unresolved merge checks nécessite le plan Premium de Bitbucket Cloud. Sur les autres plans, les contrôles de fusion ne font qu'avertir et ne peuvent pas bloquer la fusion.

Azure DevOps¶

Sur Azure DevOps, Boost Security signale un statut par scanner sur la pull request. Les politiques de branche de la branche par défaut exigent un statut réussi de chaque scanner qui doit bloquer une fusion. Voir Branch policies and settings dans la documentation Azure DevOps.

Une branche avec au moins une politique requise ne peut pas recevoir de push direct : chaque modification passe par une pull request, ce qui protège la branche par défaut.

Dans le projet, allez dans Project settings → Repositories, sélectionnez le dépôt, puis ouvrez l'onglet Policies.
Sous Branch Policies, sélectionnez la branche par défaut.
Sous Status Checks, cliquez sur + pour ajouter une politique de statut, et définissez :
- Status to check : le statut du scanner, par exemple security/boostsecurity - boostsecurityio/gitleaks. Les statuts Boost Security utilisent le genre security et le nom boostsecurity - <scanner>.
- Policy requirement : Required, afin qu'un statut autre que succeeded bloque la pull request.
- Développez Advanced, puis définissez :
  - Authorized identity : Any identity can post this status. Facultativement, pour renforcer la politique, sélectionnez Only the following identity can post this status et choisissez l'identité de votre intégration Boost Security : l'utilisateur propriétaire du jeton d'accès personnel (PAT), ou le principal de service de l'inscription d'application.
  - Reset conditions : laissez Reset status whenever there are new changes décoché. Lorsqu'il est sélectionné, le statut Boost Security ne se termine jamais.
- Path filter : laissez-le vide, afin que la politique s'applique à chaque pull request.
- Policy applicability : laissez Apply by default sélectionné, afin qu'une pull request soit bloquée jusqu'à ce que le scanner signale un statut réussi.
Cliquez sur Save.
Répétez les étapes 3 et 4 pour chaque scanner qui doit bloquer une fusion.