Chaîne logicielle et intégrité

Chaîne logicielle et intégrité

1. Défaillance de la chaîne logicielle (A03)

   Ce risque entre au Top 10 en 2025 : il traduit le poids réel des dépendances, des registres et des systèmes de construction. Une application n'est plus seulement son code : c'est son code plus tout ce qu'elle embarque.

   Les trois surfaces

   • Dépendances : une bibliothèque compromise se propage à toutes les applications qui l'utilisent.
   • Registres et installateurs : un paquet publié puis retiré reste dans des caches et sur des machines.
   • Systèmes de construction : c'est là que se décide ce qui est réellement compilé et publié.

   Les mesures qui comptent

   1. Verrouiller les versions et garder le fichier de verrouillage versionné : c'est ce qui rend une construction reproductible.
   2. Réduire les dépendances : chaque dépendance est une surface d'attaque. Une petite bibliothèque stable vaut mieux qu'un ensemble instable et non maintenu.
   3. Vérifier les signatures et empreintes des artefacts téléchargés, et échouer si elles diffèrent.
   4. Analyser les vulnérabilités de façon automatique, avec un seuil qui bloque le déploiement.
   5. Isoler la construction : l'environnement qui construit n'a pas accès aux secrets de production.

2. Intégrité des logiciels et des données (A08)

   Cette entrée couvre la confiance accordée à un artefact, et la vérification de ce qu'on a downloaded.

   • Mise à jour automatique : vérifier la signature avant d'appliquer, jamais après.
   • Désérialisation : lire une donnée sérialisée venue de l'extérieur peut exécuter du code. Les chargeurs sûrs n'instancient que les classes autorisées.
   • Intégrité des données au repos : un chiffrement sans authentification ne protège pas — un contenu chiffré reste modifiable, avec un risque de permutation. Il faut un mode qui authentique également.
   • Signatures de code : signer l'artefact publié permet de vérifier qu'il vient bien de vous.

3. Mauvaise gestion des conditions exceptionnelles (A10)

   Entrée nouvelle du Top 10 2025, et pourtant ancienne cause de failles : le traitement de l'échec.

   • Erreur masquée : un except qui ignore l'erreur transforme un problème visible en silence.
   • Message trop détaillé : renvoyer une trace d'exécution à l'utilisateur facilite l'exploitation ; on journalise côté serveur, on répond « une erreur est survenue ».
   • Opération à moitié faite : si la seconde étape échoue, la première a déjà été appliquée. C'est l'absence de transaction qui laisse le système dans un état incohérent.
   • Échec non traité : un service qui s'interrompt sur une entrée imprévue devient un déni de service.

   Le principe : l'échec est un chemin normal. Il se conçoit, se teste et se mesure, exactement comme le cas nominal.

4. Exercices

   1. Inventaire des dépendances : listez les dépendances directes et transitives de votre projet, et identifiez celles qui ne sont plus utilisées.
   2. Traitement d'erreur : relevez tous les blocs qui masquent une erreur dans votre application et remplacez-les par un traitement explicite.
   3. Transaction :Operations une opération en deux étapes dont la seconde peut échouer, et montrez ce qu'un traitement non transactionnel laisse derrière lui.