Une étude Checkmarx / Censuswide révèle que les développeurs interrogés disent être meilleurs en sécurité, avec une compétence plus grande. Mais il y a énorme mais qui pondère ce sentiment d'amélioration : le manque de temps pour être efficace et réellement appliquer le secure by design.

L'étude DevSecOps Evolution : from DevEx to DevSecOps analyse les pratiques des équipes de développement dans les grandes entreprises. L’étude révèle que, malgré une certaine progression, les équipes de développement et de sécurité peinent à aligner flux de travail et métriques associées. Bref : il y a un peu de mieux mais le fossé reste colossal. 

Quelques chiffres qui font réflêchir : 

• 21 % des développeurs interrogés déclarent que la sécurité est leur priorité absolue lors du codage
• 99,6 % des participants ont eu accès à des formations dédiées à la sécurité, 90 % d'entre eux estimant l’efficacité de ces dernières de moyenne ou élevée
•  41,53 % déclarent comprendre les tickets de vulnérabilité qu'ils reçoivent, ainsi que la manière dont ces vulnérabilités se manifestent lors de l'exécution, entre 41 et 60 % du temps
• 72 % des développeurs consacrent plus de 17 heures par semaine à des tâches liées à la sécurité et un sur quatre y consacre plus de 25 heures

Checkmarx préconise 4 étapes pour faire du DevSecOps :

• Étape 0 - Sécurité réactive : l’AppSec est « intégré » au développement, créant un goulot d'étranglement et agissant comme un frein au déploiement.
• Étape 1 - Axé sur la sécurité : l’AppSec détecte et transmet les vulnérabilités aux développeurs, qui sont bombardés d'alertes sans recevoir aucune aide à la remédiation.
• Étape 2 – Axé sur le DevEx : les outils sont directement intégrés à l'environnement de développement (IDE), ce qui permet aux développeurs de corriger les vulnérabilités à l'aide de conseils de remédiation sans perturber leur flux de travail.
• Étape 3 – DevSecOps mature : la culture DevSecOps est désormais solidement ancrée. Les équipes de sécurité et de développement partagent une vision commune en matière de politiques, de gouvernance et de collaboration. La formation, dispensée directement dans l’environnement de développement IDE au moment opportun, assure une montée en compétences ciblée. Par ailleurs, des objectifs clairs et des indicateurs de performance harmonisés permettent de suivre efficacement les progrès.

Un autre élément de l'étude pointe que 28 % du temps consacré à la sécurité sont pour la résolution et la fixation des failles. 45 % du temps est dédié à faire du code sécurisé (reste à savoir où et comment). 

« En 2024, le DevSecOps a connu une phase de transition en France, portée par une prise de conscience croissante et des efforts pour intégrer la sécurité à chaque étape du développement. Pourtant, des défis persistent, notamment le manque de ressources, des budgets contraints et des organisations encore cloisonnées. Si des avancées ont été réalisées, 2025 sera une année clé pour structurer et généraliser durablement le DevSecOps en France face à un cadre réglementaire de plus en plus exigeant. » conclut Fabien Petiau, Country Manager France de Checkmarx.

Pour aller plus loin :

Hors série sécurité & hacking édition 2025 : https://www.programmez.com/magazine/programmez-hors-serie-16-pdf

DevCon sécurité de novembre 2024 : 

Des extensions malicieuses ne sont pas rares sur Visual Studio et Visual Studio Code. Deux extensions douteuses sont apparues ces derniers semaines. Elles ont pour extension .ahban.shiba et ahban.cyhelloworld. Heureusement, les téléchargements ont été très limités avant que Microsoft ne les retire. Visiblement, ces extensions ont réussi à passer les procédures de review avant publication sur la marketplace. Plus étonnant encore, le premier malware semble dater d'octobre 2024 et le second de février 2025. 

ReversingLabs a mis en évidence la présence de commandes Powershell pour charger et exécuter des scripts PowerShell pour installer un ransomware et se connecter à un site illicite. Ces ransomwares ne semblent pas terminer mais peuvent crypter des fichiers et lancer une alerte à l'utilisateur. 

