Discussion :

[Sandra Coret]

81 % des équipes de développement admettent avoir sciemment mis en ligne du code vulnérable, 20 % des cadres supérieurs reconnaissant même le faire souvent, selon un rapport d'Immersive Labs

Le rapport d'Immersive Labs, qui s'appuie sur les travaux d'Osterman Research, révèle un manque de confiance dans la sécurité des applications en général.

En effet, la moitié seulement des responsables de la sécurité des systèmes d'information pensent qu'il est possible de développer des applications sécurisées et 44 % seulement des équipes de sécurité pensent que leur entreprise pourrait résister à une attaque de type SolarWinds sur leur environnement de développement.

Sur les 260 équipes de sécurité et de développement interrogées, seules 39 % des équipes de sécurité déclarent disposer de suffisamment de temps et de ressources pour prendre en charge le "virage à gauche" nécessaire au développement d'un code sécurisé. Et seulement 54 % des équipes de sécurité interrogées pensent que les développeurs comprennent les dernières menaces qui pèsent sur la sécurité des applications.

Seulement 27 % des équipes de développement de première ligne considèrent que la sécurité est leur responsabilité, alors que 80 % de leurs cadres supérieurs pensent que c'est le cas, ce qui montre une déconnexion inquiétante. La moitié seulement des équipes chargées de la sécurité proposent des formations aux équipes chargées de la sécurité des applications tous les trimestres ou plus régulièrement, et 50 % d'entre elles affirment que ces formations sont toujours dispensées en classe. En conséquence, 45 % des équipes de développement estiment que leur compréhension des dernières attaques applicatives est insuffisante.

"La sécurisation des applications est peut-être le plus grand problème de sécurité auquel les organisations sont confrontées aujourd'hui", déclare James Hadley, PDG d'Immersive Labs. "Comme pour tout ce qui concerne la cybersécurité, le faire est autant un défi humain que technique. Les relations que les gens entretiennent, le stress qu'ils subissent, le développement personnel dont ils bénéficient et la culture qui les lie sont aussi importants que n'importe quelle contre-mesure électronique. Pour améliorer cela, le partage des informations et la progression personnelle par le développement des compétences sont cruciaux. Chez Immersive Labs, nous en sommes conscients et nous l'avons placé au centre d'une nouvelle plateforme conçue pour améliorer progressivement les compétences des équipes de développement – ce qui permet d'intégrer la sécurité dès le départ."

Source : Immersive Labs

Et vous ?

Que pensez-vous des résultats de ce rapport ?
D'après votre expérience, le trouvez-vous pertinent ou pas ?

Voir aussi :

Une vulnérabilité du kernel Linux expose la mémoire et provoque des fuites de données, alors que des discussions se poursuivent sur la prise en charge de Rust pour le développement du noyau Linux

La nouvelle plateforme DoControl aide les entreprises à prévenir les violations des applications SaaS

[Astraya]

Et c'est pas prêt de changer. La priorité des chef de projet et autres directeurs est de livrer au plus vite pour soit appâter le chaland soit pour faire plaisir aux clients.
Quand je vois que l'on prend à peine le coche de l'intégration continue dans certaines boîtes... Alors du code sans faille...

[walfrat]

Ce titre frôle la diffamation en faisant de nous de parfait bouc émissaire et en nous déléguant toute la responsabilité de la sécurité quand il n'y a aucun financement pour actuellement faire des revues de code,...

Un titre plus correct serait : "81% des ingénieurs sont payés pour livrés des features et pas du code secure et en sont parfaitement conscient".

[marsupial]

La cybersécurité est un métier à part entière. Si les gouvernement prônent le zero trust, les moyens mis en face sont insuffisants pour mettre en place une équipe dédiée à chaque projet pour gérer la sécurité. Il ne s'agit pas de clouer au pilori les développeurs mais les décideurs en haut lieu ne gérant pas les budgets adéquats pour palier au résultat de cette étude. De plus, les ressources humaines manquent à l'appel. De ces faits, je ne comprends pas le pouce rouge pour cette news.

D'après votre expérience, le trouvez-vous pertinent ou pas ?

