Pourquoi les lockfiles, l'épinglage et la confusion de dépendances comptent-ils dans le build ?
Réponse courte
Les lockfiles épinglent les versions exactes et les empreintes des dépendances pour que chaque build résolve les mêmes octets vérifiés — rendant les builds reproductibles et bloquant les mises à jour malveillantes silencieuses. L'épinglage par empreinte, la vérification des empreintes d'intégrité et le cloisonnement des paquets internes dans un registre privé défendent aussi contre la confusion de dépendances, où un attaquant publie un paquet public de version supérieure correspondant à un nom interne pour détourner la résolution. Le principe : ne jamais laisser le build récupérer silencieusement du code non vérifié.
Un build qui récupère des dépendances à chaque fois n'est aussi digne de confiance que ce que le registre de paquets a bien voulu servir à cette minute-là. Les lockfiles et l'épinglage retirent cette incertitude du build.
Lockfiles : des builds reproductibles et vérifiés
Un lockfile (package-lock.json, yarn.lock, poetry.lock, go.sum) enregistre la version exacte de chaque dépendance — directe et transitive — plus une empreinte d'intégrité du contenu de chaque paquet. Deux conséquences comptent pour la sécurité :
- Reproductibilité. Chaque build, sur chaque machine, résout l'arbre de dépendances identique. Ce que vous avez testé est ce que vous livrez.
- Détection d'altération. Comme le lockfile stocke des empreintes de contenu, si un registre sert des octets différents pour la même version (un paquet compromis, un MITM), la vérification d'empreinte échoue et le build s'arrête. Épingler la version seule ne suffit pas — l'empreinte est ce qui prouve que vous avez obtenu le même code.
Confusion de dépendances
C'est l'attaque qui rend le cloisonnement essentiel. Si votre build résout les noms de paquets contre à la fois un registre privé (pour les paquets internes) et le registre public, un attaquant peut publier un paquet public portant le même nom que votre paquet interne mais un numéro de version supérieur. Une résolution naïve préfère la version supérieure et récupère le code de l'attaquant dans votre build. Défenses : cloisonner les paquets internes dans un registre/espace de noms privé, configurer la résolution pour que les noms internes ne retombent jamais sur le public, et vérifier les empreintes d'intégrité.
La tension avec les correctifs
Tout épingler signifie que vous cessez de recevoir des mises à jour — y compris les correctifs de sécurité. La réponse n'est pas d'arrêter d'épingler ; c'est d'épingler plus automatiser des mises à jour contrôlées (par ex. Dependabot/Renovate) qui montent les versions via revue et CI, pour que vous obteniez les correctifs délibérément plutôt que silencieusement.
Ce que recherchent les recruteurs
Ils veulent le cadrage reproductibilité-plus-intégrité, une explication correcte de la confusion de dépendances et du cloisonnement des registres, et la maturité de concilier l'épinglage avec le fait de rester à jour via des mises à jour automatisées et revues.
Questions de suivi probables
- Comment une attaque de confusion de dépendances détourne-t-elle réellement la résolution ?
- Quelle est la tension entre l'épinglage et l'obtention des correctifs de sécurité ?
- Pourquoi les empreintes d'intégrité d'un lockfile comptent-elles même si la version est épinglée ?