DevOps 2026 : 29 M secrets hardcodés et OSS sous pression

Sept vérités difficiles sur l'état de la sécurité DevOps en 2026

Le 20 mai 2026, Help Net Security a publié une synthèse des enseignements du rapport 2026 DevOps Threats, un document consolidant les données de plusieurs études sectorielles majeures : le State of Secrets Sprawl 2026 de GitGuardian, le DevSecOps 2026 Report de Datadog, le Software Supply Chain Security Report 2026 de ReversingLabs, et l'analyse de StepSecurity sur la sécurité des workflows GitHub Actions. Le tableau dressé par ces rapports cumulés est préoccupant pour toute organisation qui développe ou déploie des logiciels en 2026.

La première statistique qui frappe est celle des secrets hardcodés. GitGuardian a analysé des milliards de commits sur GitHub public et a détecté 29 millions de nouveaux secrets exposés au cours de l'année 2025 — clés API, tokens d'authentification, mots de passe, certificats privés, chaînes de connexion aux bases de données. Ce chiffre représente une augmentation de 34 % par rapport à 2024 et constitue la plus forte hausse annuelle jamais enregistrée depuis que GitGuardian mesure ce phénomène. Plus alarmant encore : d'après le rapport, les secrets hardcodés sont désormais la première cause de compromission de code en entreprise, devant les failles non patchées et les erreurs de configuration cloud.

Le problème des secrets hardcodés est structurellement difficile à résoudre. Dans les pipelines de développement modernes, les développeurs travaillent sous pression constante, utilisent des dizaines d'outils, d'assistants IA et d'environnements de test. Les secrets finissent dans des fichiers de configuration, des scripts de déploiement, des notebooks ou des logs de CI/CD, parfois poussés dans des dépôts publics par inadvertance, parfois exposés via des forks ou des snapshots de dépôts privés. Une fois un secret exposé sur un dépôt public, il est aspiré par des bots de scan automatisés en quelques secondes — un délai bien inférieur au temps nécessaire pour détecter et révoquer manuellement la credential concernée.

Le rapport soulève également l'explosion des vulnérabilités dans les composants open source. Selon les données compilées, le nombre moyen de CVE embarquées dans une application a augmenté de 107 % entre 2024 et 2025, atteignant une moyenne de 581 vulnérabilités par codebase. Cette explosion est en partie liée à la croissance du nombre de dépendances utilisées par application — les outils d'IA générative encouragent notamment des architectures très dépendantes de bibliothèques tierces — et en partie à l'amélioration de la détection. Mais l'amélioration de la détection seule n'explique pas un doublement en un seul exercice.

Sur le front des attaques de la chaîne d'approvisionnement, les chiffres sont tout aussi préoccupants. D'après le rapport, npm a connu en 2025 une augmentation de plus de 100 % du nombre de packages malveillants détectés, atteignant 10 819 paquets identifiés comme malveillants sur la plateforme. L'attaque Shai-Hulud 2.0, documentée en fin d'année 2025, a infecté près de 700 packages npm et affecté plus de 25 000 dépôts GitHub, illustrant l'effet de multiplication propre aux attaques supply chain. Ces attaques ciblent désormais systématiquement les pipelines CI/CD pour injecter du code malveillant dans les artifacts de déploiement, contournant la plupart des contrôles de sécurité applicatifs traditionnels.

L'intégration de l'IA dans les workflows DevOps ajoute une nouvelle dimension de risque. Le rapport Datadog DevSecOps 2026 identifie les pipelines d'IA comme une surface d'attaque émergente critique : injections de prompts malveillants dans les systèmes d'agents IA, exécution de code à distance via des modèles manipulés, et fuites de credentials à travers les caches de contexte des LLM. Ces menaces sont peu documentées dans les standards de sécurité existants — les référentiels OWASP n'ont pas encore pleinement intégré les risques spécifiques aux pipelines d'IA générative en production.