D'après ma maigre expérience en tant que chef de projet d'une solution de sécurité, la patience était inversement proportionnelle aux ressources humaines allouées. Et encore, j'estime avoir été bien loti comparativement à d'autres qui n'ont même pas ce genre de travail à réaliser. Au moins, la conscience de la nécessité de sécuriser était présente alors qu'à l'époque, l'innovation à la mode était au cloud et à l'intelligence artificielle.

[Invité]

Le développement est une activité largement sous-traitée et tertiarisée. Côté donneurs d'ordre, l'intérêt des utilisateurs finaux n'est pas pris en compte quand il s'agit de décider des budgets et à quelle société attribuer les appels d'offre, dont on ne s'assure jamais de la compétence. Et les responsables IT ne connaissent tout simplement pas les produits vendus par leur entreprise. Dans ces conditions, la qualité du travail rendu n'est pas la priorité, loin de là.

Dernier exemple en date dans ma société, le top management a décidé qu'il fallait remettre au goût du jour une application interne développée en Delphi travaillant de concert avec des progiciels Windows, via leurs serveurs COM. La base choisie pour la nouvelle application est NodeJS dans un Cloud Azure. Avant même d'avoir pu présenter quoique ce soit, tous le budget à été consommé pour coder ce que faisaient les dits serveurs COM. Mon entreprise a dû acheter des nouvelles licences réseau pour les dits progiciels (plus de 100000€) afin de faire fonctionner le bouzin. A ce jour, rien de fonctionnel n'a été présenté. La société sous-traitante a finalement été virée du projet, mais notre responsable IT groupe n'a pas été inquiété pour autant malgré cette débâcle.

[Mingolito]

Cette étude est parfaitement pertinente, explication : Un tiers des travailleurs du secteur des technologies admettent ne travailler que 3 à 4 heures par jour à part une poignée de vrai bosseurs, le plus gros des développeurs en France sont des gros feignants qui préfèrent largement passer 70% de leurs heures de travail à jouer à des jeux vidéos à ou surfer sur des sites pornos plutôt que de se former à sécuriser leur code.
Au lieu de ça certains font du code obfusqué, donc illisible sauf par eux pour être bien sur de ne pas se faire virer même en ne foutant rien.
C'est tout à fait normal que les développeurs en France soient sous payés vu qu'ils bossent que 30% du temps, et que les manager soit largement sur payés car manager cette bande de tire-au-flanc juste bon à faire l'apéro tous les jours c'est un cauchemar. Ca arriverais pas au Japon ou il y a de vrais développeurs travailleurs et honnêtes.

[Bruno]

81 % des développeurs admettent avoir publié sciemment des applications vulnérables,
selon Immersive Labs

Dans un rapport intitule « Imperfect People, Vulnerable Applications » publié par Immersive Labs, une société de services informatique, l’entreprise révèle que les développeurs publient sciemment un nombre important d'applications vulnérables. « La grande majorité des développeurs des grandes entreprises, en particulier les cadres supérieurs, choisissent de mettre en ligne des applications qu'ils savent non sécurisées », déclare Immersive Labs dans le rapport. « Les équipes de sécurité ont peu confiance dans le cycle de vie du développement logiciel (SDLC). Seule une minorité d'équipes de sécurité pense que leur environnement de développement d'applications pourrait résister à une attaque similaire à celle de SolarWinds », indique le rapport.

Pour parvenir à leur conclusion, Immersive Labs a interrogé des développeurs d'applications et des professionnels de la sécurité les résultats ont révélé des problèmes importants. Selon Immersive Labs, l’enquête a permis de déterminer qu’une majorité inquiétante des équipes de développement des grandes entreprises interrogées publient sciemment des applications vulnérables dont le code n'est pas sécurisé (81 %). Pour les développeurs interrogés en tant que groupe unique, plus de la moitié d'entre eux publient "parfois" ou "souvent" du code non sécurisé.

Les ingénieurs de développement seniors avec les rôles de chef de DevOps et responsable du développement qui ont la responsabilité globale du SDLC sont deux fois plus susceptibles que les équipes de développement de première ligne de publier "souvent" du code non sécurisé. Les vulnérabilités constituant l'une des principales voies d'entrée pour les cybercriminels, cela souligne un problème à grande échelle pour les équipes de sécurité.

