Pendant des décennies, la mise à jour rapide des dépendances logicielles a été érigée en dogme de la cybersécurité. Appliquer sans délai les correctifs était le meilleur rempart contre les vulnérabilités connues. Or, une analyse publiée en mai 2026 par un expert en sécurité — témoin de l'évolution du secteur depuis la fin des années 1990 — affirme que cette règle de base est devenue dangereuse.

L'auteur rappelle que dans les années 1990 et 2000, l'environnement logiciel était beaucoup plus simple : on dépendait d'un nombre limité de fournisseurs formels, que l'on pouvait auditer manuellement. Le passage massif à l'open source, ainsi que la croissance exponentielle des écosystèmes, ont changé la donne. Les dépendances se comptent par centaines, voire par milliers, et leur gestion échappe à tout contrôle individuel.

Le glissement vers la compromission de la chaîne d'approvisionnement

L'analyse soutient que la sécurité ne consiste plus seulement à corriger des failles dans son propre code ou dans celui de ses dépendances amont. Le problème principal est devenu l'impossibilité de faire confiance à la chaîne d'approvisionnement elle-même. Entre 2025 et 2026, plusieurs incidents majeurs — cités sous les noms de code Shai Hulud, Nx s1ngularity, axios, TeamPCP, chalk/debug/qix ou tj-actions/changed-files — ont illustré la facilité avec laquelle des attaquants peuvent compromettre des comptes de développeurs et diffuser des versions piégées de bibliothèques très utilisées.

L'auteur rappelle des vulnérabilités historiques qui ont secoué l'ensemble du réseau — BIND, OpenSSL ou Log4j (Log4Shell) — et souligne que les mainteneurs open source, souvent bénévoles et sous-équipés, n'ont pas les moyens d'assurer une sécurité parfaite. Face à cette situation, la réponse dominante de l'industrie a été de « jeter les bras en l'air » : on se contente d'être à la dernière version en espérant que le correctif viendra d'en haut.

L'illusion du processus

Selon l'essai, les mécanismes formels mis en place (programmes de divulgation responsable, politiques de sécurité, CVSS, certifications ISO) n'ont pas résolu les causes profondes. Ils créent une illusion de contrôle tout en générant des coûts supplémentaires. L'auteur dénonce une forme de « sécurité par le nombre » : on mise sur le fait que la majorité des utilisateurs subira les mêmes attaques, plutôt que de réellement vérifier l'intégrité de ce que l'on installe.

Les outils techniques existent, mais sont peu adoptés

Ironiquement, des solutions techniques robustes existent pour durcir la chaîne d'approvisionnement : transport chiffré obligatoire, adressage par contenu, OIDC/Fulcio, TUF, SLSA, authentification à deux facteurs, etc. Mais leur adoption reste faible en raison de la complexité et de l'effort requis. Les bonnes pratiques peinent à s'imposer dans l'ensemble de l'industrie.

Une recommandation contre-intuitive

Face à ce constat, certains gestionnaires de paquets recommandent désormais de ne pas mettre à jour ses dépendances avant un certain nombre de jours, afin de laisser les premiers utilisateurs « payer le prix » et détecter d'éventuels pièges. C'est un retournement complet par rapport à la sagesse conventionnelle. L'analyse conclut que l'époque où l'on pouvait « tout mettre à jour sans regarder » est révolue, et qu'il faut repenser fondamentalement la manière de gérer les dépendances.

Ce débat intervient alors que la prochaine génération d'outils de développement devra intégrer dès leur conception des mécanismes de vérification de provenance et de confiance, au lieu de les ajouter après coup.