CI/CD et DevSecOps : sécuriser la chaîne de livraison sans la bloquer.

Le DevSecOps consiste à intégrer les contrôles de sécurité dans la chaîne d’intégration et de livraison continues, plutôt qu’à les placer en fin de cycle. Le principe fait consensus, sa mise en œuvre échoue régulièrement pour une raison simple : un dispositif qui bloque les déploiements sur des alertes non priorisées se fait contourner en quelques semaines. Cette page traite comment intégrer la sécurité sans casser le rythme, comment maîtriser la chaîne d’approvisionnement logicielle, et ce qu’il faut mesurer, dans le prolongement de notre couverture IA, données et plateformes.

Ce que la chaîne automatise

Définition. L’intégration continue vérifie automatiquement chaque modification de code par une construction et une batterie de tests. La livraison continue automatise la mise à disposition d’une version validée jusqu’à l’environnement de production. Le DevSecOps y ajoute les contrôles de sécurité, exécutés au même titre que les tests.

Une chaîne de livraison mature enchaîne six étapes : construction, tests automatisés, analyse de la qualité et de la sécurité du code, construction et signature de l’artefact, déploiement progressif, vérification post-déploiement.

Le bénéfice de sécurité principal n’est pas l’analyse de code. C’est la traçabilité : savoir quelle version tourne, à partir de quel code, construit par quel pipeline, avec quelles dépendances, et pouvoir revenir en arrière en minutes. Une organisation qui ne sait pas répondre à ces questions ne peut pas traiter un incident correctement.

Intégrer la sécurité sans bloquer

Quatre familles de contrôles, avec des profils très différents.

La règle qui décide de l’adoption : ne rendre bloquant que ce dont le taux de faux positifs est maîtrisé. Un dispositif qui interrompt une livraison sur une alerte de faible sévérité et non exploitable dans le contexte détruit sa propre crédibilité. Les équipes obtiennent alors des dérogations permanentes, et le contrôle ne sert plus.

La priorisation des vulnérabilités remontées suit la même logique que celle décrite dans notre couverture des vulnérabilités et CVE : l’exposition et l’exploitation constatée priment sur le score de sévérité.

La chaîne d’approvisionnement logicielle

C’est le sujet qui a le plus progressé, et celui que les organisations traitent le moins.

Une application moderne embarque des centaines de composants tiers, eux-mêmes dépendants d’autres composants. La question à laquelle il faut pouvoir répondre en quelques minutes lors d’une alerte : utilisons-nous ce composant, dans quelle version, dans quelles applications ?

Trois pratiques y répondent :

• L’inventaire des composants logiciels. Produire, pour chaque artefact livré, la liste exhaustive de ses dépendances et de leurs versions. C’est ce document qui permet la recherche rétroactive.
• La signature des artefacts. Garantir qu’un artefact déployé est bien celui qui est sorti du pipeline, et non un binaire substitué.
• La maîtrise des sources. Restreindre les registres autorisés et figer les versions, plutôt que de récupérer la dernière version disponible à chaque construction.

Le risque n’est pas théorique : la compromission d’un composant très utilisé, ou d’un maillon de la chaîne de construction, atteint simultanément toutes les organisations qui en dépendent. Voir notre couverture des logiciels malveillants.

Les secrets, angle mort permanent

Identifiants de bases, clés d’interface de programmation, certificats, jetons de déploiement. Ils se retrouvent dans les dépôts de code, dans les variables de pipeline, dans les images de conteneurs et dans les fichiers de configuration.

Trois mesures, par ordre d’effet :

1. Détecter avant l’écriture dans le dépôt, par un contrôle exécuté côté poste de développement en plus du pipeline. Un secret déjà versé reste dans l’historique même après suppression.

2. Centraliser dans un coffre-fort, avec injection au moment de l’exécution plutôt que stockage dans la configuration.

3. Faire tourner les secrets automatiquement, ce qui limite la durée d’exploitation d’une fuite non détectée.

Le sujet croise directement la gestion des identités et des accès, en particulier sur les identités machines et les comptes de service.

Ce qu’il faut mesurer

Quatre indicateurs suffisent à piloter, et ils sont mieux que les compteurs d’alertes.

• Fréquence de déploiement. Elle mesure la fluidité réelle de la chaîne.
• Délai entre le code écrit et le code en production. Un délai qui s’allonge signale un dispositif de contrôle mal calibré.
• Taux d’échec des changements et délai de remise en service. Ils mesurent la fiabilité, pas la vitesse.
• Délai de correction d’une vulnérabilité critique exploitable, de la publication au déploiement du correctif.

Ce dernier est le seul indicateur de sécurité qui compte réellement dans une chaîne de livraison. Le nombre d’alertes remontées ne dit rien du niveau de risque. L’instrumentation associée est traitée dans notre section observabilité et monitoring, et la reproductibilité des environnements dans notre section Infrastructure as Code.

Explorer le cluster

Cette page fait partie de notre couverture de l’intelligence artificielle, de la donnée et des plateformes : gouvernance, socle technique et industrialisation.

iTPro+ : recevez chaque semaine les analyses plateforme et sécurité qui concernent les équipes techniques.