Discussion :

[Christian Olivier]

Les principaux obstacles à la sécurisation des logiciels aujourd’hui dans le cycle DevOps
D'après une étude de Checkmarx

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 ?

[marsupial]

En 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.

[ShigruM]

c'est surtouts un probleme d'attribution des compétences.

je ne suis pas payé pour sécurité mais pour développer.
je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.
ce sont des domaines complexe et un développeur qui s'improvise testeur ou sécuriseur et très dangereux car il n'a pas les compétences requise pour cela, il au mieux des notions.

La sécurité, le test sont des domaines qui demande des années d'expériences significatives.
je préferaire donc payer un expert qui fera tout le process nécessaire pour sécurisé.

a alger j'ai bien appris tous ce qui était chiffrement (rsa...etc), les attaques xss, injection sql...etc. mais ai-je de l'expérience la dedans ? non.
si je connais bien la théorie je suis un 0 en pratique, le risque d'erreur est trop grave. Il vaut mieux payer un externe pour faire un audit de sécurité.

[xav67]

je ne suis pas payé pour sécurité mais pour développer.
je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.
ce sont des domaines complexe et un développeur qui s'improvise testeur ou sécuriseur et très dangereux car il n'a pas les compétences requise pour cela, il au mieux des notions.

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.

[Beowulf59]

je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.

Je ne suis pas du tout d'accord avec ça. Peut être que ça va bien si tu en es au début de ton apprentissage (à "pisser des lignes" comme on dit vulgairement), mais à un moment donné le développement vas plus loin :

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"...

[XanatosAO]

je ne suis pas payé pour sécurité mais pour développer.
je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.
ce sont des domaines complexe et un développeur qui s'improvise testeur ou sécuriseur et très dangereux car il n'a pas les compétences requise pour cela, il au mieux des notions.

[...]

a alger j'ai bien appris tous ce qui était chiffrement (rsa...etc), les attaques xss, injection sql...etc. mais ai-je de l'expérience la dedans ? non.
si je connais bien la théorie je suis un 0 en pratique, le risque d'erreur est trop grave. Il vaut mieux payer un externe pour faire un audit de sécurité.

Les 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.

[spyserver]

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.

[micka132]

Donc si on suit ton raisonnement, un développeur web n'a pas à se soucier des injections SQL, failles XSS... ?

J 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)

Les failles les plus communes devraient en effet être prise en compte par le développeur.

Les attaques XSS, injections SQL des domaines complexes ? Je ne veux pas être désagréable mais ça me rend fou de lire ça.

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.

[mamadoudou]

l'argent et le temps sont bien les problemes.

Moi dans mes projets ce qui morfle c'est la sécurité et les tests quand on est a cours de budget/temps.
Je privilégie les fonctionnalités et l'UI qui sont les valeurs clients, car le client sera contant.
le jour ou le système du client se fait hacker il ne vas s'en prendre à moi, il me contactera et me payera par contre pour l'accompagner à la sécurité de ces solutions.

donc pour moi c'est un business model, le client nous presse pour avoir son soft, on lui livre un soft non testé et pas sécurisé, il nous repaye plus tard pour sécurisé sont parc applicatif.

le mieux est quand on a accès a la BDD, on lui qu'un concurrent n'a utilisé que du md5 pour chiffré sa BDD (en réalité c’était moi, malynx ), du coup je diffame un concurrent et j'emporte la satisfaction client qui me prend pour un dieu avec mes termes compliqué et l'ajout de la sécurité.

la sécurité, les bugs c'est important car c'est ce qui nous donne du pouvoir et du travail. On peu même créer un bug critique qui requiert notre service pendant un weekend pluvieux en automne/hiver, le client vas facturer très cher le dimanche pendant le week end on peut glander sur developpez.net et corriger le "probleme" dimanche à 16H en modifiant juste la ligne de code que l'on volontairement mal codé.

