DevSecOps : les donneurs d'ordre durcissent le ton et contrôlent les prestataires à chaque étape du build

En décembre 2020, la mise à jour trojanisée de SolarWinds Orion est parvenue à environ 18 000 clients de l'entreprise. Cet épisode a rappelé à l'industrie que la vulnérabilité peut venir non du produit lui-même, mais du chemin qu'il emprunte jusqu'au client. Le marché russe en arrive à la même conclusion. D'après un article de TAdviser, les donneurs d'ordre s'enfoncent de plus en plus dans une logique de zero trust à l'égard des prestataires IT et réclament un « pipeline stérile » de développement, avec vérification multiple du code. Cette approche repose sur le DevSecOps, un cycle de création de logiciels où la sécurité est intégrée à chaque étape au lieu d'être ajoutée juste avant la release.

D'où vient la défiance

Le modèle classique était simple. Le prestataire écrit le code, livre le build, le client procède à la recette. Tout ce qui se passe chez le prestataire reste une boîte noire. Or un prestataire, ce sont des ordinateurs portables de développeurs, des bibliothèques tierces, des dépôts cloud et des systèmes de CI, et chacun de ces éléments peut être compromis.

Les exemples ne manquent pas. La vulnérabilité Log4Shell, fin 2021, a montré comment une seule bibliothèque de journalisation se retrouve dans des milliers de produits dont les propriétaires ne soupçonnent même pas la présence. La porte dérobée dans l'archiveur XZ Utils (CVE-2024-3094), découverte en 2024, avait été introduite par une longue opération d'ingénierie sociale visant le mainteneur du projet. Le principe de zero trust, formalisé dans la NIST SP 800-207, impose de vérifier chaque participant et chaque action. Il s'applique désormais au développement.

À quoi ressemble le « pipeline stérile »

L'article de TAdviser décrit une tendance et non un standard unique : l'ensemble des mesures varie donc d'un donneur d'ordre à l'autre. Le dispositif type se présente ainsi :

• un environnement de build isolé, sans accès à Internet et avec un jeu limité de dépendances externes ;
• une analyse statique du code (SAST) à chaque commit et une analyse dynamique (DAST) sur les environnements de test ;
• une analyse de composition logicielle (SCA) : inventaire des composants tiers et recherche des vulnérabilités connues ;
• un SBOM, la liste de tous les composants du build, comme artefact de livraison obligatoire ;
• l'analyse des dépôts à la recherche de secrets : clés, jetons, mots de passe ;
• une revue de code obligatoire par une seconde personne et la signature des artefacts produits ;
• une nouvelle vérification des sources et du build du côté du donneur d'ordre.

Le mot clé est ici « multiple ». Le même code est analysé chez le prestataire, puis chez le donneur d'ordre, et parfois aussi par un laboratoire indépendant. Chaque couche détecte ce que la précédente a laissé passer. Chacune part aussi du principe que la précédente a pu être compromise.

Le prix à payer pour le prestataire

Pour le prestataire, cela signifie des coûts en hausse et une refonte des processus. Il lui faut des chaînes de build dédiées, des licences pour les outils d'analyse, des spécialistes du développement sécurisé et une discipline qui fait souvent défaut aux petites équipes. Les intégrateurs matures, chez qui le DevSecOps est déjà ancré dans la production, y gagnent. Les petits studios devront soit monter en compétence, soit se replier sur des segments aux exigences moins strictes.

Il y a aussi un revers. Les vérifications multiples ralentissent les releases, et une partie des alertes des analyseurs sont de faux positifs, qui deviennent du bruit si on ne les trie pas. Le donneur d'ordre qui en fait trop en matière de contrôle le paie en délais.

Par où commencer

Le donneur d'ordre a intérêt à inscrire dans le contrat les exigences de développement sécurisé : format du SBOM, fréquence des scans, droit d'audit et procédure de réaction aux vulnérabilités détectées. Il est raisonnable de classer les prestataires selon la criticité des systèmes et de ne pas imposer partout le même niveau maximal de contrôle.

Le prestataire a intérêt à commencer petit : activer l'analyse des secrets et des dépendances dans la CI existante, rendre la revue obligatoire et apprendre à générer le SBOM automatiquement. Ces mesures coûtent moins cher que les autres et lèvent d'emblée les principales questions des auditeurs. Celui qui se prépare avant que l'exigence n'apparaisse dans un appel d'offres prendra l'avantage sur ceux qui s'y mettront après.