Kennedy Toomey
Nous avons publié il y a peu l’étude État des lieux du DevSecOps 2026, dans laquelle nous avons analysé des dizaines de milliers d’applications, mais aussi leur supply chain et les dépendances du système de build. Notre étude a mis au jour des tendances dans les postures de sécurité, ainsi que des bonnes pratiques applicables à l’ensemble du cycle de développement logiciel. Nous avons notamment constaté les points suivants :
Les développeurs ont toujours des difficultés à maintenir les bibliothèques à jour
L’installation d’une mise à jour moins de 24 h après sa publication n’est pas sans risques
GitHub Actions est vulnérable aux attaques de la supply chain
La plupart des vulnérabilités ne doivent pas générer une alerte traitée par un humain
À la lumière de ces constats, voici quelques bonnes pratiques que nous invitons les organisations à adopter :
Utiliser des métriques DORA pour améliorer la sécurité de manière mesurable
Mettre à jour les logiciels rapidement, mais sans précipitation
Utiliser le contexte des applications et des vulnérabilités pour optimiser la priorisation
Nous expliquons également dans notre article comment utiliser Datadog Code Security et Cloud SIEM au sein de la plateforme Datadog pour améliorer votre posture de sécurité et vous protéger des menaces.
Sécuriser plus efficacement GitHub Actions
Les pipelines CI/CD jouent un rôle majeur dans le développement moderne, mais ils constituent aussi une cible de choix pour les hackers. Notre étude montre qu’en l’absence d’une sécurisation adaptée, GitHub Actions est particulièrement exposé aux attaques de la supply chain. L’application de tags comme @v1 ou @latest aux actions tierces permet l’injection de code malveillant directement dans votre pipeline de build en cas de compromission de leur dépôt. GitHub recommande vivement de verrouiller les actions sur un SHA de commit spécifique et immuable.
# the secure way: pinning to a commit SHAuses: thollander/actions-comment-pull-request@b07c7f86be67002023e6cb13f57df3f21cdd3411# the insecure way: pinning to a taguses: thollander/actions-comment-pull-request@v2Cette opération pouvant être fastidieuse, GitHub permet via son outil Dependabot de créer des pull requests mettant à jour le hachage vers la dernière version à intervalles réguliers.
Datadog Infrastructure as Code (IaC) Security offre une visibilité complète sur les configurations CI/CD. Datadog inclut des règles IaC prédéfinies pour GitHub Actions qui analysent automatiquement les fichiers de votre workflow et signalent les configurations risquées, comme l’absence de verrouillage des actions sur un hachage de commit précis. Vous pourrez ainsi sécuriser vos pipelines avant que le code n’arrive en production.
Utiliser des métriques DORA pour améliorer la sécurité de manière mesurable
Les métriques DevOps Research and Assessment (DORA) sont généralement utilisées pour évaluer la vélocité et la stabilité de la livraison des logiciels, mais nous avons constaté que leur amélioration est fortement corrélée au renforcement de la posture de sécurité. Les équipes performantes déploient leurs logiciels à un rythme soutenu, sans augmentation du taux de défaillance, ce qui témoigne d’un processus de livraison à la fois efficace et résilient. Notre étude et les pratiques de l’industrie montrent que les équipes obtenant des métriques DORA plus élevées livrent leur code plus rapidement et se relancent plus rapidement après une défaillance. Leurs fenêtres d’exposition aux vulnérabilités sont ainsi réduites, et les boucles de rétroaction pour l’application de correctifs et de mises à niveau plus rapides.
Du point de vue de la gestion des dépendances, cela signifie que les équipes avec les meilleures métriques DORA sont capables d’intégrer en continu les mises à jour des bibliothèques. Leurs services incluent moins de packages obsolètes ou vulnérables et sont plus sécurisés que les services dont les scores DORA sont plus bas. En alignant la vélocité du développement sur les objectifs de sécurité, les organisations peuvent mettre en place un cycle de déploiement fréquent et stable qui encourage une innovation rapide et limite le risque.
Pour aider les équipes à exploiter les informations révélées par les métriques DORA, Datadog fournit une suite intégrée d’outils allant de la surveillance des performances à la réponse aux incidents, en passant par la visibilité CI et l’analyse de la qualité du code. La page DORA Metrics centralise les quatre indicateurs clés : fréquence de déploiement, délais de modification, taux d’échec des changements et délai de rétablissement du service. Les équipes peuvent également segmenter et filtrer les métriques par attribut, par exemple le service, l’environnement ou l’équipe. Elles peuvent ainsi adapter leurs analyses à des workflows spécifiques et concentrer les efforts d’amélioration là où ils auront le plus d’impact.
Mettre à jour les logiciels rapidement, mais sans précipitation
S’il est indispensable de mettre à jour les logiciels, le faire automatiquement et sans discernement est risqué. Nous avons constaté que ce risque était particulièrement important pour les AMI et les bibliothèques.
Bibliothèques
De récents incidents ayant touché la supply chain montrent à quelle vitesse des dépendances malveillantes peuvent faire de lourds dégâts une fois qu’elles ont atteint l’écosystème logiciel. Des campagnes comme s1ngularity et les deux Shai-Hulud reposent sur des packages malveillants publiés dans des dépôts publics, depuis lesquels elles ont été importées dans des projets sans que personne ne s’en rende compte. Les mises à jour automatiques des dépendances et des contraintes de version laxistes ont accéléré cette propagation : les packages compromis se sont répandus comme une traînée de poudre, sans intervention manuelle. Ce qui a peut-être commencé par l’envoi d’un seul fichier malveillant s’est rapidement traduit par des milliers d’installations. Ces événements montrent comment les pratiques de développement modernes, et en particulier les mises à jour automatiques destinées à booster la vélocité, peuvent amplifier le rayon d’impact d’une attaque de la supply chain en l’absence de garde-fous appropriés.
Pour protéger vos supply chains, déployez des outils CLI open source, comme GuardDog et Supply-Chain Firewall. GuardDog identifie les comportements suspects ou malveillants des packages open source, par exemple les techniques d’obfuscation, les patterns d’exfiltration des données ou les indices de typosquatting, avant qu’ils ne soient intégrés à votre base de code. Supply-Chain Firewall peut empêcher automatiquement l’installation de packages malveillants connus dans les environnements de développement pour que les dépendances compromises n’atteignent jamais votre cycle de développement. Cet outil est en partie basé sur la base de packages logiciels malveillants open source de Datadog. Des chercheurs en sécurité et GuardDog la mettent à jour en temps réel en fonction des campagnes observées contre la supply-chain. Ensemble, ces outils donnent aux organisations la visibilité et les contrôles dont elles ont besoin pour réduire leur exposition aux dépendances malveillantes en amont de la chaîne.
Le verrouillage des packages sur un SHA de commit complet est souvent mis de côté, car fastidieux, mais c’est pourtant un moyen efficace pour réduire le risque d’introduction de dépendances malveillantes. D’autres mesures peuvent aider à créer un tampon de protection. Par exemple, Yarn et pnpm proposent désormais des configurations imposant un délai minimal de publication afin de retarder l’installation des nouvelles versions des packages. Même stratégie pour Dependabot de GitHub, qui propose un paramètre de temporisation pour décaler les mises à jour automatiques. Ce retard volontaire permet à la fois de rester à jour et d’éviter d’installer un package malveillant tout juste publié. Un délai d’une semaine pourrait par exemple empêcher la propagation d’une majorité des dépendances compromises.
minimumReleaseAge: 10080 # one week in minutesnpmMinimalAgeGate: "7d" cooldown: default-days: 7Datadog Software Composition Analysis (SCA) permet aux équipes d’identifier les packages malveillants connus avant leur déploiement en production en analysant en permanence les dépendances des dépôts et services. SCA détecte les packages vulnérables et suspects à l’aide d’informations sur les menaces et de bases de données de vulnérabilités. Les équipes peuvent ainsi détecter rapidement les risques dès le début du développement et dans les applications déjà déployées. L’onglet Libraries (SCA) de Code Security permet aux développeurs d’explorer les services et répertoires pour trouver les packages vulnérables ou risqués et identifier leur point d’introduction.
De plus le Research Feed (fil de recherche) Security fournit des alertes rapides sur les nouvelles attaques de la supply chain, les campagnes de packages malveillants et les nouvelles menaces détectées, et révèle si votre environnement est touché. Ensemble, ces différents outils permettent aux organisations de détecter, d’analyser et de corriger rapidement les dépendances malveillantes.
AMI
Les Amazon Machine Images (AMI) sont vulnérables aux attaques par confusion de nom. Une erreur de configuration a priori sans conséquence sur la sélection des AMI peut ainsi entraîner de graves compromissions des environnements cloud. Dans cette attaque, les logiciels qui récupèrent les AMI les plus récentes à l’aide de l’API AWS ec2:DescribeImages sans spécifier explicitement un propriétaire de confiance peuvent lancer une AMI malveillante dont le hacker a choisi le nom avec soin. Tout le monde peut publier une AMI dans le catalogue public, et cette attaque par confusion du nom peut donc entraîner la sélection de l’image du hacker aux dépens de celle voulue et aboutir à l’exécution de code à distance sur le compte AWS de la victime. Cette possibilité montre que la méthode de sélection de l’AMI ne doit pas se faire au plus pratique : elle peut devenir un vrai vecteur d’attaque de la supply chain et nécessite donc la mise en place de garde-fous et mécanismes de détection.
En réaction à cette étude, AWS a mis en place la fonctionnalité Allowed AMIs, qui permet aux organisations de limiter les lancements d’instances aux seules images de confiance. Il s’agit d’une protection particulièrement importante pour l’utilisation d’AMI communautaires. Les équipes souhaitant vérifier quelles images ont déjà été utilisées en interne peuvent s’appuyer sur whoAMI-scanner, un outil open source dont les rapports révèlent les AMI communautaires non vérifiées déployées au sein de leur organisation. De plus, Investigator.cloud permet d’analyser les AMI publiques et de retracer leur lignage pour mieux comprendre leur provenance et le risque qu’elles peuvent poser.
Datadog Infrastructure as Code (IaC) Security a créé une règle de vérification de votre code Terraform pour déterminer si l’AMI la plus récente est utilisée sans propriétaire ou filtre. Datadog Cloud SIEM propose de son côté une règle pour vous alerter lorsque l’endpoint ec2:DescribeImages est interrogé sans identifiants de propriétaire et que cette opération est suivie d’un appel à ec2:RunInstances par le même ARN.
Utiliser le contexte des applications et des vulnérabilités pour optimiser la priorisation
Les vulnérabilités des dépendances sont partout, et le nombre de détections au sein des bases de code modernes peut rapidement submerger les équipes de sécurité, même de taille conséquente. Dans de nombreuses organisations, la priorisation des vulnérabilités repose encore principalement sur les scores Common Vulnerability Scoring System (CVSS). Si ces scores forment une base solide pour estimer la gravité théorique d’une vulnérabilité, ils ne reflètent pas la façon dont se manifeste la vulnérabilité en question dans un environnement donné. Les équipes traitent donc souvent chaque vulnérabilité critique avec le même degré d’urgence, qu’elle soit réellement exploitable ou non.
Notre étude montre que seulement 18% des vulnérabilités initialement considérées comme critiques le restent lorsqu’elles sont évaluées avec un contexte supplémentaire. Les 82 % restantes sont déclassées en raison de facteurs comme l’exposition à l’exécution, l’exploitabilité et l’accessibilité. Cet écart témoigne d’une difficulté centrale de la gestion des vulnérabilités : la gravité ne fait pas le risque. Sans contexte environnemental, les équipes de sécurité en sont réduites à traiter les vulnérabilités dont le score est élevé plutôt que celles qui sont réellement pertinentes.
Nous avons également constaté que les services déployés dans 87 % des organisations renferment au moins une vulnérabilité exploitable connue. Ce chiffre est d’autant plus frappant que nombre de failles sont déclassées lorsqu’aucun exploit n’existe. Les scores de gravité optimisés révèlent donc qu’une part importante de vulnérabilités franchit encore ce cap. C’est sur ces menaces concrètes, présentes en production, que les organisations doivent concentrer leurs efforts.
Le modèle de scoring de gravité actualisé de Datadog résout ce problème en intégrant le contexte d’exécution et des informations sur les exploits dans la priorisation des vulnérabilités. Il va plus loin que le score CVSSS classique pour mieux représenter le risque réel auquel un service ou une application est exposé. Il tient compte de la présence de la dépendance vulnérable en production, de son accessibilité via les chemins d’exécution et de son association avec des indices d’exploitation active. Il représente ainsi mieux l’urgence à la corriger. Le résultat ? Une roadmap de remédiation plus claire et plus ciblée qui permet aux équipes d’optimiser l’impact de leurs actions.
Sécuriser votre SDLC avec Datadog
Pour maintenir la vélocité du développement sans risquer leur sécurité, les organisations doivent bénéficier d’une visibilité complète sur l’ensemble de leur cycle de développement, des vulnérabilités de leur code applicatif aux erreurs de configuration de l’infrastructure cloud. Elles doivent aussi disposer du contexte nécessaire pour prioriser et éliminer les risques les plus menaçants. Datadog centralise toutes ces informations dans une plateforme servant déjà à surveiller l’intégrité et les performances des systèmes. Nous éliminons ainsi les silos opérationnels et permettons aux équipes de collaborer plus efficacement. En centralisant la sécurité et l’observabilité, nous aidons les organisations à accélérer l’adoption du DevSecOps tout en améliorant leur sécurité de façon mesurable.
Consultez notre documentation pour démarrer. Vous n’êtes pas encore client ? Commencez dès aujourd’hui par un essai gratuit de 14 jours.