dernnier point c'est la performance, on peut la aussi créer volontairemlent une sur consommation de ram du soft dans une version 1.0 afin de faire payer au client une V2 qui divise par 2 la consommation de ram.

suffit simplement de génerer un gros tableau d'entier qui prend 1Go de ram et de supprimer cette ligne, 1 semaine payé juste pour supprimer 1 ligne elle est pas belle la vie ? et en plus la aussi tu passera pour un dieu en ayant /2 la ram.
pour le cv tu peut ensuite raconter tes exploits, optimisation de code ultra bas niveau de la mort qui tue, sécurisation renforcé je suis un vrai agent du OWASP...etc. plus c'est gros plus sa passe, sont tellement bête de toute façon. si c'est un informaticien en fasse de toi tu reste vague, tu reste uniquement en surface sans rtentrer dans les détails, tu parle d'architecture cloud, palette de service...etc.

[Psycadi]

@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.

[Pyramidev]

Certains 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.

[Invité]

Qu’en pensez-vous ?

Je ne suis pas codeur.

En revanche, je suis intéressé d'en savoir plus sur ce qu'on appelle "sécurité d'un code" et comme j'ai un peu la flemme de chercher
Il doit exister des best practices je suppose ?

-VX

[foetus]

Utiliser des requêtes préparées.

Ouais, mais il se cache un truc très bête : "échapper toutes les entrées pour les transformer en chaîne de caractères"

Je ne suis pas codeur.

En revanche, je suis intéressé d'en savoir plus sur ce qu'on appelle "sécurité d'un code" et comme j'ai un peu la flemme de chercher
Il doit exister des best practices je suppose ?

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/ ...

[darklinux]

l'argent et le temps sont bien les problemes.

Moi dans mes projets ce qui morfle c'est la sécurité et les tests quand on est a cours de budget/temps.
Je privilégie les fonctionnalités et l'UI qui sont les valeurs clients, car le client sera contant.
le jour ou le système du client se fait hacker il ne vas s'en prendre à moi, il me contactera et me payera par contre pour l'accompagner à la sécurité de ces solutions.

donc pour moi c'est un business model, le client nous presse pour avoir son soft, on lui livre un soft non testé et pas sécurisé, il nous repaye plus tard pour sécurisé sont parc applicatif.

le mieux est quand on a accès a la BDD, on lui qu'un concurrent n'a utilisé que du md5 pour chiffré sa BDD (en réalité c’était moi, malynx ), du coup je diffame un concurrent et j'emporte la satisfaction client qui me prend pour un dieu avec mes termes compliqué et l'ajout de la sécurité.

la sécurité, les bugs c'est important car c'est ce qui nous donne du pouvoir et du travail. On peu même créer un bug critique qui requiert notre service pendant un weekend pluvieux en automne/hiver, le client vas facturer très cher le dimanche pendant le week end on peut glander sur developpez.net et corriger le "probleme" dimanche à 16H en modifiant juste la ligne de code que l'on volontairement mal codé.

dernnier point c'est la performance, on peut la aussi créer volontairemlent une sur consommation de ram du soft dans une version 1.0 afin de faire payer au client une V2 qui divise par 2 la consommation de ram.

suffit simplement de génerer un gros tableau d'entier qui prend 1Go de ram et de supprimer cette ligne, 1 semaine payé juste pour supprimer 1 ligne elle est pas belle la vie ? et en plus la aussi tu passera pour un dieu en ayant /2 la ram.
pour le cv tu peut ensuite raconter tes exploits, optimisation de code ultra bas niveau de la mort qui tue, sécurisation renforcé je suis un vrai agent du OWASP...etc. plus c'est gros plus sa passe, sont tellement bête de toute façon. si c'est un informaticien en fasse de toi tu reste vague, tu reste uniquement en surface sans rtentrer dans les détails, tu parle d'architecture cloud, palette de service...etc.

Au 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 cause

[Invité]

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/ ...

OK, merci.

-VX