1. Inventorier ce que la compilation utilise réellement
Notez gestionnaire de paquets, fichier de verrouillage, version Node, dépendances directes, chemin transitif de chaque paquet signalé et scripts d’installation ou de post-installation. Un nom de paquet ne suffit pas : le risque dépend de la version, de la source, des scripts et du contexte d’exécution.
Gardez d’abord l’inventaire en lecture seule. Le premier résultat utile est une carte qu’un autre responsable peut examiner, pas une longue liste de CVE sans chemins affectés ni possibilité d’atteindre le code concerné.
- Le fichier de verrouillage et le gestionnaire de paquets sont précisés.
- Les paquets signalés sont reliés à un chemin de dépendance.
- Les scripts de cycle de vie et le registre source sont consignés.
- Les environnements de compilation et d’exécution sont distingués.
2. Associer le contrôle à ses preuves
supply-chain-risk-auditor convient à une revue ciblée des dépendances. Semgrep ou CodeQL peuvent apporter le contexte de règles ou de flux de données lorsque le dépôt et le langage sont pris en charge. Utilisez chaque outil pour le signal qu’il peut réellement produire et conservez commande, révision, périmètre et résultat.
Un constat peut être périmé, concerner du code inaccessible ou être un faux positif. La revue doit expliquer le changement, le chemin affecté et la prochaine vérification du responsable, sans transformer une étiquette d’outil en approbation automatique ou en alarme injustifiée.
3. Classer le problème avant de modifier les dépendances
Distinguez script d’installation suspect, paquet abandonné ou usurpant un nom, version connue comme vulnérable, changement inattendu de responsable ou de registre et paquet simplement inutilisé. Ces catégories demandent des preuves et des suites différentes.
Pour chaque point, notez le motif d’escalade, la plus petite expérience sûre et le retour arrière. Si la revue ne peut pas préciser ce qui infirmerait le soupçon, elle n’est pas prête à guider un changement de dépendance.
- Le risque est relié à une version et une source.
- Le chemin de code ou le script affecté est identifié.
- Une étape de vérification sûre est nommée.
- La modification proposée possède un responsable et un retour arrière.
4. Limiter la conclusion à ce qui a été audité
Un scan réussi peut étayer une affirmation limitée, par exemple « aucune alerte de ce jeu de règles n’a été trouvée dans le fichier de verrouillage examiné ». Il ne prouve pas que le paquet est sûr, que l’application est sans vulnérabilité ou que le registre ne changera pas.
Ne publiez la fiche de preuves qu’après retrait des identifiants secrets, chemins privés et journaux sensibles. La valeur de cette page est un périmètre de revue répétable, pas un badge de sécurité pour un paquet ou un dépôt.