Security conserve l'inventaire de chaque paquet installé dans un projet et le compare aux avis publiés, afin de détecter une version vulnérable dès son arrivée dans un pull request, et à nouveau lorsqu'un nouvel avis concerne une version déjà utilisée.
L'inventaire
À chaque nouvelle tête de la branche par défaut et au moins une fois par jour, Coroid lit les fichiers de verrouillage du projet avec OSV-Scanner, verrouillé sur une version précise et comparé à sa somme de contrôle publiée. Le scan ne prend en compte que les fichiers de dépendances, une configuration générée par Coroid, sans accès réseau ni identifiants. Les osv-scanner.toml d'un dépôt n'ont aucun effet.
Sécurité → Dépendances affiche l'inventaire de chaque projet : les paquets et leurs versions installées, le manifeste qui les déclare, ceux qui sont vulnérables, la couverture de chaque fichier et la date de dernière lecture des données d'avis. Exporter CycloneDX télécharge l'inventaire sous forme de fichier CycloneDX 1.5. Il liste uniquement les vulnérabilités pour les résultats déjà publics. Voir Divulgation.
Ce que Coroid lit intégralement
La couverture est calculée par fichier de verrouillage, non par dépôt. Dans un monorepo, chaque fichier de verrouillage constitue un groupe distinct avec sa propre couverture ; ainsi, les résultats d'un fichier de verrouillage complet restent valables même si un autre manifeste est partiel.
| Fichier | Écosystème | Versions exactes | Dépendances transitives complètes | Couverture |
|---|---|---|---|---|
package-lock.json | npm | Oui | Oui | Complète |
npm-shrinkwrap.json | npm | Oui | Oui | Complète |
pnpm-lock.yaml | npm | Oui | Oui | Complète |
yarn.lock | npm | Oui | Oui | Complet |
requirements.txt | PyPI | Oui | Non | Partiel |
go.mod | Go | Oui | Non | Partiel |
Ce tableau est généré à partir des jeux de données de test propres à Coroid, exécutés via le scanner ; il ne change donc que lorsque les tests sont modifiés.
- Les espaces de travail npm, pnpm et Yarn: un espace de travail
package.jsonsans son propre fichier de verrouillage est couvert par le fichier de verrouillage racine. Unpackage.jsonqui ne correspond plus à son fichier de verrouillage est considéré comme partiel jusqu'à ce que le fichier de verrouillage soit régénéré. - Fichiers de verrouillage npm doivent être en version 2 ou 3. Les entrées pnpm et Yarn provenant de Git, d'un fichier local ou d'une mise à jour sont considérées comme partiels.
requirements.txtcouvre uniquement les versions verrouillées par==.- Autres fichiers de dépendances (
package.jsonsans fichier de verrouillage,pyproject.toml,poetry.lock,Pipfile,Cargo.lock,Gemfile.lock,pom.xml, Gradle, Composer, NuGet et autres) sont détectés et affichés comme partiels, avec mention du nom du fichier, afin qu'un projet ne soit jamais considéré comme couvert s'il ne l'est pas.
Avis de sécurité
Coroid lit les avis de sécurité provenant de OSV, qui contient également les avis de sécurité de GitHub, pour chaque écosystème utilisé par vos projets. Chaque heure, il lit les nouveautés ou modifications apportées depuis la dernière lecture, et une fois par jour, il lit l'ensemble des données. Le rapprochement s'effectue à partir des inventaires stockés, ce qui évite tout accès nécessaire à votre dépôt.
L'objectif de Coroid est de rapprocher 95 % des nouveaux avis de sécurité avec chaque inventaire dans les 60 minutes suivant leur apparition dans les données d'avis qu'il lit, et il mesure le temps nécessaire à chaque rapprochement. Il ne peut pas garantir un délai à partir de la divulgation initiale de la vulnérabilité : cela dépend du moment où l'avis de sécurité est publié.
Si les données des avis de sécurité accusent plus de 90 minutes de retard ou si leur dernière lecture a échoué, l'onglet Aperçu et la section Dépendances affichent le message « Le flux d'avis de sécurité est en retard depuis… », et aucune couverture de projet n'est considérée comme complète tant que ce problème persiste.
Lorsqu'un avis de sécurité est retiré, Coroid recalcule quelles recommandations restent applicables parmi les avis restants concernant la même vulnérabilité. Une alerte est classée comme « Plus applicable » uniquement lorsqu'aucune recommandation ne s'y rapporte, jamais comme « Corrigé ».
Sur les demandes de fusion
Le Coroid Security vérifie les fichiers de verrouillage modifiés par pull request, tant à leur état initial qu'à leur état final, et ne compte que les versions vulnérables introduites par cette modification :
- Observez: la vérification réussit ou renvoie un résultat neutre en indiquant ce qu'elle a détecté.
- Appliquer: Un changement qui introduit une version vulnérable connue au niveau ou au-dessus de la gravité choisie (par défaut « élevée ») fait échouer la vérification. Une couverture partielle du fichier de verrouillage concerné par le changement entraîne également l'échec de la vérification, en indiquant pourquoi et comment la relancer.
La même vérification est exécutée sur les demandes de fusion de correctifs et de fonctionnalités propres à Coroid avant leur ouverture. Pour connaître le comportement de cette vérification, comment l'exiger et comment la relancer, consultez Les autorisations GitHub et la vérification de Sécurité Coroid.
Notifications
Le premier inventaire complet d'un dépôt constitue une référence silencieuse : ses résultats apparaissent dans la section Sécurité sans notification aux utilisateurs. Par la suite, toute nouvelle dépendance critique détectée envoie une notification unique aux propriétaires et administrateurs de l'organisation : via la cloche, par e-mail si l'option est activée, et via Slack si ce dernier est connecté. Pour une alerte publique, la cloche précise le nom du paquet et de l'alerte ; pour tout élément non encore rendu public, elle indique simplement qu'une découverte critique nécessite une attention immédiate. Consultez Divulgation.