Microsoft a rapidement ordonné le retrait des extensions. 

GitHub subit une vilaine attaque : Actions a été compromis via tj-actions/changed-files. Il permet de détecter les changements sur les fichiers des référentiels. Cette fonction est naturellement très utilisée. Un hacker a réussi à y injecter un code malveillant qui c'est ensuite diffusé dans plus de 23 000 projets. 

L'attaque remonte au 14 mars et même peut-être dès le 11-12 mars selon Sysdig. L'attaque consiste à une altération du code pour pouvoir injecter un code malveillant pour récupérer les secrets et les données des projets. Il s'agit d'une fonction Node en base64. Elle contient des instructions Python. Les secrets incluent les clés d'API, les tokens d'accès. Selon Sysdig, d'autres codes malveillants ont été répérés dans d'autres projets. A l'heure actuelle, l'identité de l'attaquant n'est pas connue ni la motivation de l'attaque. L'attaque consiste à cibler le Personal Access Token (PAT). GitHub cherche à savoir comment une telle compromission a été possible. 

L'auteur de tj-actions/changed-files a confirmé que les mots de passe du compte bot ont été modifiés et que les permissions ont été abaissées pour réduire les risques. Envisagez une alternative à tj-actions/changed-files. 

Cette attaque est référencée : CVE-2025-30066

Mise à jour : Espressif a répondu le 10 mars en publiant un poste sur les supposées portes dérobées. "Récemment, certains médias ont fait état d'un communiqué de presse qui accusait initialement les puces ESP32 d'avoir une « porte dérobée ». Il convient de noter que le communiqué de presse original de l'équipe de recherche de Tarlogic a été corrigé pour supprimer la désignation de « porte dérobée ». Cependant, toute la couverture médiatique n'a pas été modifiée pour refléter ce changement. Espressif souhaite profiter de cette occasion pour clarifier cette question pour nos utilisateurs et partenaires. Les commandes sont là pour le debug et les tests. Elles font parties de l'implémentation Host Controller Interface sur le protocole Bluetooth." En résumé : il s'agit de commandes de debug, sans accès distant, pas d'impact sur la sécurité. Ces commandes ne sont pas présentes sur les gammes 32-C, 32-S et 32-H. En complément, Espressif publie une note complète les commandes Bluetooth : https://developer.espressif.com/blog/2025/03/esp32-bluetooth-clearing-the-air/

Bleepingcomputer.com a publié un article sur des commandes non documentées sur les microcontrôleurs ESP32 fabriqués par Espressif. Pour 2023, plus d'un milliard de puces contiennent ces commandes non officielles (estimation des chercheurs). Ces commandes pourraient permettre de faire un spoofing matériel et permettre des accès non autorisés. Ces commandes ont été dévoilées durant la conférence RootedCON à Madrid. 

Pour les chercheurs, les ESP32 contiennent donc des backdoors pour permettre d'accès aux WiFi et Bluetooth. Des millions d'IoT utilisent ces composants ESP32. Ils sont peu chers et très performants. Des fonctions non documentées ne signifient pas forcément une porte dérobée intentionnelle. Il arrive souvent que des constructeurs ne documentent pas des fonctions ou des commandes pour en éviter leur usage. Les chercheurs ont démontré les vulnérabilités en codant un pilote Bluetooth spécifique pour exploiter ces commandes qui contournent les sécurités. Il permet une attaque brute sur le réseau sans fil de l'ESP. 

Les chercheurs ont mis en évidence 32 commandes qu'ils qualifient de portes dérobées. Bleepingcomputer.com s'interroge, avec raison, sur l'existence de ces commandes :

- des commandes privées qui ne sont pas destinées à être utilisées par les développeurs

- une erreur d'implémentation : ces commandes ont été laissées par erreur. Il arrive que des fondeurs laissent des fonctions non officielles, plus simple que de refaire un design.

Il est difficile de savoir pourquoi ces commandes sont présentées. Espressif a réagi le 10 mars dernier.

