Passer au contenu principal

​
Aperçu

​
Fonctionnement

Les règles de blocage sont des garde-fous qui définissent quels résultats doivent faire échouer une vérification de pull request ou un pipeline CI. Cela permet de garantir que votre base de code respecte les normes de sécurité et de qualité de votre organisation. Vous pouvez créer trois types de règles de blocage :
  • Règles de vulnérabilité du code : bloquent les pull requests selon les vulnérabilités, les problèmes de qualité du code ou les deux
  • Règles de vulnérabilité des dépendances : bloquent les pull requests selon les dépendances vulnérables détectées par le scan SCA
  • Règles de License Compliance : bloquent les dépendances avec des licences SPDX spécifiques ou des familles de licences

​
Pour qui c’est

Les règles de blocage sont principalement conçues pour :
  • Équipes de développement
  • Chefs de projet
  • Professionnels de la sécurité
Cette fonctionnalité est particulièrement utile pour les organisations ayant des exigences strictes en matière de conformité ou celles travaillant sur des applications critiques où la qualité du code et la sécurité sont primordiales.

​
Caractéristiques clés et avantages

Définir des règles basées sur les Common Weakness Enumerations (CWE) pour bloquer les pull requests introduisant des types spécifiques de vulnérabilités ou des problèmes de qualité de code.
Attribuez des niveaux d’urgence (par exemple, critique, élevé, moyen, bas) à différents types de problèmes, ce qui vous permet de les prioriser et de les gérer en conséquence.
Pour les règles de vulnérabilité des dépendances, définissez une plage inclusive de scores CVSS afin de bloquer les dépendances vulnérables selon leur score.
Pour les règles Dependency Vulnerability qui s’appliquent à la CI, restreignez le blocage aux dépendances dont le code vulnérable est réellement accessible depuis votre application, afin que les paquets inutilisés ou inaccessibles ne fassent pas échouer votre pipeline.
Bloquez les dépendances selon des identifiants de licence SPDX spécifiques ou selon les familles Copyleft, Permissive et Commercial.
Appliquez des règles de blocage à des projets spécifiques, à des tags de projet, ou à l’ensemble de votre organisation, ce qui vous donne un contrôle granulaire sur quels projets sont soumis à quelles règles.
Créez, modifiez et supprimez facilement des règles de blocage grâce à une interface conviviale, afin de garantir que vos règles restent à jour avec vos besoins évolutifs.
Activez ou désactivez temporairement les règles de blocage selon vos besoins, sans perdre leur configuration.

​
Types de règles

Les règles de blocage prennent en charge trois types distincts pour offrir une couverture de sécurité complète :

Code Vulnerability

Bloque les pull requests selon les vulnérabilités de sécurité, les problèmes de qualité du code ou les deux.Configurer par :
  • Sélection d’un type de problème : All, Vulnerabilities ou Code Quality
  • Sélection de catégories CWE (Common Weakness Enumeration) précises
  • Définir les niveaux d’urgence/sévérité
Utilisez ce type de règle pour empêcher les injections SQL, les XSS, la cryptographie non sécurisée et d’autres vulnérabilités du code.

Dependency Vulnerability

Bloque les pull requests selon les dépendances vulnérables détectées par l’analyse de la composition logicielle (SCA).Configurer par :
  • Définir les niveaux d’urgence/gravité (Critical, High, Medium, Low)
  • Ou définition d’une plage inclusive de scores CVSS comprise entre 0,0 et 10,0
  • Éventuellement en restreignant par accessibilité (règles CI uniquement)
Utilisez ce type de règle pour empêcher l’introduction de paquets présentant des vulnérabilités connues et protéger votre chaîne d’approvisionnement.

License Compliance

Bloque les pull requests ou les pipelines CI lorsqu’une dépendance utilise une licence refusée.Configurer par :
  • Sélection d’une ou plusieurs familles de licences : Copyleft, Permissive ou Commercial
  • Saisie d’identifiants SPDX spécifiques, par exemple AGPL-3.0
Utilisez ce type de règle pour appliquer la politique de licences open source et commerciales de votre organisation.

​
Comment cela fonctionne avec GitHub

Prérequis Vous devez avoir installé et configuré la Corgea GitHub App avec les autorisations de dépôt requises.
1

Soumission de pull request

Le développeur soumet une pull request avec des modifications de code
2