Pourcentage des personnes interrogées (uniquement les promoteurs)

Selon une autre étude publiée par Dynatrace, les RSSI sont de plus en plus préoccupés par le fait que l'adoption croissante des architectures natives du cloud et des pratiques DevSecOps pourrait avoir brisé les approches traditionnelles de la sécurité des applications. L'étude révèle que 89 % des RSSI pensent que les microservices, les conteneurs et Kubernetes ont créé des angles morts en matière de sécurité des applications. En outre, 71 % d'entre eux admettent qu'ils ne sont pas totalement convaincus que le code est exempt de vulnérabilités avant sa mise en production.

En outre, l'enquête mondiale menée auprès de 700 RSSI montre que 97 % des organisations ne disposent pas d'une visibilité en temps réel des vulnérabilités d'exécution dans les environnements de production conteneurisés. Près des deux tiers (63 %) des responsables de la sécurité informatique affirment que les méthodes DevOps et le développement agile ont rendu plus difficiles la détection et la gestion des vulnérabilités logicielles, et 74 % déclarent que les contrôles de sécurité traditionnels, tels que les scanners de vulnérabilités, ne sont plus adaptés à l'univers natif du cloud.

Environnements de construction non sécurisés

Moins de la moitié soit 44 % des professionnels de la sécurité interrogés dans le cadre de cette étude pensent que leurs applications sont suffisamment sécurisées pour résister à un cybercriminel spécialisé. En fonction de leur rôle, les équipes de sécurité de première ligne sont beaucoup moins susceptibles de considérer l'environnement de développement comme fiable que les responsables de la sécurité.

Pourcentage des personnes interrogées (uniquement les spécialistes en sécurité)

Le nombre de professionnels du développement qui pensent que leur environnement est suffisamment sécurisé est plus élevé que celui des professionnels de la sécurité, bien que la même variation existe entre les ingénieurs de développement seniors et le personnel de développement de première ligne. Pour les deux groupes, les faibles chiffres indiquent un état d'impréparation et une cible majeure pour les cybercriminels.

Pourcentage des personnes interrogées (uniquement les développeurs)

Faible capacité à développer des applications sécurisées

En général, seuls 56 % des professionnels de la sécurité interrogés dans le cadre de cette étude se sont dits confiants que les équipes de développement et d'ingénierie de leur organisation pouvaient développer des applications sécurisées. Par rôle, les RSSI ont le niveau de confiance le plus faible par rapport aux deux autres groupes de professionnels de la sécurité. Des exemples de ce faible niveau de confiance ont été exprimés à travers de multiples questions d'évaluation, portant sur :

• la résistance aux attaques ciblées : seuls 54 % des RSSI pensent que les applications développées par leur organisation résisteraient à une attaque ciblée ; les équipes de sécurité de première ligne expriment encore moins de confiance, avec seulement 44 % des réponses favorables ;
• les équipes de sécurité face aux attaques de bas niveau : seuls 63 % des RSSI pensent que les applications développées par leur organisation pourraient résister à une attaque de bas niveau. La confiance des équipes de sécurité de première ligne est plus faible, avec 50 % des répondants ;
• les équipes DevOps ont exprimé un niveau de confiance plus élevé dans leurs capacités de sécurité par rapport aux spécialistes en sécurité. Par exemple :
• les développeurs sur la résistance aux attaques ciblées 66 % des personnes interrogées se sentent confiantes dans le fait que les applications développées par leur organisation pouvaient résister à une attaque ciblée. Ce taux de confiance est presque 30 % plus élevé que celui des personnes interrogées sur la sécurité ;
• les développeurs face aux attaques de bas niveau : 69 % des personnes interrogées sont convaincues que leurs applications peuvent résister à une attaque de bas niveau, soit un taux de confiance supérieur de 13 % à celui des personnes interrogées sur la sécurité.