L'éditeur Dynatrace lance la solution Observabilty for Developers. Il s'agit d'un ensemble d'outils pour les développeurs afin de fournir un monitoring, une observabilité des environnements en production et améliorer le shift left. "Les environnements cloud modernes devenant de plus en plus complexes, les solutions d’observabilité sont devenues indispensables pour les développeurs. Avec des systèmes de plus en plus distribués et dynamiques, les équipes de développement ont besoin d’informations en temps réel sur les performances des applications, l’état de santé de l’infrastructure et les expériences utilisateurs, afin de maintenir le niveau de fiabilité tout en développant l’innovation." explique d'éditeur. 

Dynatrace rassemble dans une solution les tableaux de bord et les logs, un outil de debug temps réel (Live Debugger) pour faciliter l'analyse et la découverte des bugs. Pour nous aider, l'éditeur propose Davis AI qui sera votre Copilot pour trouver les dysfonctionnements et bugs. 

Des plugins pour Jetbrains et Visual Studio Code sont disponibles. 

BreizhCTF revient les 14 et 15 mars à Rennes. Il s'agit d'une compétition de sécurité. Plus de 600 hackers éthiques sont attendus. Le BreizhCTF rassemble aussi entreprises, startups, institutions étatiques, écoles et universités, étudiants, collégiens et lycéens pour ouvrir la porte de la cyber au plus grand nombre et susciter des vocations. L’objectif : fédérer la communauté cyber et répondre aux besoins en formation, en emploi et en compétences de la filière, faisant de cet événement un événement d’utilité publique face aux enjeux cyber.

Le format change pour la 9e édition : la compétition aura lieu en journée, le samedi. Au programme : un “Hack&Teens” pour faire découvrir la cyber aux collégiens et lycéens et un “Hack&Job” pour répondre aux besoins RH de la filière. 

Site : https://www.breizhctf.com/

GitHub annonce deux nouvelles fonctions pour les développeurs : Secret Protection et Code Security. Il s'agit d'une modification de GitHub Advanced Security. Jusqu'à présent, ces outils étaient liés à Advanced Security. A partir du 1er avril, ils seront disponibles en dehors de cette offre. 

En résumé :

• GitHub Secret Protection : les fuites de secrets constituent un défi de grande ampleur ; rien qu'en 2024, plus de 39 millions de secrets ont été détectés dans les référentiels GitHub. Secret Protection détecte et empêche les fuites de secrets avant qu'elles ne se produisent grâce à une protection push, une analyse des secrets, une détection basée sur l'IA avec un faible taux de faux positifs, des informations sur la sécurité, etc. 19 $ / mois / par committer

• GitHub Code Security : cette solution aide à identifier et à corriger plus rapidement les vulnérabilités grâce à l'analyse de code, à Copilot Autofix, aux campagnes de sécurité, à Dependency Review Action, etc. 30 $ / mois / par comitter

• disponibilité d'un outil d'évaluation des risques liés aux secrets, Security tab : outil gratuit

Stroustrup appelle la communauté C++ à défendre le langage depuis les polémiques des agences de sécurité et de la maison blanche. C++ est devenu une cible de choix de nombreux experts en sécurité et d'éditeurs : C++ n'est pas assez sécurisé, utiliser Rust ! En cause, la difficulté à bien utiliser la gestion mémoire et la notion de safe / unsafe et de la memory safe. 

Depuis, plusieurs propositions ont été lancées pour faciliter la sécurité par design dans le langage : TrapC, FilC, MiniC, Safe C++, etc. Mais le travail avancerait trop lentement pour le créateur du langage. Dans une note pour le comité de standarisation du 7 février, Bjarne appelle à agir rapidement et à mieux défendre C++. Le WG21 doit agir de manière significative. Il rappelle que le memory safe est un sujet crucial. 

Quelques jours plus tard, il évoque la réelle menace sur C++ des dernières directives des agences américaines sur l'obligation des constructeurs de proposer une approche memory safe dans les roadmaps produits. En arrière-plan, il y a aussi l'appel de Mark Russinovich (Microsoft Azure) à utiliser uniquement Rust pour les nouveaux projets. Au-delà, il y a une réelle question : une dépréciation C et C++ dès 2026 dans agences américaines. 