Analyse automatisée

Le système analyse les modifications du code au regard des règles de blocage actives
3

Validation des règles

Si des violations sont détectées, la pull request est automatiquement bloquée
4

Notification au développeur

Le développeur reçoit une notification détaillée concernant les violations des règles
5

Résolution

Avant que la fusion ne soit autorisée, le développeur doit corriger les violations et les marquer comme Fixed, ou les classer comme False Positive ou Accepted Risk

​
Comment cela fonctionne avec Azure DevOps

Prérequis Assurez-vous que l’intégration Azure DevOps avec Corgea est configurée et que vous disposez des autorisations nécessaires.
1

Soumission de pull request

Un développeur soumet une pull request avec des modifications de code dans Azure DevOps.
2

Analyse automatisée

Le système évalue les modifications du code selon les règles de blocage actives définies dans Corgea.
3

Validation des règles

Si des violations sont détectées, la pull request est automatiquement bloquée.
Le développeur ne peut pas fusionner la pull request tant que les violations ne sont pas résolues.
4

Notification au développeur

Le développeur reçoit un lien vers les informations détaillées sur les problèmes ayant entraîné l’échec, dans la page de scan Corgea.
5

Résolution

Le développeur doit résoudre les violations en les corrigeant ou en les marquant comme False Positive ou Accepted Risk avant que la fusion puisse se poursuivre.

​
Guide d’utilisation

​
Création d’une nouvelle règle de blocage

1

Commencer la création

Cliquez sur le bouton « Add Blocking Rule »
2

Choisir le type de règle

Sélectionnez le type de règle de blocage :
  • Code Vulnerability : bloque les pull requests selon les problèmes de sécurité du code (résultats SAST)
  • Dependency Vulnerability : bloque les pull requests selon les dépendances vulnérables (résultats SCA)
  • License Compliance : bloque les dépendances selon les licences SPDX refusées ou les familles de licences
Add Blocking Rule modal with Applies To, rule types, and Issue Type
3

Informations de base

Saisissez le nom et la description de la règle, puis choisissez Applies To :
  • Pull Requests applique automatiquement la règle dans les vérifications de pull request.
  • CI applique la règle uniquement lorsqu’un pipeline la nomme avec corgea scan --block-on <slug>. Les règles CI ne bloquent pas les pull requests.
Les nouvelles règles utilisent Pull Requests par défaut. Corgea génère le slug à partir du nom de la règle et l’affiche dans la liste des règles.Les règles de pull request ne commentent que les résultats qui nécessitent une action. Corgea ignore les commentaires pour les résultats confirmés comme inaccessibles, ceux mis en attente parce qu’ils sont considérés comme des faux positifs ou proviennent de langages non pris en charge, ainsi que ceux situés dans des chemins ignorés par le projet. Ces résultats restent disponibles dans Corgea pour examen, mais ne bloquent pas la pull request.
Add Blocking Rule modal with CI selected and License Compliance configured
4

Configurer les paramètres

Pour les règles Code Vulnerability : choisissez un Issue Type afin d’appliquer la règle à All les résultats, uniquement aux Vulnerabilities ou uniquement aux résultats de Code Quality. All est la valeur par défaut et préserve le comportement des règles existantes. Sélectionnez ensuite les niveaux d’urgence (Critical, High, Medium ou Low) et/ou les CWE ciblées ; au moins un de ces critères est requis.Pour les règles Dependency Vulnerability : choisissez un filtrage par sévérité ou par score CVSS. Sélectionnez les niveaux d’urgence (Critical, High, Medium ou Low), ou saisissez un score CVSS minimal et maximal compris entre 0,0 et 10,0 afin de bloquer les dépendances vulnérables dans cette plage inclusive. Si la règle s’applique à la CI, vous pouvez également sélectionner un ou plusieurs états d’Accessibilité pour la restreindre davantage — voir Filtrage par accessibilité.Pour les règles License Compliance : sélectionnez au moins une famille de licences refusée (Copyleft, Permissive ou Commercial) ou saisissez un ou plusieurs identifiants SPDX. Une dépendance est bloquée lorsqu’une licence signalée correspond à une famille sélectionnée ou à un ID spécifique.
5

Définir le périmètre

