Les principaux obstacles à la sécurisation des logiciels aujourd'hui dans le cycle DevOps
D'après une étude de Checkmarx
Le 2018-08-08 15:49:12, par Christian Olivier, Expert éminent sénior
Selon un nouveau rapport, la majeure partie des entreprises auraient encore du mal à mettre en œuvre la sécurité dans leurs processus DevOps, un terme qui fait référence à un mouvement en ingénierie IT et à une pratique technique visant à l’unification du développement logiciel (Dev) et de l’administration des infrastructures informatiques (Ops), notamment l’administration système.
Ce rapport intitulé « ;Managing software exposure: time to fully embed security into your application lifecycle ;» (gérer l’exposition des logiciels : il est temps d’intégrer pleinement la sécurité dans votre cycle de vie applicatif) provient d’une étude menée par Checkmarx, un spécialiste de la sécurité des applications. Il examine les principaux obstacles à la sécurisation des logiciels aujourd’hui dans le cycle DevOps et regroupe les commentaires de 183 personnes originaires des quatre coins du monde, la majeure partie d’entre elles évoluant dans les domaines du développement logiciel, de la sécurité IT et de l’informatique en général.
Cette étude met en lumière le fait qu’il existe un grand fossé entre ce qui est nécessaire et ce qui est réellement en place, relevant que 96 % des personnes interrogées estiment qu’il est « ;souhaitable ;» ou « ;hautement souhaitable ;» que les développeurs soient correctement initiés à la production de code sécurisé. En effet, les organisations sont de plus en plus nombreuses à adopter une démarche DevOps, il est donc impératif que les développeurs travaillant pour elles prennent la responsabilité de sécuriser eux-mêmes les nouveaux logiciels qu’ils conçoivent.
Malheureusement, seulement 11 % des personnes interrogées ont déclaré avoir répondu de manière adéquate au besoin de formation des développeurs évoluant dans leurs organisations pour atteindre cet objectif. En outre, 41 % des sondées reconnaissent que la définition de la responsabilité et de la propriété en matière de sécurité des logiciels reste un défi majeur.
Habituellement, des équipes opérationnelles spécifiques sont responsables au sein des organisations de la sécurité logicielle. Mais il existerait entre les développeurs et les équipes opérationnelles une relation conflictuelle qui génèrerait de problèmes au niveau de la communication et serait à l’origine d’une culture d’inefficacité. Même si la démarche DevOps est censée éliminer un grand nombre de barrières entre ces deux départements, 72 % des personnes interrogées estiment que les différentes équipes et disciplines au sein du département informatique hésitent encore trop souvent à se faire confiance.
Ce rapport insiste également sur le fait qu’il est important d’éduquer et de motiver la haute direction à penser à la sécurité des logiciels en tant que risque commercial, indiquant que 44 % des répondants ont déclaré que les dirigeants ne se soucient pas des moyens mis en œuvre par les développeurs pour fournir rapidement, régulièrement et en toute sécurité des logiciels. Tout ce qui les intéresserait la plupart du temps, c’est que le travail soit fait.
Le rapport de Checkmarx précise à ce propos que 57 % des sondées sont d’accord avec l’affirmation selon laquelle la sécurité des logiciels est désormais « ;un problème de salle de réunion ;» et 45 % des répondants trouvent qu’il est difficile de faire approuver le financement de la formation en sécurité des développeurs par la haute direction.
La première étape pour renforcer la manière dont la sécurité est intégrée au cycle de livraison des logiciels consisterait donc à impliquer davantage la partie dirigeante des organisations concernées. La seconde étape serait probablement de mettre en place un cadre qui permettrait aux développeurs, aux testeurs, aux spécialistes de la sécurité et au personnel des opérations de travailler ensemble en harmonie.
Source : CheckMarx
Et vous ?
Qu’en pensez-vous ?
Ce rapport intitulé « ;Managing software exposure: time to fully embed security into your application lifecycle ;» (gérer l’exposition des logiciels : il est temps d’intégrer pleinement la sécurité dans votre cycle de vie applicatif) provient d’une étude menée par Checkmarx, un spécialiste de la sécurité des applications. Il examine les principaux obstacles à la sécurisation des logiciels aujourd’hui dans le cycle DevOps et regroupe les commentaires de 183 personnes originaires des quatre coins du monde, la majeure partie d’entre elles évoluant dans les domaines du développement logiciel, de la sécurité IT et de l’informatique en général.
Cette étude met en lumière le fait qu’il existe un grand fossé entre ce qui est nécessaire et ce qui est réellement en place, relevant que 96 % des personnes interrogées estiment qu’il est « ;souhaitable ;» ou « ;hautement souhaitable ;» que les développeurs soient correctement initiés à la production de code sécurisé. En effet, les organisations sont de plus en plus nombreuses à adopter une démarche DevOps, il est donc impératif que les développeurs travaillant pour elles prennent la responsabilité de sécuriser eux-mêmes les nouveaux logiciels qu’ils conçoivent.
Malheureusement, seulement 11 % des personnes interrogées ont déclaré avoir répondu de manière adéquate au besoin de formation des développeurs évoluant dans leurs organisations pour atteindre cet objectif. En outre, 41 % des sondées reconnaissent que la définition de la responsabilité et de la propriété en matière de sécurité des logiciels reste un défi majeur.
Habituellement, des équipes opérationnelles spécifiques sont responsables au sein des organisations de la sécurité logicielle. Mais il existerait entre les développeurs et les équipes opérationnelles une relation conflictuelle qui génèrerait de problèmes au niveau de la communication et serait à l’origine d’une culture d’inefficacité. Même si la démarche DevOps est censée éliminer un grand nombre de barrières entre ces deux départements, 72 % des personnes interrogées estiment que les différentes équipes et disciplines au sein du département informatique hésitent encore trop souvent à se faire confiance.
Ce rapport insiste également sur le fait qu’il est important d’éduquer et de motiver la haute direction à penser à la sécurité des logiciels en tant que risque commercial, indiquant que 44 % des répondants ont déclaré que les dirigeants ne se soucient pas des moyens mis en œuvre par les développeurs pour fournir rapidement, régulièrement et en toute sécurité des logiciels. Tout ce qui les intéresserait la plupart du temps, c’est que le travail soit fait.
Le rapport de Checkmarx précise à ce propos que 57 % des sondées sont d’accord avec l’affirmation selon laquelle la sécurité des logiciels est désormais « ;un problème de salle de réunion ;» et 45 % des répondants trouvent qu’il est difficile de faire approuver le financement de la formation en sécurité des développeurs par la haute direction.
La première étape pour renforcer la manière dont la sécurité est intégrée au cycle de livraison des logiciels consisterait donc à impliquer davantage la partie dirigeante des organisations concernées. La seconde étape serait probablement de mettre en place un cadre qui permettrait aux développeurs, aux testeurs, aux spécialistes de la sécurité et au personnel des opérations de travailler ensemble en harmonie.
Source : CheckMarx
Et vous ?
-
xav67Membre habituéDonc si on suit ton raisonnement, un développeur web n'a pas à se soucier des injections SQL, failles XSS... ? La qualité d'un code passe par sa sécurité d’ailleurs, les failles sont souvent abordées des les cours/tuto.
Quand j'ai appris le C l'une des premières chose qu'on m'a enseigné sur les tableaux est de bien faire attention à leurs tailles afin d'éviter les dépassement de tampons, je n'ai pas eu besoin de savoir comment ça fonctionnait pour comprendre que c'était un point qui posait problème et nécessitait de faire attention.
Je ne pense pas que le développeur ait besoin d'être un expert en sécurité, il doit juste être conscient des potentiels points critiques de ses applications pour limiter la casse. Évidemment un audit de sécurité est toujours une bonne idée, quand on parle de sécurité mieux vaut trop en faire que pas assez.le 09/08/2018 à 9:13 -
marsupialExpert éminentEn résumé, la teneur de l'article tient dans 96% des professionnels sont d'accord pour sécuriser mais 0% des instances dirigeantes veulent investir dans de la formation ou dans le recrutement. Déjà le bât blesse. Mais lorsqu'on sait que la sécurité est un métier et qu'un des spécialistes, un ex de la CIA, a rapporté l'an dernier qu'il manquait 1,6 million de candidats rien que pour le marché des Etats-Unis, il serait peut être grand temps de mettre des billes dedans en formation. D'ailleurs, je ne sais même pas comment on fait en France pour tenir debout toutes les infrastructures. Les ESN spécialisées sont surbookées et en surcharge permanente. Et je pense que la situation est similaire partout dans le monde.
C'est à dire que les équipes gèrent trop de clients différents. Au cas où un WannaCry impacte trop de clients, tous ne pourront être servis en même temps. Attention à la catastrophe.le 08/08/2018 à 19:10 -
PsycadiMembre averti@mamadoudou, t'es pas un dev toi, t'es un charlatan o_O
sinon pour parler du sujet, il est vrai que la sécurité est l'affaire des dev mais il faut aussi que les dirigeants (chef de projet, de département...) donnent les moyens de faire de la sécurité. En tant que chef de projet, j'ai souvent eu du mal à avoir plus de temps (donc de l'argent) pour sécuriser une application. En général, ça se termine par quelques devs experts qui font des heures supp. pour supprimer les failles les plus importantes/connues et le reste, on verra quand on sera en Prod.le 09/08/2018 à 14:40 -
XanatosAOMembre régulierLes attaques XSS, injections SQL des domaines complexes ? Je ne veux pas être désagréable mais ça me rend fou de lire ça.
En PHP (puisque nous sommes sur du web) :
- htmlspecialchars ou htmlentities pour les failles XSS
- utiliser correctement PDO contre les injections SQL
Pas besoin d'un diplôme d'ingénieur pour faire ça, ni d'être payé plus.
Sans parler de la quasi-totalité (si ce n'est tous) des frameworks qui gère déjà ces 2 notions de sécurité.
Sauf application avec fonctionnalités bien particulières, (pour moi) un développeur doit savoir sécuriser son application, le contraire m'est juste inconcevable.
En cas d'attaques, je veux bien savoir comment tu te justifies auprès de ton client.le 09/08/2018 à 9:50 -
spyserverMembre confirméUn développeur est responsable de la sécurisation du code bien entendu !!
Pour moi les devs doivent faire de la veille et connaitre les mécanismes de bases je dirais (au moins) et ensuite doivent être conseillés par une instance externe qui s'appelle en général la sécurité dans les boites.
Sur mon projet la sécu avait dressé une liste de recommandations avec des points critiques et des nice-to-have (encryption, algo de chiffrement utilisé, failles diverses et variés sur les tokens, etc...) ça m'a pris une journée de vérifier point par point si on répondait aux critères (en utilisant des librairies solides j'avais déjà couvert 90% des recos), au final il me manquait pas grand chose et on a pu s'aligner sur la version suivante donc dire que ce n'est pas notre métier c'est du non sens.
Nous sommes les premiers concernés justement et je trouve très enrichissant et gratifiant d'avoir une app sécurisé, si on vous appelle un jour et qu'on vous explique que votre app s'est faites hackée et qu'on vous demande des comptes ... honnêtement j'ai pas envie d'être dans ce genre de situation.
Par contre clairement notre salut se trouve dans l'usage de librairies solides et éprouvés, on ne devrait jamais partir sur du code custom avec des features touchant à la sécurité, il faut donc éviter au maximum que ça arrive et se reposer sur les standards, en faisant ça comme j'ai expliqué on couvre 90% des failles.le 09/08/2018 à 11:01 -
foetusExpert éminent séniorOuais, mais il se cache un truc très bête
: "échapper toutes les entrées pour les transformer en chaîne de caractères"
En fait, c'est avant tout
- de respecter les pré et les post conditions (par exemple, de limiter les caractères aux caractères textes lors de la saisie)
- de tester toutes les entrées utilisateurs (ou à défaut de les transformer en chaîne de caractères)
- de s'appuyer sur des bibliothèques qui ont fait leurs preuves (par exemple, OpenSSL)
- de se maintenir au courant en terme de sécurité (par exemple, le MD5 est obsolète) et des retours d'expérience (par exemple, Sony qui ne chiffre pas leur base de données)
En gros, essentiellement tous les petits "trucs" qui sautent parce que pas le temps/ pas nécessaire/ trop chiant à coder/ ...le 10/08/2018 à 4:03 -
PyramidevExpert éminentCertains commentaires sur ce fil montrent un manque de sensibilisation à l'écriture d'un code robuste qui contrôle les entrées des utilisateurs (dont le contenu des URL).
Une injection SQL ne peut exister qu'en cas d'erreur de programmation. En effet, si on construit une requête SQL en concaténant naïvement des chaînes de caractères, dont une chaîne inconnue quelconque (donc qui peut être un bout de code SQL) en faisant comme si ce n'était pas une chaîne quelconque, alors c'est une erreur de programmation.
Éviter les injections SQL, ce n'est pas faire des trucs mystiques spécifiques à la sécurité informatique : c'est seulement essayer d'écrire du code robuste.
Et quand on cherche comment écrire du code robuste autour des requêtes SQL, on cherche sur internet et on tombe sur la réponse : utiliser des requêtes préparées.le 09/08/2018 à 15:18 -
Beowulf59Membre actif
Envoyé par ShigruM
Faire du test ne dépend pas forcément que testeur, cf le TDD et le BDD. Le testeur a une plue value pour les parcours de bout en bout, on peut même faire appel à un automaticien, mais le fait de tester tes méthodes et avoir une bonne couverture de code ne dépend que de toi.
Concernant la sécurité, au final un audit de sécurité va te dire "il y a une faille ici, ici" : il faut te dire comment résoudre tout et le faire à ta place ? Nous sommes des ingénieurs, nous sommes capables de réfléchir un minimum par nous même et d'anticiper les failles les plus communes (OWASP) et de les traiter pour laisser aux personnes faisant l'audit de sécurité de se concentrer sur des cas plus exotiques.
Quant à la remarque "Il faut me payer plus"...le 09/08/2018 à 9:31 -
darklinuxMembre extrêmement actifAu hasard , prie pour le ta clientèle , qui ce doit de faire de la veille sécuritaire , ne ce retourne pas envers l ' ANSSI et t ' adresse un mise en demeure pour une application ne tenant pas compte de leurs suggestion de construction ... il et vrai que si ce n 'est pas dans ton cahier des charges ... mais tu devrais le faire en connaissance de causele 10/08/2018 à 4:39
-
micka132Expert confirméLes failles les plus communes devraient en effet être prise en compte par le développeur.
Par contre il est illusoire de croire qu'en tant que dev on est en capacité de se prémunir de toute attaque, y compris les attaques XSS ou injection SQL, car oui le xss et l'injection sql sont des domaines complexe. Les frameworks ajoutent des fonctionnalités pour les limiter, mais ce n'est pas suffisant, comme le prouve chaque journée qui passe.
Les hackeurs sont passionnés et trouveront toujours un détournement de fonction (que l'on qualifie de faille).
C'est pourquoi j'ai de gros doute sur la généralisation de formations en expert sécurités, qui à mon avis seront juste un nid à charlatan comme on en trouve dans tous les métiers, et qui feront juste gonfler la note d'un projet.le 09/08/2018 à 12:04