Bjarne supporte les safety profiles dans le langage. Ce framework devrait intégrer le standard C, C++ mais le processus d'intégration est long. Pourquoi pas assurer une intéropérabilité avec Rust le temps de simplifier le memory safe ? 

Sniffnet est un outil permettant de surveiller l'activité du trafic internet mais avant tout c'est un outil de monitoring de réseau pour comprendre et surveiller ce qu'il se passe. On peut appliquer des filtres, voir les statistiques, les logs, avoir le trafic en temps réel, exportation les données, identifier les connexions à son réseau local, etc. 

L'outil est open source, écrit en Rust et disponible sur Linux, macOS et Linux. On peut l'installer directement dans le Terminal ou pour l'installeur. L'interface est plutôt simple à prendre en main et les métriques sont bien visibles et compréhensibles. 

Site : https://sniffnet.net/

Question qui revient souvent : les apps mobiles sont-ils sécurisées ? Les équipes du zLabs de Zimperium ont publié une étude sur cette question. Malheureusement, de nombreuses apps disponibles sur l'AppStore et Play, possèdent toujours de vulnérabilités ou sont elles-mêmes de fausses apps. Le comportement de certaines apps est pointé du doigt : pourquoi une messagerie prendrait une copie d'écran sans notifier l'utilisateur ? Pour accéder au presse-papiers ? Pourquoi les OTP sont stockés alors qu'ils sont normalement à usage unique ?

Le constat est amer : le simple fait de télécharger depuis un appstore officiel, même une application très populaire, n'est pas une garantie de sécurité.

"L’analyse des 50 applications les plus téléchargées sur l’App Store d’iOS et le Play Store d’Android dans les catégories Productivité, Affaires et Finance révèle qu’au moins une application par catégorie présente un score élevé de vulnérabilité en matière de sécurité ou de confidentialité. Ces résultats mettent en évidence des failles récurrentes dans la gestion de la sécurité et de la confidentialité des applications les plus utilisées, soulignant ainsi la nécessité d'un contrôle rigoureux en entreprise." commente le rapport. 

Une application de messagerie populaire : commodité vs sécurité

L’analyse d'une application de messagerie largement utilisée a révélé d'importants problèmes de sécurité et de confidentialité. Ses demandes excessives d’autorisation, notamment l'accès à la caméra, au microphone et aux services de localisation, vont bien au-delà des besoins d'une application de messagerie. De plus, elle a un accès illimité au presse-papiers du téléphone, ce qui peut exposer des informations sensibles comme des mots de passe ou des données confidentielles copiées par l’utilisateur. Elle dispose également d'une fonctionnalité permettant d’effectuer des captures d'écran, pouvant ainsi surveiller toutes les interactions de l'utilisateur avec l’application. En matière de sécurité, l'application présente des faiblesses dans son architecture. Un attaquant pourrait exploiter ces failles pour injecter du code malveillant, transformant ainsi l’application de messagerie en un outil sophistiqué de surveillance.

"Bien que les applications iOS présentent généralement moins de vulnérabilités liées aux fuites de données que leurs équivalents Android, elles souffrent davantage de faiblesses cryptographiques. Ce constat met en évidence un compromis fondamental entre les plateformes : si iOS applique des contrôles de confidentialité plus stricts dans certains domaines, la sécurisation cryptographique reste un enjeu majeur." poursuit le rapport. 

Depuis 2 ans, les paquets Python malveillants se multiplient sur PyPi. Les hackers utilisent des noms très proches pour provoquer une confusion et l'utilisateur installe le mauvais paquet ou des paquets officiels sont purement et simplement remplacés par de faux paquets. 

Le projet Quarantine (quarantaine) doit permettre aux administrateurs PyPi d'isoler un paquet incertain ou identifié comme malveillant. L'objectif est que les administrateurs PyPi disposent de rapports d'analyse sur les paquets et, si un paquet s'avère douteux, ils peuvent isoler le ou les paquets et toutes leurs versions liées. La suppression complète des paquets sera possible ainsi que le bannissement du nom du paquet. Les auteurs de Quarantine sont conscients que la suppression totale d'un paquet peut gêner les développeurs et les utilisateurs. Les créateurs des paquets seront prévenus et la procédure d'exclusion lancée.

