Contrôles de pull request

Contrôles PR GitHub et External Status Checks MR GitLab CodeCleared : vulnérabilités, secrets, licences, advisor, SAST.

Objectif

Les contrôles PR / MR publient un ou plusieurs résultats de statut fournisseur sur chaque pull ou merge request afin que les relecteurs voient si les changements proposés introduisent des violations de sécurité ou de politique avant fusion.

Pour qui

Les propriétaires ou admins d’organisation activent les contrôles. Les mainteneurs de dépôt doivent disposer de la permission fournisseur correspondante : Checks de l’App GitHub, ou External Status Checks GitLab (Premium/Ultimate).

Prérequis

Dépôt connecté via l’App GitHub ou OAuth GitLab.com (Paramètres → Sources)
Permission de statut accordée (Checks GitHub, ou External Status Checks GitLab sur Premium/Ultimate)
Contrôles PR activés au niveau organisation ou dépôt (Settings → Scan defaults, ou Scan triggers du dépôt)
Limites de plan (Free : 1 dépôt ; Starter et plus : illimité)
SAST : add-on SAST et unité de projet sast sur le dépôt
Secrets : unité de projet secrets sur le dépôt
Vulnérabilités, licences, dependency advisor : unités de projet SCA (lockfiles reconnus)

Fonctionnement

Ouvrez ou mettez à jour une pull request (GitHub) ou merge request (GitLab) sur une branche surveillée (scanOnPr / scanOnPrUpdate doivent être activés).
CodeCleared met en file un workflow distinct par type de contrôle activé.
Chaque contrôle publie réussite ou échec sur la PR / MR chez le fournisseur.
Analysez l’échec dans CodeCleared (détail du contrôle PR), puis poussez un correctif ou une exception documentée le cas échéant.

Types de contrôles

Type	Échoue quand	Modèle d’évaluation
Vulnérabilités	Constats nouveaux ou présents avec sévérité ≥ `prCheckSeverityThreshold` (selon le mode)	Seuil de sévérité configurable
Secrets	Constats nouveaux ou présents avec sévérité ≥ `prCheckSeverityThreshold`	Seuil de sévérité configurable
Licences	Politique de licences non conforme pour le commit évalué	Politiques de licences de l’organisation
Dependency advisor	Politique de catégorie / dépendance non conforme	Politiques Dependency Advisor
SAST	Constats nouveaux ou présents avec sévérité ≥ `prCheckSeverityThreshold`	Seuil de sévérité configurable + add-on SAST

Les contrôles basés sur les politiques (licences, dependency advisor) utilisent les mêmes moteurs que les onglets produit et les portes de qualité. Les contrôles par sévérité (vulnérabilités, secrets, SAST) utilisent uniquement prCheckSeverityThreshold — ce ne sont pas les Quality Gates, et ils ne sont pas liés aux règles Quality Gates pour ces checks PR.

Seuil de sévérité (`prCheckSeverityThreshold`)

Valeurs : critical | high | medium | low. Défaut : high.

Le check échoue dès qu’au moins un constat évalué a une sévérité supérieure ou égale au seuil (ex. high échoue sur critical et high ; critical n’échoue que sur critical).

Organisation : Paramètres → Scan defaults
Surcharge dépôt : Scan triggers du dépôt (optionnel ; absent = héritage du défaut org)
Aussi configurable à l’Onboarding et à l’Import de dépôt (seuil PR uniquement à l’import)

Ce champ est distinct de apiGateSeverityThreshold (attente API publique / CLI / MCP). Voir API scans.

Mode diff vs full

Le mode par défaut est diff (métadonnées organisation ou dépôt) :

Diff : compare les commits de base et de tête. Pour vulnérabilités, secrets, SAST et dependency advisor, seules les nouvelles violations font échouer le check.
Full : évalue uniquement le commit de tête (tous les constats correspondants peuvent faire échouer les checks par sévérité).

Priorité de configuration

À l’import, les cinq types de contrôles PR sont activés par défaut sauf Scan defaults organisation contraires.

Par dépôt :

Si le dépôt a au moins un type activé, les toggles du dépôt s’appliquent à tous les types.
Si aucun type n’est activé au dépôt (vide ou tout désactivé), les Scan defaults de l’organisation s’appliquent.

Configurez les toggles et la surcharge optionnelle de sévérité PR dans Scan triggers du dépôt ou les Scan defaults de l’organisation.

Contrôles de merge request GitLab

À l’import GitLab.com, CodeCleared enregistre les webhooks du projet et tente de créer les cinq External Status Checks (mêmes types que GitHub). Les External Status Checks exigent GitLab Premium ou Ultimate ; sans ce plan, l’import et les scans fonctionnent, mais les status checks MR ne sont pas créés. GitLab auto-hébergé n’est pas pris en charge. Voir Connecter GitLab.

Scénarios et cas limites

Aucun check n’apparaît (GitHub) : permission Checks manquante, contrôles désactivés, scanOnPr désactivé, ou dépôt hors périmètre de l’App.

Aucun check n’apparaît (GitLab) : External Status Checks non enregistrés (souvent plan Free/Standard), contrôles désactivés, scanOnPr désactivé, ou accès OAuth insuffisant.

Seulement certains checks : chaque type est indépendant ; vérifiez le toggle, l’add-on (SAST) ou l’unité de projet (secrets, SAST).

Le check échoue mais le tableau de bord semble correct : commits, branches ou project units différents ; en mode diff, seuls les constats nouveaux font échouer les checks par sévérité.

PR depuis un fork : l’accès App et les secrets pour les workflows de fork peuvent différer.

Politique changée après ouverture : poussez un nouveau commit pour réévaluer la politique courante.

SAST échoue avec « no SAST project unit » : activez le SAST sur le dépôt et vérifiez l’unité de projet SAST.

Limites

Un check en échec est un signal de gouvernance, pas une preuve que la production est compromise. Sur Free, un seul dépôt peut utiliser les contrôles PR. Les contrôles consomment des crédits selon les scans sous-jacents (branche tête facturée en mode diff ; scan base non facturé lorsque configuré ainsi).

Modifier les seuils Quality Gates d’un package ne change pas la sévérité d’échec PR pour vulns / secrets / SAST. Utilisez prCheckSeverityThreshold.

Erreurs courantes

Désactiver tous les toggles au niveau dépôt en s’attendant aux defaults organisation — si le dépôt désactive explicitement chaque type, aucun check ne part.
S’attendre à ce que les Quality Gates pilotent le pass/fail PR vulns / secrets / SAST — ce n’est pas le cas ; réglez prCheckSeverityThreshold.
S’attendre à ce qu’une allowance licence relance immédiatement les contrôles PR — voir Exceptions.
Ignorer la permission Checks alors que l’App GitHub a déjà accès au contenu.
Attendre des status checks MR GitLab sans Premium/Ultimate.
Activer le contrôle SAST sans add-on ou sans unité de projet SAST.