byteratio/security-sweep

Balayage de sécurité

Répondre bien à une question : ces projets sont-ils exposés à une vulnérabilité de dépendance qui compte vraiment maintenant ? « Compte vraiment maintenant » signifie soit cataloguée-et-atteignable, soit un incident actif dans la nature qui n'a pas encore entièrement propagé dans les bases de données d'audit.

La valeur ajoutée par rapport à un simple npm audit est la couche de recherche. Les bases de conseils sont en retard sur les divulgations, et les incidents de paquets malveillants sont souvent traités par dépublication (aucun avis consultable). Ce balayage associe donc les outils déterministes à une recherche en direct sur ce qui est activement exploité, et vérifie directement le lockfile pour ces noms — le signal fiable le plus rapide, qu'aucun outil d'audit ne fournit.

Lecture seule par défaut : ceci examine et rapporte. Proposer uniquement des correctifs; ne pas appliquer de mises à jour de version sans l'accord de l'utilisateur (elles peuvent casser les builds).

Quand l'utiliser

• « Examiner la sécurité » / « vérifier les dépendances vulnérables » / « exécuter un balayage de sécurité ».
• « Sommes-nous affectés par <une histoire nommée de CVE, GHSA ou compromission de package> ? » — l'utilisateur a lu quelque chose et veut connaître leur exposition.
• Une vérification périodique (composer avec la compétence schedule pour un balayage récurrent dans le cloud — voir la fin).

Étape 1 — Périmètre

Décider quoi balayer. Par défaut, le projet courant ; proposer un balayage multi-dépôt si la formulation de l'utilisateur est large (« nos projets », « tout », « la flotte »).

• Projet courant : le dépôt dans lequel vous êtes.
• Multi-dépôt : énumérer les dépôts frères à côté du dépôt courant — c'est-à-dire le parent de la racine git courante (généralement ~/projects/*/ ou ~/src/*/). Confirmer le répertoire avec l'utilisateur avant de le parcourir plutôt que de supposer ; une mauvaise estimation gaspille un long scan. Pour chaque dépôt, détecter les écosystèmes par manifeste (ci-dessous), balayer à tour de rôle, rapporter par projet.

Étape 2 — Détecter les écosystèmes et localiser les lockfiles

Par projet, un écosystème est présent si son lockfile est :

Écosystème	Manifeste / lockfile	Emplacement habituel
npm	package-lock.json	frontend/ ou racine du dépôt
Go	go.mod / go.sum	backend/ ou racine du dépôt
Python	poetry.lock, requirements.txt, uv.lock	racine du dépôt
Swift/SPM	Package.resolved	ios/ ou un .xcodeproj

Le lockfile — pas le manifeste — est ce que vous analysez : il épingle les versions transitives exactes réellement installées.

Étape 3 — Base déterministe (par écosystème)

Exécuter l'outillage propre à l'écosystème. Ceux-ci capturent tout ce qui se trouve déjà dans les bases de données de conseils. Privilégier les outils avec analyse d'atteignabilité (ils ne rapportent que les vulnérabilités que votre code peut réellement atteindre) lorsqu'ils sont disponibles.

• npm : cd <dir> && npm audit --omit=dev --audit-level=high (ce qui est livré aux utilisateurs) et un simple npm audit (tout, informatif). Pas d'atteignabilité — sur-rapporte ; pondérer les résultats de production.
• Go : govulncheck ./... — fait de l'analyse d'atteignabilité (ne signale que les vulnérabilités dans le code appelé) ; installer une fois avec go install golang.org/x/vuln/cmd/govulncheck@latest. L'étalon-or de ces outils.
• Python : pip-audit (ou pip-audit -r requirements.txt).
• Tout écosystème, ou quand un outil manque : osv-scanner contre le lockfile, exécuté via conteneur pour n'avoir rien à installer : <runtime> run --rm -v "$PWD:/src:ro" ghcr.io/google/osv-scanner:latest scan --lockfile=/src/<lockfile>. Base de données la plus large ; solution de repli pour Swift/SPM, qui dispose d'un outillage interne limité.

Capturer ce que chacun rapporte. Distinguer production/atteignable de dev/au moment de la construction — un niveau élevé dans un outil de construction qui n'est jamais livré n'est pas la même chose qu'un résultat dans une dépendance d'exécution.