Plus un paquet malveillant reste disponible longtemps, plus il risque de se propager. Depuis que le projet est déployé, plus de 140 paquets ont été identifiés et isolés. Un projet a été réintégré, tous les autres ont été supprimés de PyPi.

Pour en savoir plus : https://blog.pypi.org/posts/2024-12-30-quarantine/

Par Jason Merrick, SVP des produits chez Tenable

Avec l'adoption croissante du cloud par les entreprises, la sécurité de celui-ci est devenue une priorité absolue. Toutefois, entre les environnements multi-cloud, les configurations complexes, les cycles de développement rapides et la méconnaissance, voire le désintérêt, des développeurs pour la cybersécurité, la protection des infrastructures cloud est un véritable parcours du combattant. C’est là que les Cloud-Native Application Protection Platform (CNAPP) apportent une réponse globale, en facilitant une sécurité de bout en bout, du développement à la production. Elles permettent aux développeurs de travailler librement tout en assurant aux administrateurs une tranquillité d'esprit. Pour être efficaces, elles doivent cependant répondre à des critères clés et suivre les meilleures pratiques permettant de sécuriser chaque étape du cycle de vie des applications.

Légende : Intégration d’une CNAP avec AWS

Une visibilité complète grâce à une intégration profonde

Une CNAPP efficace commence par établir une connexion directe avec les API des principaux fournisseurs cloud comme Azure, AWS, GCP et OCI. Cette intégration permet une visibilité complète sur toutes les ressources cloud, y compris les workloads, les identités, les configurations réseau et les données. Grâce à cette vue d’ensemble, les organisations peuvent identifier rapidement des configurations inadéquates, des autorisations excessives et d’autres vulnérabilités qui pourraient compromettre leur environnement. Par exemple, pour AWS, il est possible de choisir entre deux modes de connexion : en "frictionless" via AWS Systems Manager Inventory et AWS Systems Manager Agent (SSM Agent), ou en utilisant le cloud connector d’AWS.

Une gestion proactive des risques via le CSPM

Une fois l’infrastructure connectée, la plateforme CNAPP repose sur deux piliers essentiels pour la gestion des risques cloud. Premièrement, le Cloud Security Posture Management (CSPM) scanne en permanence les configurations pour identifier les violations de conformité avec des standards comme le RGPD, ISO 27001 ou les benchmarks CIS. Cela garantit que les environnements respectent les meilleures pratiques en matière de sécurité. La plateforme s’interconnecte en mode sans agents avec les fichiers de configuration des infrastructures en production pour les comparer à ses bases de données de vulnérabilités et de bonnes pratiques.Le Cloud Infrastructure Entitlement Management (CIEM) analyse les permissions des identités (humaines ou machines) pour réduire les risques liés à des autorisations excessives ou inutilisées. Il permet d’appliquer des politiques d’approvisionnement "juste-à-temps" et de moindre privilège, limitant ainsi les possibilités d'accès non autorisés. L’objectif du CIEM est de minimiser les risques sans compromettre la productivité des utilisateurs.

Uniformisation au service d’une CNAPP et d’un CSPM plus intelligents

Le défi principal dans la sécurisation de l'Infrastructure as Code (IaC) réside dans le manque de standardisation des définitions d'infrastructure. Par exemple, le YAML de Kubernetes est différent du HashiCorp Configuration Language (HCL) utilisé pour Terraform. Ce manque d'uniformité complique l'évaluation et la réduction des risques. La seule manière évolutive d'obtenir de la cohérence est de normaliser les types d'IaC dans un format uniforme (Cloud as Code).Une fois les définitions d'infrastructure normalisées, des vérifications basées sur des politiques (Policy as Code) peuvent être appliquées pour identifier les violations de bonnes pratiques en matière de conformité ou de sécurité. Les solutions CSPM doivent examiner le code tout au long de son développement, sans entraver le flux de travail et l'agilité des développeurs. Open Policy Agent (OPA) est désormais le standard pour l'application des politiques. Les moteurs de politiques basés sur Python, par exemple, sont peu maniables par rapport à ceux basés sur OPA, qui utilisent le langage de requête Rego.

