Identifier une vulnérabilité est l'étape la plus facile. La mission de la sécurité consiste à faire fusionner et déployer la correction ; pour les dépendances vulnérables, Coroid génère elle-même la mise à jour pull request, que votre équipe examine puis fusionne.
Lorsque Coroid en ouvre une...
Avec Corriger les dépendances vulnérables activé, toute dépendance dont la gravité atteint ou dépasse le seuil défini (élevé par défaut) déclenche une tâche de correction dans son projet :
- Une tâche par package et par pull request, couvrant toutes les alertes qui l'affectent.
- Les anomalies critiques en premier, puis celles de niveau élevé.
- Au maximum 5 demandes de fusion de correction ouvertes par projet par défaut (jusqu'à 50). La prochaine correction attend son tour.
Les propriétaires et administrateurs peuvent également choisir Corriger sur toute alerte de dépendance ouverte dont l'avis est public. Si aucune version corrigée n'est encore disponible, Corriger propose une tâche de mitigation : supprimer ou remplacer le package, verrouiller une branche patchée, ou protéger l'appel vulnérable.
Les mises à jour automatiques fonctionnent aujourd'hui pour les projets npm. Pour les autres écosystèmes, l'alerte indique « Aucune correction automatique pour cet écosystème pour l'instant » ; Corriger propose alors la tâche de mitigation.
Ce que cela coûte
Les tâches de Corriger utilisent un modèle AI, donc elles consomment des heures d'agent comme tout autre travail. Elles s'exécutent dans le cadre du mandat intégré Corrections de sécurité , que chaque organisation possède :
- Portée: mises à jour de dépendances et mitigations de sécurité, rien d'autre.
- Budget: uniquement des heures d'agent, soit un quart des heures d'agent de votre abonnement par mois par défaut. Les propriétaires modifient ces heures, ainsi que leur périodicité (hebdomadaire ou mensuelle) via Sécurité → Paramètres → Corriger les dépendances vulnérables.
- Pas d'expiration de l'examen. Il s'agit d'une configuration par défaut permanente, sans besoin de renouvellement.
- Priorité: les corrections de sécurité ont la priorité sur les autres travaux initiés par l'utilisateur.
Désactiver Corriger les dépendances vulnérables au niveau par défaut de l'organisation suspend le mandat. Ce mandat figure aux côtés des autres dans Contrôle qualité → Mandats.
Lorsqu'une organisation ayant déjà des dépôtiers connectés souscrit à Sécurité, ses propriétaires reçoivent une notification dans la cloche : « Les corrections de sécurité démarreront dans sept jours ». Le travail de Corriger commence sept jours après cette notification, ce qui permet à un propriétaire de le désactiver avant la première intervention de pull request. Les nouvelles organisations démarrent immédiatement.
Pourquoi une correction peut-elle être retardée ?
La section de correction de l'alerte indique ce qui cause le retard. Les raisons courantes sont :
- la limite d'pull request ouverte pour le projet est atteinte ;
- le budget du mandat ou les heures d'agent de l'abonnement sont épuisées (la détection continue néanmoins) ;
- le travail de l'agent est en pause dans Mission Control, ou aucune plage horaire n'est disponible ;
- la période de notification de sept jours n'est pas terminée ;
- aucune correction compatible n'a été publiée, ou l'écosystème ne dispose pas de correction automatique ;
- Corriger les dépendances vulnérables est désactivé.
Comment le choix de la mise à jour est-il effectué ?
Pour chaque emplacement où un package vulnérable est installé, Coroid sélectionne la version la plus récente supérieure à celle installée qui corrige toutes les alertes concernées, tout en respectant la plage déclarée et la version majeure autorisée. Elle ne fait jamais de downgrade. Un espace de travail nécessitant une version majeure et un autre en nécessitant une autre obtiennent chacun leur propre version patchée au sein du même pull request. Un package transitif suit la mise à jour de son parent ou l'override du gestionnaire de packages. Tout changement majeur ou regroupement vers une seule version est accompagné d'une justification dans pull request. Si aucune mise à jour unique ne permet de tout corriger, la demande de fusion traite ce qui peut l'être et liste le reste comme non corrigé.
Ce que contient pull request
- Les alertes qu'elle corrige, avec leur niveau de gravité.
- L'inventaire des packages avant et après le changement, montrant la version vulnérable supprimée.
- Les vérifications de votre projet : si le graphe de livraison du projet comporte des vérifications pouvant s'exécuter, elles doivent donner un résultat positif sur la modification poussée avant que Coroid n'ouvre pull request ; sinon, la tâche se termine avec sa raison. Si aucune vérification n'est configurée pour le projet, pull request s'ouvre quand même et indique que Coroid n'a exécuté aucune vérification de projet, que votre propre CI du dépôt s'exécute sur pull request, et où configurer les vérifications dans Contrôle qualité.
- Les raisons de tout changement majeur ou de plage.
- Toute alerte qu'elle n'a pas pu corriger, listée comme non corrigée.
Cela se termine par : « Les équipes reviennent sur les modifications et les fusionnent. Le statut de déploiement n'est déterminé qu'après une analyse de la version déployée. » La constatation est ensuite intégrée au code lors du prochain inventaire complet, et corrigée pour chaque environnement après analyse de la version exécutée dans cet environnement. Voir Les constatations et leur cycle de vie.
Constatations sur le code
Pour une constatation sur le code, Corriger crée une tâche pour la corriger dans son projet. Les propriétaires et les administrateurs peuvent l'utiliser sur toute constatation de code ouverte. Cette tâche demande au développeur de décrire la correction — et non l'attaque — dans les messages de validation ainsi que dans pull request, et d'ajouter un test de régression. Elle suit les mêmes règles que les autres tâches et consomme des heures d'agent.
Dans un dépôt public, ou dans un dépôt dont la visibilité ne peut pas être confirmée par Coroid, aucune correction pour une constatation non encore rendue publique n'y est commise. Coroid conserve alors la modification préparée en privé afin qu'un propriétaire ou un administrateur puisse la publier. Voir Divulgation.
Secrets divulgués
Une identifiant divulgué est corrigé en le renouvelant ; cette action ne peut pas être effectuée automatiquement par Coroid. La correction d'une constatation liée à un secret génère plutôt une tâche de liste de contrôle. Voir Secrets divulgués.