Verrouiller et mettre à jour les dépendances

Deux obligations qui tirent en sens contraire

Exigence	Ce qu’elle impose	Ce qu’elle pousse à faire
Annexe I, partie I — pas de vulnérabilité exploitable connue à la mise sur le marché	Les composants doivent être à jour	Mettre à jour souvent
Annexe I, partie II, point 2 — corriger sans délai	Idem, en continu	Mettre à jour vite
Art. 13, paragraphe 8 — période de support de cinq à dix ans	Pouvoir reconstruire à l’identique une version livrée il y a huit ans	Tout figer

Le règlement exige donc simultanément la fraîcheur et la reproductibilité. La réponse n’est pas un compromis mou : c’est figer précisément, et mettre à jour délibérément.

Figer : le fichier de verrouillage

Un manifeste déclare des intervalles (« version 5 ou supérieure ») ; un fichier de verrouillage enregistre la résolution exacte, transitives comprises, avec les empreintes.

Sans lui, deux constructions du même code à deux dates différentes produisent deux artefacts différents. Les conséquences sont directement réglementaires :

le SBOM ne décrit plus de façon fiable ce qui a été livré ;
la reconstruction d’une version ancienne devient impossible, donc la période de support aussi ;
une substitution silencieuse de dépendance ne se voit pas.

La règle : le fichier de verrouillage est commité, il fait partie du code source, et la construction publiable échoue si la résolution s’en écarte. C’est ce que garantissent les modes d’installation stricts des différents écosystèmes, qui refusent de mettre à jour le fichier de verrouillage à la volée.

Figer aussi ce qui n’est pas une dépendance applicative

C’est l’angle mort le plus fréquent : on verrouille les bibliothèques, et on laisse mutable tout le reste de la chaîne.

Élément	Référence mutable — à éviter	Référence immuable
Action ou étape de CI réutilisée	Étiquette de version	Empreinte de commit complète
Image de base de conteneur	`:latest`, ou une étiquette de version	Empreinte de contenu
Script distant exécuté par la chaîne	URL vers la branche principale	URL figée + vérification d’empreinte
Outil installé à la volée	« dernière version »	Version exacte, empreinte vérifiée

Pourquoi c’est décisif. Une étiquette peut être repointée vers un autre commit sans qu’aucune de vos références ne change. C’est exactement l’attaque qui a exposé les secrets de milliers de chaînes en mars 2025 — voir Incidents de référence. Une empreinte, elle, ne se repointe pas.

Mettre à jour : délibérément, pas automatiquement

Figer sans mettre à jour produit l’inverse du résultat cherché : un produit reproductible et vulnérable.

Les robots de mise à jour — Dependabot, Renovate — sont l’outillage standard. Ils ouvrent des propositions de modification lorsqu’une version est publiée, avec les notes de version et, selon la configuration, la vulnérabilité corrigée.

Mais un robot de mise à jour est lui-même un vecteur. Une montée de version automatique fusionnée sans revue introduit du code tiers directement en production. Trois garde-fous :

Garde-fou	Effet
Délai de quarantaine	Aucune version publiée depuis moins de N jours n’est proposée. Les paquets malveillants sont généralement retirés en quelques heures ou quelques jours
Fusion automatique restreinte	Réservée aux correctifs de sécurité sur des composants en liste blanche, et jamais pour un changement de version majeure
Revue humaine des dépendances sensibles	Liste explicite des composants dont toute montée de version passe par une personne

L’ingestion contrôlée : cache ou point de décision ?

Faire transiter les dépendances par un miroir interne est une bonne pratique répandue, mais il faut distinguer deux dispositifs que l’on confond souvent :

	Cache ou miroir	Point de décision à l’entrée
Fonction	Sert plus vite, résiste à l’indisponibilité amont	Autorise, refuse, met en quarantaine
Moment	Après téléchargement	Avant l’entrée dans l’organisation
Face à un paquet malveillant	Il le propage, et le conserve	Il le bloque

Un cache accélère ; il ne gouverne pas. Si l’objectif est d’empêcher un paquet typosquatté ou fraîchement publié d’entrer, il faut une décision appliquée avant l’ingestion, et une politique qui vive à côté du code plutôt que dans une console.

Point souvent négligé : la configuration seule ne suffit pas. Tant qu’un poste peut joindre directement le registre public, le contournement est trivial. Le filtrage sortant est ce qui rend la règle effective.

La reproductibilité, exigence de long terme

Sur un produit couvert par une période de support de dix ans, il faut pouvoir reconstruire dans huit ans. Cela suppose de conserver, en plus du code :

le fichier de verrouillage de la version livrée ;
les empreintes des images de base et des outils de construction ;
une copie des artefacts amont — un registre public n’est pas un service d’archivage, et des paquets disparaissent ;
la définition de la chaîne telle qu’elle était.

La démarche des builds reproductibles pousse la logique à son terme : deux constructions du même code produisent des artefacts identiques bit à bit. C’est exigeant, et c’est la seule preuve réellement vérifiable par un tiers.

Le recoupement mérite d’être dit : ce que le règlement impose de conserver pour la période de support, et ce que la GPL impose de fournir comme « code source correspondant », sont le même ensemble d’artefacts. Voir Application bureau ou ligne de commande.