Choisissez les projets concernés et/ou les tags de projet (optionnel). Une règle s’applique lorsqu’un projet est sélectionné directement ou possède un tag sélectionné. Si aucun projet ou tag n’est sélectionné, la règle s’applique à tous les projets.
6

Sauvegarder

Révisez et cliquez sur « Create »

​
Gestion des règles existantes

Recherchez les règles par nom ou par paramètre, ou filtrez la liste par tag de projet ou par cible Applies To. Le tableau des règles affiche le slug de chaque règle dans la colonne ID et présente le périmètre projet, le type de règle et la cible Pull Requests ou CI sous Triggers On. Sélectionnez un slug pour le copier et l’utiliser dans une commande CI. Les règles sans périmètre de projet ou de tag s’appliquent à tous les projets ; les longues listes sont regroupées derrière une infobulle +N more.
Blocking rules list showing slug, Triggers On chips, and CI badge

​
Appliquer les règles en CI

Créez une règle active avec Applies To défini sur CI, puis passez son slug à la commande de scan. Nommez les règles d’après la condition qui les déclenche — par exemple criticals, et non no-criticals — afin que --block-on se lise comme une affirmation directe. --block-on nécessite Corgea CLI 1.10.0 ou une version ultérieure.
Pour appliquer plusieurs règles CI, fournissez leurs slugs sous forme de liste séparée par des virgules. La commande échoue lorsqu’un résultat viole l’une des règles nommées. Un slug inconnu, une règle inactive ou une règle applicable aux pull requests est traité comme une erreur de configuration et n’est pas ignoré. --block-on n’est pris en charge que par le scanner BLAST et ne peut pas être combiné avec --fail ou --fail-on.
  1. Localiser la règle dans le tableau
  2. Cliquez sur le bouton « Edit »
  3. Modifier les paramètres si nécessaire
  4. Cliquez sur « Update » pour enregistrer

​
Afficher les règles appliquées aux scans

Vous pouvez consulter les règles de blocage qui s’appliquent à vos scans à deux endroits :
  1. Sur la page des détails du scan, vous verrez une section « Blocking Rules » affichant toutes les règles évaluées :
  1. Dans les détails d’un problème, vous pouvez voir les règles de blocage qu’il a déclenchées :
Cela facilite la compréhension des règles qui affectent vos scans et des problèmes spécifiques, vous aidant à identifier pourquoi certains changements peuvent être bloqués.

​
Filtrage par accessibilité

Dans la plupart des projets, la majorité des dépendances vulnérables ne sont jamais réellement utilisées par votre code. Le filtrage par accessibilité permet à une règle Dependency Vulnerability de ne bloquer que les résultats qui importent : une CVE critique dans un paquet que vous n’appelez jamais ne fait plus échouer votre pipeline.
Disponible uniquement pour les règles CI L’accessibilité est analysée sur les scans que vous lancez vous-même avec corgea scan, et non sur ceux déclenchés automatiquement à l’ouverture d’une pull request. Définissez Applies To sur CI pour utiliser ce filtre ; l’option est masquée pour les règles Pull Request. Référencez ensuite la règle depuis votre pipeline avec corgea scan --block-on <slug>.
Prérequis L’accessibilité nécessite l’activation de AI-Native SCA pour votre organisation. Sans cette option, aucune dépendance n’est analysée et une règle utilisant ce filtre ne bloque jamais rien. L’éditeur de règles vous avertit lorsque l’option est désactivée.
Add Blocking Rule modal with CI and Dependency Vulnerability selected and Reachable checked under Reachability
Sélectionnez un ou plusieurs des états suivants : Le filtre d’accessibilité est combiné avec le filtre de sévérité, de CVSS ou Malicious, et ne le remplace pas : un résultat doit correspondre aux deux. Une règle définie sur la sévérité Critical et sur Reachable ne bloque que les vulnérabilités critiques qui sont également accessibles. Laisser l’accessibilité vide conserve le comportement existant de la règle, qui bloque indépendamment de l’accessibilité.

​
Attente de l’analyse

