Sécurité fonctionne via l'application GitHub de Coroid. Cette page liste ce dont l'application a besoin pour Sécurité, ce que Coroid Security le rapport du contrôle indique, comment faire en sorte que GitHub l'exige, et comment les alertes de sécurité propres à GitHub apparaissent dans Sécurité.
Autorisations
Sécurité utilise les autorisations que l'application possède déjà pour vos dépôts : la lecture du code et des demandes de fusion, ainsi que l'écriture de contrôles. Celles-ci sont optionnelles, et chacune ajoute une fonctionnalité :
| Autorisation | Ce qu'elle ajoute | Sans elle |
|---|---|---|
| Files d'attente de fusion : en lecture seule, avec l'événement de groupe de fusion | Coroid Security sur les commits de la file d'attente de fusion | Les files d'attente de fusion n'obtiennent pas de Coroid Security résultat |
| Alertes Dependabot : en lecture seule, avec son événement | Importe les alertes Dependabot | Non importé |
| Alertes d'analyse de code : en lecture seule, avec son événement | Importe les alertes d'analyse de code GitHub | Non importé |
| Alertes d'analyse de secrets : en lecture seule, avec son événement | Importe les alertes d'analyse de secrets GitHub, sans les valeurs des secrets | Non importé |
Lorsque l'application demande une nouvelle autorisation, GitHub sollicite l'acceptation par l'administrateur de votre organisation pour votre installation. En attendant, Sécurité → Aperçu indique quels dépôts en manquent, avec un lien vers l'installation sur GitHub.
Coroid lit également si chaque dépôt est public ou privé, à partir des événements de GitHub et en interrogeant GitHub, afin de déterminer ce qui peut y être publié. Voir Divulgation.
Le contrôle de sécurité Coroid
Coroid Security est un seul contrôle, avec un nom unique, qu'il s'exécute seul ou dans le graphe de livraison du projet sous Contrôle qualité, afin qu'un dépôt puisse l'exiger une fois. Il signale les protections qui vérifient chaque modification : les dépendances vulnérables et les secrets fuites. Le pire des deux résultats prévaut. Les rapports d'analyse de code passent par les contrôles de Contrôle qualité, et la révision de sécurité via le contrôle de Révision Coroid.
Il s'exécute sur les dépôts GitHub connectés via l'application :
- lorsqu'une demande de fusion pull request est ouverte, rouverte, mise à jour ou marquée prête pour révision ;
- sur chaque commit de la file d'attente de fusion, avec l'autorisation des files d'attente de fusion ;
- lorsqu'une personne le relance sur GitHub.
Il apparaît comme en cours d'exécution dès l'arrivée de l'événement. Son détail ouvre le lien vers le projet dans Sécurité.
Ce qu'il signale
| État | Appliqué | Observation uniquement |
|---|---|---|
| Couverture complète de la modification, rien au seuil ou au-dessus | Succès | Succès |
| Une occurrence au seuil ou au-dessus | Échec | Neutre, avec son nom |
| L'analyse a échoué ou n'a pas pu s'exécuter, un fichier touché par la modification n'est que partiellement couvert, ou la configuration n'a pas pu être lue | Échec, en indiquant la raison et comment le relancer | Neutre, en indiquant la raison |
| Aucun résultat en 10 minutes | Échec, « délai dépassé » | Neutre |
| Toutes les protections désactivées pour le projet | Neutre | Neutre |
Il n'est jamais « ignoré » : GitHub considère qu'un contrôle requis ignoré est validé, donc une protection appliquée qui n'a pas été exécutée serait considérée comme validée. Un contrôle requis obtient toujours l'un des résultats ci-dessus, donc une file d'attente de fusion n'attend jamais indéfiniment.
Le contrôle ne compte que ce que la modification introduit, pas les occurrences déjà présentes sur la branche de base. Son texte ne mentionne jamais une occurrence qui n'est pas publique ; il indique combien ont été trouvées, à quel seuil, et que les détails se trouvent sur Coroid.
Exiger le contrôle de sécurité Coroid
Appliquer une protection fait échouer le contrôle. GitHub bloque la fusion uniquement si le dépôt exige le contrôle :
- Protection de branche: dans Paramètres → Branches du dépôt, modifiez la règle pour votre branche par défaut, activez Exiger que les contrôles d'état soient validés avant la fusion, et ajoutez
Coroid Security. - Règles: dans Paramètres → Règles → Règles, ajoutez Exiger que les contrôles d'état soient validés à la règle pour votre branche par défaut, ajoutez
Coroid Security, et choisissez l'application GitHub de Coroid comme source. - Files d'attente de fusion: exigez le contrôle dans la même règle. L'application a besoin de l'autorisation des files d'attente de fusion pour que le contrôle s'exécute sur les commits de la file d'attente de fusion.
Activez cette option une fois que les protections que vous souhaitez appliquer sont effectivement en vigueur. Une vérification requise qui ne fait qu'observer reste toujours valable.
Alertes de sécurité GitHub
Avec Alertes de sécurité GitHub Après avoir activé cette option dans Sécurité → Paramètres et configuré les autorisations requises ci-dessus, la fonctionnalité Sécurité importe les alertes de Dependabot, de l'analyse de code et du balayage de secrets en tant qu'observations des mêmes résultats que ceux générés par les propres analyses de Coroid. De nouvelles alertes arrivent au fur et à mesure que GitHub les envoie, et Coroid relit les alertes de chaque dépôt une fois par jour.
- Importées, non confirmées. Une alerte que les propres analyses de Coroid n'ont pas encore confirmée affiche le message « Importée depuis GitHub, non confirmée pour l'instant ». Elle est répertoriée et prise en compte dans le compteur, sans toutefois déclencher de notification ni bloquer quoi que ce soit tant que l'analyse de Coroid ne l'aura pas confirmée.
- Les sources divergent. Lorsque GitHub et Coroid signalent un résultat différemment, le résultat indique cette divergence et affiche l'état de chaque source : présent, absent, ignoré ou illisible.
- Chaque source clôture les alertes à sa manière. Une alerte Dependabot est considérée comme résolue sur GitHub lorsque la branche par défaut ne contient plus la version vulnérable. Une alerte d'analyse de code est considérée comme résolue lorsque l'analyse de la branche par défaut ne la signale plus. Une alerte de balayage de secrets reste ouverte jusqu'à ce qu'un utilisateur la résolve sur GitHub ; ainsi, le simple merge d'une correction ne la ferme pas.
- Autorisation perdue. Si l'application perd une autorisation ou si GitHub désactive une fonctionnalité, les résultats signalés uniquement par cette source affichent l'état « statut inconnu depuis » à partir de ce moment, et aucune alerte n'est clôturée.
L'Aperçu indique, par dépôt et par source, si les alertes ont été lues, si l'autorisation est manquante, si la fonctionnalité est désactivée sur GitHub, ou si le dépôt n'a pas pu être atteint.