D'après une enquête de Versa Networks, l'adoption des Secure Access Service Edge (SASE) a augmenté pendant la pandémie, 34 % des entreprises déclarant les avoir adoptées au cours de l'année écoulée, et 30 % supplémentaires prévoyant de le faire dans les six à douze prochains mois. Malgré cette adoption rapide, la majorité (69 %) des professionnels de l'informatique et de la sécurité interrogés par Versa Networks ne savent toujours pas ce qu'est réellement le SASE. L'étude menée par Sapio Research auprès de 500 décideurs en matière de sécurité et d'informatique travaillant dans des moyennes et grandes entreprises aux États-Unis, au Royaume-Uni, en France et en Allemagne, révèle que 84 % des entreprises ont accéléré leur transformation numérique et leur passage au cloud pendant la pandémie, et que 44 % des entreprises pensent que leurs employés continueront à travailler à distance, à temps plein ou à temps partiel, une fois les restrictions liées à la pandémie levées.

Quand la sécurité doit-elle être prise en compte pour la première fois dans le SDLC ?

Le fait de traiter la sécurité comme un ajout aux projets de développement d'applications logicielles a été impliqué dans la publication de code non sécurisé. Beaucoup pensent qu'un SDLC sécurisé est un SDLC qui est conscient de la multitude d'éléments humains complexes. Au lieu d'écrire un énième article soulignant une dynamique difficile entre les équipes de sécurité et de développement, Immersive Labs a voulu pousser plus loin l'analyse de la situation pour comprendre les facteurs qui contribuent à cet écart. Trois thèmes principaux qui se dégagent des résultats de l’enquête et auraient un impact bénéfique sur les éléments humains qui augmentent actuellement le risque dans le SDLC s’ils étaient améliorés.

La recherche a mis en évidence une aspiration à réaliser le virage à gauche afin d'intégrer plus tôt la sécurité dans le SDLC. Les équipes de sécurité sont plus enthousiastes que leurs homologues développeurs, mais dans les deux groupes, l'opinion dominante est que plus la sécurité est prise en compte tôt, plus les risques de l'application sont faibles. Cependant, cette volonté de se déplacer vers la gauche est actuellement entravée par le fait que les équipes de sécurité et de développement sont limitées par un manque de temps et de ressources. Les points de données de l'analyse qui mettent en évidence cette lacune sont les suivants :

• manque de temps et de ressources, seuls 39 % des personnes interrogées en matière de sécurité ont déclaré que leur équipe disposait de suffisamment de temps et de ressources pour prendre en charge les besoins en sécurité ;
• pas assez de temps et de ressources pour traiter les vulnérabilités prioritaires seule la moitié des personnes interrogées sur la sécurité s'accordent à dire qu'elles disposent de suffisamment de temps et de ressources pour traiter les vulnérabilités prioritaires sur les applications. En d'autres termes, la capacité d'aborder les problèmes de sécurité actuels et connus manque cruellement de ressources ;
• pas de temps pour travailler avec l'équipe de développement seuls 44 % des répondants en matière de sécurité ont déclaré avoir le temps nécessaire pour aider l'équipe de développement à sécuriser les applications.

Lorsque ces points de données sont ventilés par rôle, le premier et le second ont été davantage ressentis par les équipes de sécurité de première ligne que les professionnels de la sécurité senior. Il semblerait que ces derniers croient en quelque chose de vrai que le personnel de première ligne ne vit pas en pratique.

Pourcentage des personnes interrogées (uniquement les répondants de sécurité)

Les développeurs en général étaient plus susceptibles que leurs homologues de la sécurité de dire qu'ils disposent de suffisamment de temps et de ressources pour accomplir leurs tâches. Cela semble indiquer que les équipes de sécurité sont plus sollicitées par les ressources. Il y a un écart notable entre les évaluations fournies par les personnes interrogées dans des rôles supérieurs et celles des équipes de première ligne. Ceci est vrai pour les groupes de sécurité et de développeurs. Il faut s'y attendre, car les responsabilités diffèrent, mais les écarts indiquent que les personnes qui créent les applications elles-mêmes ont le niveau le plus bas d'appropriation personnelle de la sécurité, un niveau de responsabilité plus faible sécurité, ainsi qu'une mauvaise compréhension des dernières menaces pour la sécurité des applications. Pour les développeurs qui se sont prêtés à l’enquête, les points de données spécifiques comprenaient :