L’analyse d’accessibilité s’exécute après la fin du scan lui-même : corgea scan continue donc d’interroger Corgea jusqu’à ce qu’elle se termine, au lieu de renvoyer un résultat immédiatement. L’analyse s’achève une fois toutes les dépendances directes analysées, ce qui prend généralement quelques minutes et au maximum 30. Ce filtre échoue de façon permissive. Si l’analyse ne peut pas aboutir — la fenêtre de 30 minutes expire, l’analyse échoue, ou AI-Native SCA est désactivé — la règle ne signale aucune violation au lieu de faire échouer votre build. Un pipeline n’est bloqué que sur une accessibilité réellement déterminée par Corgea, jamais sur une analyse manquante.
corgea scan échoue de façon restrictive à l’expiration de son propre délai. Corgea CLI 1.13.0 et versions ultérieures autorisent 35 minutes, ce qui dépasse confortablement la fenêtre d’analyse de 30 minutes. Sur une CLI antérieure, le délai est de 15 minutes et peut expirer alors que Corgea analyse encore, faisant échouer le pipeline. Mettez à jour la CLI ou augmentez le délai avec CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS :

​
Exemples

Type de règle : Code VulnerabilityCréez une règle ciblant CWE-326 (Inadequate Encryption Strength) et CWE-327 (Use of a Broken or Risky Cryptographic Algorithm), avec une urgence « Critical », afin d’empêcher l’utilisation d’un chiffrement faible.
Type de règle : Code VulnerabilitySélectionnez Code Quality en tant que type de problème, puis établissez une règle pour CWE-398 (Indicator of Poor Code Quality) et CWE-477 (Use of Obsolete Functions) avec une urgence « Medium » pour maintenir les normes de code.
Type de règle : Dependency VulnerabilityCréez une règle avec les niveaux d’urgence « Critical » et « High » pour bloquer automatiquement toute pull request qui introduit des dépendances présentant des vulnérabilités critiques ou de sévérité élevée. Vous protégez ainsi votre chaîne d’approvisionnement contre les paquets vulnérables connus.
Type de règle : Dependency VulnerabilityCréez une règle qui filtre par CVSS comme 7.0 à 10.0, pour bloquer les pull requests introduisant des dépendances vulnérables dans cette plage de score.
Type de règle : Dependency Vulnerability — S’applique à : CISélectionnez les niveaux d’urgence « Critical » et « High », puis sélectionnez Reachable sous Accessibilité. La règle ne fait échouer un pipeline que lorsqu’une vulnérabilité critique ou élevée est accessible depuis le code de votre application, afin que les paquets inutilisés ou inaccessibles n’interrompent pas les développeurs. C’est une bonne première règle d’accessibilité, car elle restreint une règle de sévérité existante au lieu d’élargir ce qui bloque.
Type de règle : Dependency Vulnerability — S’applique à : CISélectionnez Unused Dependency sous Accessibilité, seule, sans filtre de sévérité ni de CVSS. La règle fait échouer un pipeline qui introduit des paquets vulnérables que rien n’utilise dans la base de code, incitant les développeurs à supprimer la dépendance plutôt qu’à la mettre à jour.
Type de règle : License ComplianceSélectionnez la famille Copyleft pour bloquer les dépendances dont les licences signalées appartiennent à cette famille. Ajoutez des identifiants SPDX spécifiques lorsque votre politique nécessite une liste de refus plus étroite.

​
Bonnes pratiques

Conseils d’implémentation

  • Commencez par les règles essentielles et développez progressivement
  • Pour les règles Dependency Vulnerability, commencez par la sévérité Critical uniquement ou par une plage CVSS ciblée, puis élargissez les critères à mesure que votre équipe s’adapte
  • Sur les règles CI, ajoutez un filtre d’accessibilité Reachable à une règle de sévérité existante pour réduire le bruit sans affaiblir la couverture des vulnérabilités réellement exploitables
  • Pour les règles Code Vulnerability, concentrez-vous d’abord sur les CWE les plus impactants (par exemple, failles d’injection, problèmes d’authentification)
  • Revues régulières et mises à jour
  • Documentation claire et formation d’équipe
  • Encourager les retours et la collaboration
  • Utilisation stratégique des niveaux d’urgence
  • Considérez les tags de projet lorsque la même règle doit couvrir un groupe de projets liés

​
Dépannage

Si une pull request est bloquée de façon inattendue, vérifiez d’abord les règles actives et leurs configurations.
  • Comportement de blocage inattendu
  • Problèmes de ciblage par règles
  • Problèmes liés à la portée du projet
  • Vérifier les configurations des règles
  • Vérifier le ciblage des CWE
  • Confirmer les paramètres du projet
  • Contactez le support si besoin