Scanner de vulnérabilités des dépendances OSV

Chargez un manifeste ou un fichier de verrouillage : les noms, versions et écosystèmes qu'il contient sont vérifiés auprès d'OSV, et le tableau affiche les avis renvoyés avec leur gravité et la version corrigée. Un fichier de verrouillage donne les versions résolues ; une plage de manifeste est interrogée à sa version déclarée la plus basse.

·

    Comment vérifier un manifeste ou un fichier de verrouillage auprès d’OSV

    Chargez un manifeste ou un fichier de verrouillage puis lancez Analyser les dépendances : les noms, versions et écosystèmes lus sont interrogés auprès de l'API OSV, et le tableau affiche les avis renvoyés avec leur gravité et la version corrigée. L'analyse se fait dans la page ; seuls les noms, versions et écosystèmes sont envoyés.

    Mesuré ici : un package.json de huit dépendances a renvoyé 13 constats, requirements.txt 107 constats pour cinq paquets, et un manifeste avec express 5.1.0, minimist 1.2.8 et chalk 5.3.0 aucun.

    1. Déposez un manifeste ou un fichier de verrouillage, ou collez son texte : package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, pom.xml, un bom.json CycloneDX, ou des lignes comme « npm lodash 4.17.15 ».
    2. Lancez Analyser les dépendances. La ligne d'état indique la progression pendant l'interrogation de l'API OSV.
    3. Lisez les indicateurs : paquets vérifiés, constats renvoyés et écosystèmes interrogés.
    4. Lisez la note sous les indicateurs quand elle apparaît : combien de plages ont été vérifiées à leur version déclarée la plus basse, combien d'entrées n'indiquaient aucune version et si la limite de 100 paquets en a écarté.
    5. Effacez avant le fichier suivant : la zone de texte, le tableau et les indicateurs sont vidés.

    Quels fichiers sont lus, ce qui est interrogé et ce que signifie un résultat vide

    Quels fichiers sont lus

    Pour npm : package.json (dependencies et devDependencies) et les trois formats de verrouillage package-lock v1/v2/v3, yarn.lock et pnpm-lock.yaml. Pour PyPI : requirements.txt. Pour Maven : pom.xml, intervalles compris. Un bom.json CycloneDX couvre npm, PyPI, Maven, NuGet, Go et crates.io. Des lignes comme « npm lodash 4.17.15 » sont lues aussi. Le fichier de verrouillage est la meilleure entrée : il contient la version réellement installée, pas la contrainte.

    Une entrée inutilisable répond par une phrase au lieu d'une exception : un texte brut, un JSON mal formé et des lignes reliées par @ ont affiché « Aucune dépendance versionnée n'a été trouvée » et le tableau est resté vide.

    Ce qui est interrogé

    Les plages sont interrogées à leur version déclarée la plus basse : Django>=2.2,<3.0 en 2.2, l'intervalle Maven [4.3.0,4.3.30] en 4.3.0. La colonne Version affiche le texte du manifeste (« >=2.2 », « [4.3.0,4.3.30] ») et non la valeur interrogée, pour comparer avec le fichier.

    Les entrées sans version de registre sont écartées et comptées dans la note : URL git avec étiquette, file:, workspace:*, latest, *, références ${property} d’un pom et un composant CycloneDX sans purl. Cent paquets au maximum sont interrogés ; un manifeste de 120 entrées en a envoyé exactement 100 et l'a signalé sous les indicateurs.

    Ce que signifient les résultats

    Chaque ligne est un avis : paquet, version vérifiée, identifiant et résumé, gravité et version corrigée. Les détails n'étaient demandés que pour 40 avis, si bien que les lignes suivantes restaient en Gravité Unknown et Corrigé dans « — » ; ils sont maintenant tous demandés, et un manifeste de 83 avis a renvoyé 83 lignes, chacune avec sa gravité et avec la version corrigée qu’OSV indique pour ce paquet.

    L'absence d'avis ne prouve pas que le paquet est sûr : un avis publié après cette analyse n'apparaîtra pas, et une plage interrogée à sa version la plus basse laisse le reste de la plage non vérifié. Si l'API OSV est injoignable, la page le dit au lieu d'afficher un résultat vide ; un HTTP 503 est signalé comme tel. Les avis sont demandés six à la fois avec une limite de 20 secondes chacun : une connexion qui se bloque ne laisse donc pas l’analyse tourner, les lignes concernées reviennent en Gravité Unknown.

    Outils récents :