Un portail pour de nouvelles dépendances
La réponse pratique consiste à faire des modifications de dépendances une partie distincte et exécutoire de la révision du code. Une demande d’extraction qui ajoute un package ou modifie sa version résolue doit produire une différence de dépendance avant de pouvoir fusionner. Les contrôles de vulnérabilité connue restent utiles, mais ils ne constituent qu’un élément d’entrée : indexed-btree n’avait pas besoin d’un CVE connu pour être dangereux. La porte doit également indiquer le nom exact du package, sa version, sa provenance lorsqu’elle est disponible et les fichiers publiés qui seront réellement exécutés.
Pour une dépendance existante recevant une mise à jour de routine, les équipes peuvent appliquer leur politique normale. Un nouveau nom, un passage à un package similaire, un changement d’éditeur ou un fichier exécutable ou obscurci inexpliqué devraient suspendre la fusion pour qu’un propriétaire puisse enquêter. Il s’agit d’une règle de décision, et non d’une demande à chaque ingénieur de lire chaque ligne de node_modules. Examiner l’artefact résolu et sa modification par rapport à la version précédemment approuvée ; enregistrez pourquoi le package est nécessaire et où il sera exécuté.
Utilisez une différence de dépendance automatisée pour rendre cela visible sur chaque demande d’extraction, puis exigez la protection de la branche d’enregistrement. L’examen des dépendances de GitHub, par exemple, peut effectuer des vérifications des vulnérabilités connues nouvellement introduites et afficher les modifications apportées aux packages. Il ne certifie pas qu’un colis sans avis est sûr. Ajoutez une règle distincte pour les identités de packages nouvelles ou inattendues et acheminez ces cas vers un réviseur désigné. Le résultat de la fusion doit être explicite : approuver la version exacte pour une utilisation définie, l’examiner ou la rejeter.