Le rapport de StepSecurity, confirmé par le rapport Datadog, souligne que les organisations ayant implémenté des contrôles stricts sur leurs workflows GitHub Actions — notamment le pinning des actions par hash SHA256 plutôt que par tag mutable, et l'utilisation de permissions minimales pour les tokens GITHUB_TOKEN — ont significativement réduit leur surface d'exposition aux attaques de type pwn request. Cette corrélation directe entre une pratique DevSecOps spécifique et la réduction du risque réel est rare dans les rapports sectoriels et mérite d'être soulignée : il existe des mesures simples, immédiatement applicables, qui ont un impact mesurable.

ReversingLabs, dans son Software Supply Chain Security Report 2026, identifie cinq priorités opérationnelles : la mise en place d'une nomenclature logicielle (SBOM) dynamique et maintenue à jour, l'adoption systématique de la signature d'artifacts via Sigstore et cosign, la surveillance comportementale des packages post-installation, la mise en place de registres privés miroir pour les dépendances critiques, et la formation continue des développeurs aux techniques d'ingénierie sociale ciblant les mainteneurs de projets open source.

Un problème systémique que les outils seuls ne suffisent pas à résoudre

La multiplication des rapports sectoriels sur la sécurité DevOps depuis 2023 révèle une tension fondamentale : les outils de détection s'améliorent, les alertes sont plus précises, les plateformes SAST/DAST/SCA sont mieux intégrées dans les pipelines, et pourtant les incidents continuent d'augmenter. La raison est simple et difficile à corriger par la technologie seule : la dette culturelle. Dans de nombreuses organisations, la sécurité reste perçue par les équipes de développement comme un frein, une checklist de conformité imposée par la DSI ou les auditeurs, plutôt que comme une propriété intrinsèque du code livré.

L'émergence des assistants de codage basés sur l'IA — GitHub Copilot, Gemini Code Assist, Claude Code — a introduit un nouveau vecteur de risque subtil. Ces outils génèrent du code à partir de patterns statistiques appris sur des milliards de lignes de code, dont une partie contient des pratiques de sécurité obsolètes ou incorrectes. Un développeur qui accepte sans analyse critique une suggestion de son assistant IA peut introduire des secrets hardcodés, des appels non authentifiés à des APIs internes, ou des patterns de validation insuffisants. Le rapport GitGuardian note une corrélation statistique entre l'adoption des outils IA de codage et la hausse des commits contenant des secrets exposés.

Les implications réglementaires de cette situation sont croissantes. En Europe, la directive NIS2 et le Cyber Resilience Act, dont les dispositions principales sont entrées en application progressivement depuis 2024-2025, imposent aux éditeurs de logiciels et aux opérateurs de services numériques des obligations explicites de sécurité tout au long du cycle de développement. Une organisation qui expose des secrets dans un dépôt public accessible, même brièvement, peut potentiellement se trouver en situation de non-conformité vis-à-vis du RGPD si ces secrets permettent d'accéder à des données personnelles. Les équipes juridiques et les DPO doivent être impliquées dans la définition des politiques de secrets management au même titre que les équipes techniques.

La convergence des menaces supply chain, des expositions de secrets et des risques IA dans un même rapport de tendance 2026 reflète la réalité d'une surface d'attaque considérablement élargie avec l'accélération du développement logiciel assisté par IA. Les organisations qui abordent ces risques en silos — une équipe pour le SAST, une autre pour la supply chain, une autre pour les contrôles IA — s'exposent à des angles morts dangereux. Une approche DevSecOps intégrée, où la sécurité est un critère de merge request au même titre que la qualité du code, n'est plus une bonne pratique optionnelle : c'est une nécessité opérationnelle en 2026.

Ce qu'il faut retenir

• 29 millions de secrets hardcodés exposés en 2025 (+34 % en un an, record absolu) : première cause de compromission de code selon GitGuardian — installer un scanner de secrets en pre-commit et en CI est non négociable.
• 581 vulnérabilités open source par application en moyenne, soit le double de 2024 : la gestion du SBOM et la mise à jour des dépendances doivent être automatisées et continues, pas annuelles.
• Les pipelines d'IA générative constituent une nouvelle surface d'attaque non couverte par les standards existants : documenter et tester spécifiquement les risques d'injection de prompt et de fuite de secrets dans les workflows utilisant des LLM.