• faible appropriation de la sécurité par les développeurs de première ligne : seuls 27 % des développeurs de première ligne considèrent la sécurité des applications comme une part essentielle de leurs responsabilités. En comparaison, 80 % des personnes interrogées des deux rôles supérieurs sont de cet avis. Il y a un problème lorsque ceux qui sont au cœur du développement ressentent une si faible appropriation de la sécurité ;
• la sécurité ne devrait pas faire partie du SDLC : seuls 55 % des développeurs de première ligne sont d'accord pour dire que les considérations de sécurité devraient faire partie du SDLC, contre 66 % des personnes interrogées ayant le rôle de responsable du développement et 85 % le rôle de chef de projet. Cela témoigne de la nécessité d’une plus grande sensibilisation à la sécurité dans le SDLC par l'éducation et la formation ainsi que de meilleurs outils et une intégration plus étroite avec les équipes de sécurité ;
• comprendre les nouvelles menaces pour la sécurité des applications : alors que 80 % des personnes interrogées dans le rôle de responsable DevOps ont déclaré comprendre les dernières menaces pour la sécurité des applications, seuls 64 % des programmeurs en disent autant. Ce qui est compris par les professionnels de haut niveau ne se répercute pas efficacement sur la ligne de front.
• manque d'informations en première ligne : par rapport aux responsables DevOps, les développeurs de première ligne sont deux fois moins nombreux à reconnaître qu'ils ont accès en temps voulu aux informations de sécurité pour les aider à créer des applications sécurisées (respectivement 63 % et 36 %). Les responsables du développement se situent à mi-chemin (49 %).

Les personnes interrogées sur la sécurité ont également fait preuve d'un écart de rôle similaire, par exemple, seule la moitié du personnel de sécurité de première ligne considère la protection des applications comme une part essentielle de ses responsabilités, contre 73 % pour les directeurs de la sécurité et 76 % pour les RSSI.
Les professionnels de la sécurité senior jouent un rôle plus actif dans la sécurisation des applications que le personnel de première ligne, 69 % des RSSI et 76 % des directeurs de la sécurité. Seulement 56 % des praticiens de la sécurité. Le personnel de sécurité de première ligne est moins nombreux à avoir accès aux renseignements sur les menaces pour améliorer la sécurité des applications que les professionnels de haut niveau. 50 % des spécialistes de la sécurité, 61 % des directeurs et 70 % des RSSI.

Source : Immersive Labs

Et vous ?

Quel est votre avis sur le sujet ?

89 % des RSSI pensent que les microservices, les conteneurs et Kubernetes ont créé des angles morts en matière de sécurité des applications, selon une récente étude de Dynatrace

69 % des professionnels de l'informatique et de la sécurité ne maîtrisent pas les SASE (Secure Access Service Edge), mais tiennent tout de même à les adopter, d'après une enquête de Versa Networks

Sécurité : seuls 7 % des responsables rendent compte au PDG, 53 % affirment que leurs dirigeants ne comprennent pas leur rôle et 51 % pensent qu'ils manquent de soutien de la part des dirigeants

80 % des organisations qui ont payé la rançon après une attaque par ransomware ont été frappées à nouveau, d'après une nouvelle étude de Cybereason

[walfrat]

Je ne vois pas où est le problème.

Que les développeurs sachent que ce qu'ils ont fait peut résister à des bots éventuellement mais pas a une attaque ciblé d'un spécialiste n'est pas un problème, c'est de la lucidité pur et simple.

Tout les conseils de sécurité qu'on peut généralement trouvé sur le net à partir du quel un développeur lambda peut faire des efforts sur la sécurité de son application c'est avant tout pour lutter contre les tentatives automatisées tel que le déni de service, les attaques par dictionnaires, certainement pas contre une équipe de hackeur financé par un état.

Je voudrais bien savoir pourquoi on a des équipes de sécurité qui publient des rapports aussi débiles ? Ils vendent des formations pour faire de ton équipe des roxxors de la sécurité en 3 mois ?


XKCD References :

https://xkcd.com/538/ (ou https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis)
https://xkcd.com/2176/
https://xkcd.com/932/

[Sandra Coret]