Une sécurité avancée pour Kubernetes

Les environnements Kubernetes, essentiels à la modernisation des infrastructures, introduisent également des défis uniques en termes de sécurité. Une CNAPP doit simplifier leur gestion grâce à une surveillance continue des ressources Kubernetes, comme les nœuds, les namespaces et les comptes de service, tout en détectant les configurations non conformes aux standards de sécurité, tels que les benchmarks CIS pour Kubernetes.

L’automatisation au service de la sécurité

Au-delà du monitoring, la force d’une CNAPP réside dans son approche automatisée de la remédiation. Lorsqu’une vulnérabilité ou une configuration incorrecte est détectée, plusieurs solutions sont possibles. Il est possible d’appliquer des correctifs automatisés intégrés dans des outils comme Terraform et CloudFormation via une intégration fluide avec des plateformes comme Jira, Slack ou ServiceNow, et des guides de correction manuelle lorsque l’automatisation n’est pas souhaitée. Cette flexibilité garantit que la sécurité ne freine pas les cycles de développement rapide.

La plupart des développeurs ne sont toutefois pas des experts en sécurité et manquent des connaissances nécessaires pour remédier aux mauvaises configurations détectées dans l'IaC. Les workflows de remédiation doivent ainsi avoir la capacité de s'intégrer à ceux des développeurs. La seule approche scalable est une solution CSPM qui génère automatiquement le code nécessaire pour résoudre les mauvaises configurations et qui crée des pull requests contre la branche principale (Remédiation en tant que Code). 

Légende : Exemple d'alerte fournie par une CNAPP concernant un conteneur vulnérable.

Assurer une remédiation plus efficace et sécuritaire en production

La plus grande distinction entre les solutions CSPM de première génération et celles de nouvelle génération réside dans leur approche de la remédiation des erreurs qui se produisent sur la production. Les solutions CSPM de première génération offraient des capacités de remédiation pour traiter un ensemble limité de risques en modifiant automatiquement les configurations en temps réel. Cette approche était toutefois risquée. Elle nécessite d’abord que l'outil CSPM soit autorisé à mettre à jour les environnements en temps réel, ce qui peut être contraire à la politique de sécurité. Ensuite, autoriser un outil à apporter des modifications automatiques aux configurations de l'infrastructure en temps réel introduit le risque d'un éventuel temps d'arrêt. Et plus important encore, toute modification apportée aux configurations d'infrastructure en temps réel crée une dérive par rapport à la base de référence de l'IaC. Cela signifie que si l'infrastructure est redéployée à partir de l'IaC, le changement effectué en temps réel sera perdu.

Les solutions CNAPP de nouvelle génération établissent quant à elle l'IaC comme la seule source de vérité. Par exemple, quand un ingénieur augmente la configuration de la mémoire d'une instance de calcul en temps réel pour améliorer les performances d'une application, le changement de configuration n'introduit pas de risque, mais l'IaC correspondant doit être mis à jour pour refléter ce changement. Cela permet d’établir une nouvelle base de référence.En cas de configuration risquée, comme la création accidentelle d'une règle dans une table de routage exposant un sous-réseau privé à Internet, la plateforme génère automatiquement le code nécessaire pour corriger la configuration. Les opérations peuvent ensuite redéployer l'infrastructure en utilisant le code mis à jour et éliminer les risques.En réunissant des outils de gestion des risques, de remédiation et de conformité dans une seule plateforme, la CNAPP réduit la complexité des environnements multi-cloud. Elle permet aux développeurs d’innover rapidement tout en assurant aux équipes SecOps un contrôle continu sur la sécurité des environnements cloud.

Légende : Des outils open-source gratuits comme Terrascan offrent aux développeurs un moyen simple de se familiariser avec les tests de Policy as Code (PaC) pour l'Infrastructure as Code (IaC).