Le fait d’avoir une dépendance vulnérable ne signifie pas toujours que votre application appelle la fonction affectée. Reachability analysis ajoute un verdict à chaque Dependabot alerte pour vous aider à hiérarchiser les correctifs en fonction de la façon dont votre code utilise la dépendance.
Remarque
Reachability analysis pour Dependabot alerts est en préversion publique et susceptible de changer.
Comment fonctionne reachability analysis
Reachability analysis analyse votre open source Dependabot alerts pour déterminer si votre application peut appeler les fonctions vulnérables. Il utilise l’analyse CodeQL statique et les données organisées identifiant les fonctions affectées pour rechercher des chemins d’appel de votre code vers ces fonctions.
Chaque alerte analysée Dependabot reçoit un verdict qui vous aide à décider de sa priorité. Lorsqu’elle est disponible, la preuve du chemin d’appel montre comment votre code peut atteindre une fonction vulnérable, afin de comprendre pourquoi une alerte est importante pour votre application.
Exigences et écosystèmes pris en charge
Reachability analysis prend en charge les dépôts JavaScript qui utilisent npm, pnpm ou Yarn, ainsi que les dépôts TypeScript. Votre dépôt doit avoir un fichier de verrouillage, tel que package-lock.json, pnpm-lock.yaml ou yarn.lock.
Dependabot alerts doit être activé pour permettre à reachability analysis de fonctionner.
L’analyse s’exécute sur les exécuteurs hébergés sur GitHub. Les exécuteurs auto-hébergés ne sont pas pris en charge.
Comprendre les résultats de joignabilité
Utilisez l’atteignabilité en même temps que la gravité, les scores EPSS (Exploit Prediction Scoring System), l’étendue des dépendances et la relation de dépendance pour déterminer les alertes à traiter en premier.
| Verdict | Signification | Réponse recommandée |
|---|---|---|
| Accessible | L’analyse a trouvé au moins un chemin d’appel du code de votre référentiel à une fonction vulnérable. | Hiérarchiser la remédiation et passer en revue les éléments de preuve du chemin d’appel. |
| Potentiellement accessible | L’analyse n’a pas pu exclure un appel à une fonction vulnérable. Cette incertitude n’est pas due à un écosystème non pris en charge ou à une analyse défaillante. Dans les dépôts avec plusieurs manifestes, les appels trouvés uniquement en dehors du répertoire d’un manifeste sont considérés comme potentiellement atteignables. | Hiérarchisez la correction en parallèle des alertes atteignables. |
| Injoignable | L’analyse s’est terminée et n’a pas trouvé d’appel depuis le code de votre application à une fonction vulnérable. | Donnez à l’alerte une priorité inférieure, mais ne l’écartez pas ou ne la fermez pas uniquement en raison de ce verdict. |
| Joignabilité indisponible | L’analyse n’a pas pu fournir de verdict, par exemple parce que l’alerte concerne un écosystème non pris en charge ou l’analyse a échoué ou expiré. | Triez l’alerte à l’aide des autres signaux de hiérarchisation. |
Utiliser la joignabilité pour hiérarchiser les alertes, et non pour les fermer
Reachability analysis ajoute des informations aux alertes ouvertes existantes pour vous aider à hiérarchiser la correction. Il ne trouve pas de nouvelles vulnérabilités et ne ferme ni n’ignore automatiquement les alertes.
Un verdict est une évaluation ponctuelle dans le temps. Vous ne devez pas fermer ou ignorer une alerte uniquement en fonction de son verdict d’atteignabilité ; alors qu’une fonction peut ne pas être atteignable à partir de votre code aujourd’hui, les modifications de code ou les mises à jour apportées à un avis de sécurité peuvent modifier le résultat d’une analyse ultérieure.
L’atteignabilité n’implique pas l’exploitabilité
Une fonction accessible n’est pas nécessairement exploitable. L’atteignabilité indique qu’un chemin d’appel existe, et non qu’un attaquant peut l’utiliser pour exploiter la vulnérabilité.
De même, un verdict « inaccessible » n’est pas une garantie qu’une dépendance est sûre. Continuez à passer en revue ces alertes et à maintenir les dépendances à jour.
Preuve de la trace d’appel
Pour les alertes accessibles, la preuve de chemin d’appel montre comment un appel de votre code peut mener à une fonction vulnérable. Utilisez cette preuve pour comprendre où votre application utilise la dépendance affectée et planifier la remédiation.
Une alerte peut afficher jusqu’à cinq exemples de chemins. Ces exemples ne sont pas une liste exhaustive de chaque chemin d’accès d’appel possible.
Comprendre quand les résultats sont mis à jour
Activer reachability analysis démarre une analyse initiale des alertes ouvertes de votre référentiel. Après cela, les analyses s’exécutent une fois toutes les 24 heures pendant que le dépôt a des alertes ouvertes. Chaque analyse couvre toutes les alertes ouvertes.
L’envoi de modifications de code ne déclenche pas d’analyse. Une fois que vous avez modifié votre code, le verdict ne reflète pas ces modifications tant qu’une analyse ultérieure n’est pas terminée.
Pendant préversion publique, vous ne pouvez pas planifier ou déclencher des analyses à la demande.
La durée de l’analyse dépend de la taille du référentiel et des dépendances du référentiel. Les analyses peuvent s’effectuer en quelques minutes, mais les analyses plus importantes prennent plus de temps. Pendant le préversion publique, les scans ont une limite de temps de trois heures.
Facturation et utilisation pendant préversion publique
Reachability analysis est gratuit pendant le préversion publique. Ses analyses ne consomment pas de minutes facturées GitHub Actions .
Limitations connues
Reachability analysisprésente les limitations suivantes pendant le préversion publique :
- Prise en charge de l’écosystème : les alertes en dehors des écosystèmes JavaScript et TypeScript pris en charge ne sont pas prises en charge.
- Dépôts volumineux et monorepos : certains référentiels peuvent atteindre la limite d’analyse de trois heures ou rencontrer des limites de ressources, ce qui laisse les résultats indisponibles.
Utilisation de verdicts via l’API REST
L’API Dependabot alerts REST expose les verdicts pour reachability analysis. Vous pouvez récupérer des verdicts via les endpoints d’alerte du dépôt, de l’organisation et de l’entreprise. Consultez « Points de terminaison d’API REST pour Dependabot alerts ».
Étapes suivantes
Pour activer reachability analysis pour votre dépôt, consultez Configuration de l’analyse d’atteignabilité pour les alertes Dependabot.