70 % des développeurs achèvent "fréquemment" ou "toujours" des projets sans effectuer toutes les étapes de sécurité, en raison des délais serrés et de la pression d'innovation, selon Invicti Security

Le rapport d'Invicti Security montre également que 78 % des personnes interrogées dans le domaine du développement et de la sécurité ont subi une augmentation de leur niveau de stress cette année et que 73 % ont envisagé de quitter leur emploi à cause de cela.

Malgré la réputation bien connue de frictions entre les deux groupes, 76 % des personnes interrogées estiment qu'elles partagent une passion commune pour la sécurité et qu'elles travaillent comme une seule équipe qui collabore souvent pour résoudre les problèmes de sécurité. En comparaison, seulement 17 % des personnes interrogées qualifient leur relation d'"ennemie" et 7 % d'"étrangère".

Selon les personnes interrogées, il faudrait en moyenne deux semaines par membre de l'équipe pour traiter l'arriéré actuel de problèmes de sécurité de leur organisation - et ce, s'ils ne travaillent pas sur autre chose. En outre, 78 % des personnes interrogées déclarent être obligées de procéder à une vérification manuelle des vulnérabilités, toujours ou fréquemment. Les faux positifs jouent un rôle dans cette situation, 96 % d'entre eux déclarant qu'ils sont problématiques dans leur organisation et 39 % affirmant qu'ils augmentent les frictions entre les développeurs et la sécurité. Lorsqu'on leur demande ce qu'il faudrait faire pour résoudre ce problème, 60 % d'entre eux citent une automatisation accrue et 99 % davantage d'intégrations.

"Bien que l'on reconnaisse de plus en plus que la sécurité doit être un élément central de l'innovation, les organisations continuent de lutter pour réaliser cette vision", déclare Mark Ralls, président et COO d'Invicti. "C'est aux dirigeants de donner le ton du haut vers le bas et d'impulser des changements de culture qui mettent davantage l'accent sur la sécurité tout en équipant les équipes d'outils et de flux de travail puissants dont ils ont besoin pour faire de l'innovation sécurisée une réalité."

Source : Invicty

Et vous ?

Que pensez-vous de ce rapport ? le trouvez-vous pertinent ?
En tant que développeur, êtes-vous parfois obligé de sauter des étapes de sécurité pour achever un projet à temps ?
Que se passe-t-il dans ces cas-là ? en informez-vous les équipes de sécurité ?
Comment se présente la relation entre les équipes de développement et de sécurité au sein de votre entreprise ?

Voir aussi :

81 % des développeurs admettent avoir publié sciemment des applications vulnérables, selon Immersive Labs

70 % des initiatives d'automatisation sont entravées par des problèmes de sécurité et de données, mais ces défis peuvent être surmontés grâce à une meilleure collaboration des équipes, selon MuleSoft

Le fossé entre les équipes de développement et de sécurité ne cesse de se creuser, 52 % des développeurs déclarent que les politiques de sécurité étouffent leur innovation, selon VMWare

96 % des développeurs pensent que la sécurité nuit à la productivité, d'après une étude de ShiftLeft centrée sur leur productivité avec une nouvelle solution d'analyse statique

91 % des équipes informatiques se sont senties "obligées" de sacrifier la sécurité au profit d'opérations commerciales, la sécurité est loin d'être la priorité dans le cadre du télétravail, selon HP

Plus de 60 % des équipes DevOps sacrifient la sécurité des conteneurs au profit de la vitesse, selon un rapport de NeuVector

[walfrat]

70 % des développeurs achèvent "fréquemment" ou "toujours" des projets sans effectuer toutes les étapes de sécurité

Bien que j'ai une culture générale de la sécurité, je ne saurais dire quel sont toutes les étapes de sécurité a effectuer dans un projet.

Et même avec une liste des étapes complètes, je suis pas certain de vouloir en prendre la responsabilité.

Que ce soit claire, je ne doute pas que des étapes de sécurité sont mâchés parce que .. ça fait chier et ça prend du temps, mais on a aussi un manque de personnel spécialisé pour gérer ça. Je ne pense pas qu'il soit de la responsabilité d'un développeur lambda que gérer la sécurité d'un projet.