Étape 4 — Rechercher le paysage actuel des menaces (la valeur ajoutée)

C'est ce qu'un simple audit ne peut pas faire. Utiliser WebSearch / WebFetch pour trouver ce qui est actuellement actif, puis rapporter les noms à l'étape 5.

• Incidents récents de la chaîne d'approvisionnement dans les écosystèmes du projet : rechercher les campagnes récentes de compromission et de malware npm/PyPI/Go ; consulter la base de données d'avis GitHub (github.com/advisories) et OSV (osv.dev) pour les entrées récemment publiées concernant les packages vus à l'étape 2.
• Si l'utilisateur a nommé un CVE / GHSA / incident spécifique, récupérer l'avis faisant autorité et extraire les noms exacts des packages affectés et les plages de versions — c'est ce que vous comparerez avec le lockfile.
• Privilégier les sources primaires (l'avis, le message du mainteneur, l'avis de sécurité du registre) plutôt que les titres des agrégateurs ; noter quand quelque chose est non confirmé.

Garder cela à jour : dater chaque affirmation et indiquer quelle était votre fenêtre de recherche (par exemple « incidents actifs divulgués dans les ~8 dernières semaines »).

Étape 5 — Recouper les noms avec le lockfile directement

Pour chaque package mis en évidence à l'étape 4, ne pas attendre l'outil d'audit — vérifier vous-même l'arbre figé. C'est l'étape d'indicateur avancé :

# npm
cd <dir> && npm ls <package>
grep -n '"<package>"' package-lock.json
# Go
grep -n '<module-path>' go.sum
# Python
grep -in '<package>' poetry.lock requirements.txt uv.lock 2>/dev/null
# Swift
grep -rn '<package>' --include=Package.resolved .

Puis comparer la version figée avec la plage affectée de l'avis. Trois résultats par nom : exposé (présent et dans la plage), clair (absent, ou présent mais en dehors de la plage), incertain (version transitive que vous n'avez pas pu résoudre complètement — creuser plus loin ou signaler).

Étape 6 — Rapport

Par projet, commencer par le verdict, puis les preuves :

• Exposé — package, version figée, avis/incident, s'il est atteignable en production, et une remédiation concrète (mise à jour ciblée de version ; jamais un npm audit fix aveugle). Si une version compromise a pu être installée, noter que son postinstall a peut-être déjà été exécuté — la principale raison pour laquelle une valeur par défaut d'ignore-scripts est importante.
• Clair — les menaces actives recherchées et vérifiées non présentes. Dire ce qui a été vérifié, pour que « clair » ait un sens.
• Incertain / non couvert — écosystèmes avec un outillage limité (Swift), transitives non résolues, ou recherche qui n'a pas pu confirmer une plage. Nommer l'écart plutôt que d'impliquer une couverture complète.

Ne pas suggérer que vous avez tout trouvé. Indiquer la fenêtre et les écosystèmes réellement balayés.

Composition

• Balayage récurrent : passer la procédure de cette compétence à la compétence schedule pour une exécution hebdomadaire dans le cloud sur les dépôts, de sorte qu'un nouvel incident soit détecté en quelques jours plutôt que quand quelqu'un pense à regarder.
• Avant une publication ou un push : exécuter un balayage ciblé d'un seul projet. Il se combine naturellement avec une étape de pré-push make audit / make secret-scan si le projet en possède une.

Remarques

• Les outils d'audit sont des indicateurs retardés ; l'actualité et l'étape 4 de cette compétence sont les indicateurs avancés. Lorsqu'ils divergent — la recherche dit qu'un package est compromis mais que les outils se taisent — faire confiance à la vérification directe du lockfile et le traiter comme actif.
• npm audit rapporte la gravité de l'avis, pas votre exploitabilité (pas d'analyse d'atteignabilité) — il sur-rapporte. govulncheck est l'opposé et le modèle à privilégier lorsqu'un écosystème le propose.
• Cette compétence répond à l'exposition. La remédiation (mises à jour de version, épinglage, npm rebuild pour une exception de script limitée) est une étape distincte et approuvée par l'utilisateur — suggérer le correctif, ne pas l'appliquer sans demande.