IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bruno

55PARTAGES

21  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de walfrat
Membre émérite https://www.developpez.com
Le 29/06/2021 à 14:48
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..._cryptanalysis)
https://xkcd.com/2176/
https://xkcd.com/932/
0  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 03/11/2021 à 9:26
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.
0  0