Sommaire (4 sections)
Toutes les analyses de sécurité de vos dépendances reposent sur un même postulat : le fichier de verrouillage dit la vérité. C'est lui qui fige, version par version, empreinte par empreinte, ce que votre application embarque réellement. L'analyseur le lit et rend son verdict.
Nous avons découvert il y a quelques jours que ce postulat pouvait être faux dans nos propres chaînes d'intégration, sans qu'aucun voyant ne s'allume. Voici ce qui se passait.
La restauration qui corrige au lieu d'alerter #
Quand une compilation démarre, elle restaure les dépendances. Si le fichier de verrouillage ne correspond plus aux dépendances déclarées — parce que quelqu'un a modifié une version sans régénérer le verrou —, le comportement par défaut de la plupart des outils est serviable : ils mettent le verrou à jour et continuent.
C'est très commode en développement. En intégration continue, c'est un désastre silencieux. La compilation passe au vert. Les tests passent au vert. Et le fichier de verrouillage qui part en production ne décrit plus ce que l'équipe a relu.
Le correctif tient en un drapeau : exiger une restauration en mode verrouillé. Dans ce mode, un verrou incohérent n'est plus réparé en douce — il fait échouer la construction, avec un message explicite. Nous l'avons ajouté à toutes nos chaînes concernées.
Avec une précaution qui a son importance : nous avons d'abord vérifié, dépôt par dépôt, que la branche principale passait ce contrôle. Ajouter un drapeau strict à un projet qui a déjà des verrous incohérents, c'est rendre sa chaîne rouge du jour au lendemain et pousser l'équipe à le désactiver. On ne pose pas un garde-fou sans avoir mesuré ce qu'il va bloquer.
Remonter les versions, vraiment #
Un verrou juste ne sert à rien s'il fige des versions de l'année dernière. Nous avons donc, en parallèle, traité le stock de mises à jour en attente sur l'ensemble de nos dépôts : vingt-six demandes de fusion, compilées, testées, et — c'est la partie que personne ne fait — ouvertes dans un vrai navigateur page par page avant fusion, puis vérifiées sur le site en production après déploiement.
Cette dernière étape n'est pas du zèle. Une montée de version majeure d'une bibliothèque d'interface compile parfaitement et rend une page blanche. Les tests unitaires ne le voient pas. La chaîne d'intégration ne le voit pas. Seul un navigateur le voit.
La faille que personne ne teste : la licence #
Le moment le plus instructif de la semaine n'a rien à voir avec une faille technique.
Une bibliothèque de test très répandue dans l'écosystème .NET a changé de licence entre deux versions majeures : d'une licence libre permissive, elle est passée à une licence propriétaire interdisant l'usage commercial sans achat. La montée de version automatique l'a proposée comme n'importe quelle autre.
Elle a compilé. Les 1 159 tests sont passés. Absolument rien, dans la chaîne, n'avait la moindre raison de protester — parce qu'aucune chaîne d'intégration ne teste les licences. Nous l'avons repérée en relisant les métadonnées du paquet, vérifiée dans son fichier de licence, puis annulée le jour même, avec une règle de blocage pour que la proposition ne revienne pas.
Un changement de licence est une régression juridique invisible. Elle ne casse aucun test, n'apparaît dans aucun scan de vulnérabilités, et se découvre en général au pire moment : un audit, une levée de fonds, une mise en demeure.
Nous avons cherché à outiller cette détection automatiquement. Nous avons échoué, et c'est une conclusion en soi : les analyseurs de licences que nous avons testés lisent les fichiers de licence présents dans l'arborescence, pas les métadonnées des paquets téléchargés. Ils ne voient donc ni cette bibliothèque, ni les autres. Plutôt que d'écrire un outil maison de plus, nous avons tranché : chaque dépendance sous licence restrictive fait l'objet d'un ticket de remplacement, suivi comme une dette technique ordinaire.
Ce que ça change pour vous #
- Vos analyses de sécurité lisent les vraies versions. Un verrou périmé rendait un verdict rassurant et faux ; il fait maintenant échouer la construction.
- Les mises à jour arrivent au fil de l'eau, en petites demandes de fusion lisibles, plutôt qu'en un lot annuel impossible à relire — et donc jamais fait.
- Vos licences sont regardées. Si une bibliothèque que vous utilisez passe sous un régime incompatible avec un usage commercial, nous le voyons et nous vous le disons, avant que ce soit votre avocat qui l'apprenne.
- Rien n'est fusionné sur la foi d'une compilation verte. Ce qui touche à l'interface est ouvert dans un navigateur, avant et après la mise en production.
Si vous voulez faire un seul contrôle chez vous ce mois-ci, faites celui-là : prenez votre fichier de verrouillage, et vérifiez que votre chaîne d'intégration échoue quand il est incohérent. Si elle le répare toute seule, votre tableau de bord de sécurité mesure quelque chose d'autre que votre production.
