Discussion :

[Nancy Rey]

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

ShiftLeft, un innovateur dans le domaine de la sécurité des applications automatisées, a publié une nouvelle version de "NextGen Static Analysis". Cette dernière vient avec de nouveaux flux de travail spécialement conçus pour les développeurs et qui améliorent considérablement la sécurité, ce, tout en augmentant la productivité. Les données des clients de ShiftLeft confirment que la productivité des développeurs souffre lorsque la sécurité n'est pas automatisée et intégrée de manière transparente dans le cycle de vie du développement logiciel.

Dans une nouvelle enquête menée auprès de plus de 165 développeurs, professionnels de la sécurité des applications et du DevOps, ShiftLeft a constaté que 96 % des développeurs estiment que la déconnexion entre les flux de travail des développeurs et de la sécurité inhibe la productivité des développeurs. En outre, lorsqu'on leur a demandé de définir des priorités, les professionnels de la sécurité des applications ont classé la création de flux de travail de sécurité adaptés aux développeurs comme leur priorité absolue, ce, devant la protection des applications dans les environnements de production.

« La réduction des priorités de la sécurité a été l'approche la plus courante pour équilibrer la sécurité des applications et la productivité des développeurs, car l'automatisation de la sécurité dans les flux de travail des développeurs a toujours été d'un coût prohibitif pour toutes les organisations de sécurité, sauf les plus élites. Le NextGen Static Analysis de ShiftLeft combine la vitesse de balayage, la précision et un flux de travail transparent à la pointe de l'industrie ; le tout pour une collaboration rapide entre les équipes de développement et les équipes de la Sécurité des applications afin que les organisations de toutes tailles puissent mener leurs initiatives au rythme du développement logiciel », a déclaré Izak Mutlu, ancien vice-président de la sécurité de l'information chez Salesforce.com.

L’amplification du télétravail de façon permanente a accru le volume d'affaires réalisées en ligne, augmentant ainsi le nombre de propriétés et d'applications web qui doivent être développées. Comme les organisations exigent que les logiciels soient construits et livrés à une vitesse toujours plus grande, il est essentiel d'améliorer la productivité des développeurs tout en renforçant la sécurité. L'enquête a révélé que le fait d'effectuer des analyses de sécurité trop tard dans le cycle de vie du développement logiciel (89,7 %) et le manque de conseils en matière de remédiation (87,7 %) sont également des obstacles importants à la productivité des développeurs.

Pour renforcer la sécurité et relever les défis de la productivité des développeurs, la nouvelle version NextGen Static Analysis de ShiftLeft propose des flux de travail holistiques avec comme premier principe l'engagement et la productivité des développeurs. Le nouveau déroulement des opérations de sécurité axé sur les développeurs repose sur le processus basé sur Git que les développeurs utilisent déjà pour écrire et mettre à jour le code. Cela permet aux organisations de :

• fournir un retour d'information immédiat et précis sur la sécurité directement à chaque développeur qui apporte le changement ;
• automatiser l'analyse des codes à chaque demande de retrait/fusion ;
• permettre aux développeurs de corriger les vulnérabilités, de la même manière qu'ils corrigent les bogues, sans quitter leur environnement de développement ;
• permettre aux équipes de la sécurité des applications d'écrire des règles de construction axées sur la sécurité qui acceptent ou refusent les fusions, permettant ainsi à la sécurité des applications d'évoluer ;
• aider les développeurs à adopter les meilleures pratiques de codage sécurisé grâce à Security Insights ;
• éliminer les goulots d'étranglement en matière de numérisation grâce à des numérisations simultanées illimitées ;
• protéger la propriété intellectuelle en scannant sans prendre le code source en dehors de leur organisation ;
• se déployer rapidement grâce à l'embarquement en libre-service qui ne nécessite pas de mises à jour de l'architecture réseau, de nouvelles configurations de pare-feu ou de services professionnels coûteux ;
• personnaliser davantage les flux de travail grâce à des API complètes.

Cette approche de l'analyse de code centrée sur le développeur augmente considérablement la sécurité et la productivité en fournissant la bonne vulnérabilité au bon développeur au bon moment. Le temps moyen de remédiation est réduit, car les vulnérabilités sont corrigées alors que le code est encore frais dans l'esprit des développeurs, et le code vulnérable ne devient pas profondément interconnecté, car les règles de construction de sécurité l'empêchent d'entrer dans la branche maîtresse.

« La seule façon d'assurer la sécurité au rythme des cycles de vie du développement logiciel moderne est de créer une culture de responsabilité individuelle des développeurs pour la sécurité du code qu'ils écrivent. Toutefois, cela exige de nouvelles solutions de sécurité des applications spécialement conçues pour les besoins actuels. D'après notre nouvelle enquête, il est clair que les développeurs ont le sentiment que les processus de sécurité ad hoc et les outils dont ils disposent aujourd'hui ne les aident pas. Nous avons toujours placé la productivité et la sécurité à la base de notre plateforme, et les résultats de nos clients montrent que le nouveau flux de travail améliore considérablement leurs postures de sécurité tout en augmentant la productivité des développeurs », a déclaré Manish Gupta, PDG de ShiftLeft.

Source : ShiftLeft

Et vous ?

Les conclusions de cette étude s’alignent-elles avec la réalité dont vous êtes au fait ?
Quelle pertinence lui accordez-vous ?

Voir aussi :

Google met à la disposition des développeurs un panneau de sécurité sur Chrome, pour faciliter le déploiement du HTTPS

Les développeurs auraient du mal à implémenter correctement le chiffrement dans leur application, parce qu'ils n'ont pas reçu de formation spécifique

L'infrastructure du protocole de communication sécurisé Matrix piratée, le hacker parle et expose de mauvaises pratiques de sécurité qui l'ont aidé

[BufferBob]

96% des cyclistes pensent que les voitures n'ont rien à faire sur la route (enquête menée auprès de 8 cyclistes)

[dfiad77pro]

Disons que quand sécurité à tendance à bloquer npm, github, java... Aléatoirement sans prévenir, c'est un peu énervant.

Quand ils renforcent les règles des Antivirus et que le CPU tourne a 90% pendant 5 minutes ...

Bref bien souvent la sécurité en entreprise ne prend pas en compte les développeurs, même dans l'analyse des faille de codes

[Neckara]

Disons que si ta sécurité c'est d'empêcher les utilisateurs de se connecter sur des réseaux WiFi, de bloquer tous les ports, d'empêcher d'installer des IDE / Bibliothèques, ouais ça nuit à la productivité.

Derrière pas de sécurité, et un virus qui te détruit toutes tes données...

[esperanto]

96% des cyclistes pensent que les voitures n'ont rien à faire sur la route (enquête menée auprès de 8 cyclistes)

C'est bien pour ça qu'on crée des pistes cyclables distinctes de la route pour les voitures, non?

Dans le cas des développeurs, ça devrait prendre la forme d'une séparation plus nette entre l'environnement de développement, plutôt ouvert, et celui de production. Entre les deux, bien sûr, un ou plusieurs niveaux de "test" pour que le développeur puisse vérifier que ce qu'il vient d'écrire a une chance de fonctionner une fois dans un environnement plus sécurisé.
Ensuite, dès lors que l'environnement de développement contient une réplique suffisamment complète de celui de production (au niveau des programmes, mais avec des données de test uniquement, bien entendu) alors plus besoin d'accéder à la production.
Parce que si comme dans mon cas, j'ai plein accès à la production mais interdiction d'exécuter tout programme non approuvé par le DSI (ce qui inclut donc de facto tout programme que j'aurais écrit puisqu'il n'a pas eu le temps de passer le filtre du DSI) alors oui, au bout d'un moment la productivité en prend un sacré coup.

[phil995511]

"96 % des développeurs pensent que la sécurité nuit à la productivité"

Vous auriez dû titrer "96 % des développeurs codant avec leur pieds (au lieu de leur tête) pensent que la sécurité nuit à la productivité"

[tanaka59]

Bonsoir,

96 % des développeurs pensent que la sécurité nuit à la productivité

Les conclusions de cette étude s’alignent-elles avec la réalité dont vous êtes au fait ?

C'est à géométrie variable ... J'ai déjà vu tout et son contraire ... Des boites ou l'on vous demande par exemple de développer batch , VBA et SQL pour des moulinettes ... mais comme vous n’êtes pas directement de la DSI , mais plutot marketeur/analyste c'est une vrai galère pour avoir de la doc ... Même sur internet une politique de blocage à outrance ou impossible d'avoir accès à la moindre doc... Une doc Excel , une doc VBA bloqué . On en vient à chercher sur son propre smartphone ...

Dans les trucs farfelues aussi . Impossible d'exécuter des .exe ou .bat . Wé et les analystes qui ont du VBA ont fait comment ? Bah tu fais pas

La palme va au dev qui surfe sur internet sur un serveur de prod non partiellement sauvegardé ... regarde du stream et se chop une trojan

J'ai connu une boite une fois ou dans sa politique de sécu https://www.developpez.net entre dans la catégorie de site dangereux qui divulgue de l'intox ou encore le forum officiel Microsoft pour les produit comme powerbi ou Access ... Sympa quand on cherche une info et une doc précise ... Surtout que le helpdesk de Microsoft tout passe par forum et plus de hotline ...

Quelle pertinence lui accordez-vous ?

Le pourcentage est pipé . Cela dépend de nombreux facteurs, difficilement quantifiable selon le secteur d'activité

[robertledoux]

donc 96% de développeurs a requalifier, voire a remercier.

[walfrat]

Disons que parmis les 96% il y a sans doute :

• des cowboy dont la sécurité, la maintenabilité du code freine leur productivité
• Des devs qui quand on leur parle de sécurité pense à tout les façon foireuses dont c'est implémenter en entreprise.

[grunk]

Disons que quand sécurité à tendance à bloquer npm, github, java... Aléatoirement sans prévenir, c'est un peu énervant.

Quand ils renforcent les règles des Antivirus et que le CPU tourne a 90% pendant 5 minutes ...

Bref bien souvent la sécurité en entreprise ne prend pas en compte les développeurs, même dans l'analyse des faille de codes

Disons que si ta sécurité c'est d'empêcher les utilisateurs de se connecter sur des réseaux WiFi, de bloquer tous les ports, d'empêcher d'installer des IDE / Bibliothèques, ouais ça nuit à la productivité.

Derrière pas de sécurité, et un virus qui te détruit toutes tes données...

Je pense que l'article parle plus de la sécurité à implémenter dans les applications plutôt que de la sécurité de l'environnement de travail. La mouvance Shift Left à pour but de mettre la sécurité au centre du développement plutôt qu'en bout de chaîne par des équipes dédiées. Mais inévitablement si il faut penser à la sécurité en permanence il est difficile d'être aussi productif que quand on y portait moins d'attention. L'idée est donc de fournir les bons outils aux dévs pour automatiser au maximum ce qui peut l'être

[Kikuts]

Les commentaires que je lis, du genre "96% de dev à licencier" ou "96% de dév qui sont nul" me font halluciner.

Si la sécurité n'entrave pas du tout votre productivité, il n'y a que 2 solutions possibles :
- soit depuis toujours ils codent en mettant la sécurité au coeur de leur préoccupation et du coup ne doivent pas avoir une productivité de fou,
- soit le mot productivité doit faire un son étrange et nouveau à leurs oreilles...

Franchement, j'aimerai bien croiser un dév qui peut me regarder droit dans les yeux et me dire que coder une authentification en prenant la sécurité en compte n'influence pas sa productivité...
En mode bourrin une authentification simple sans cryptage, token, etc c'est une question de minutes voir au max qq heures à modéliser, coder, déployer et même documenter lol.
La même chose en cryptant le mdp, en déployant un code signé avec certificat, vérifier que le serveur et la DB ont les derniers patchs contre les derniers zero days et vulnérabilités connues, etc, c'est soit Jon Skeet, soit un gros mytho soit un prof qui n'a fait que des cours et formation hello world dans sa vie

En plus la sécurité
La sécurité à un coût non négligeable sinon tous nos sites web et appli seraient bien plus sécurisé !

Je prends 2 voitures identiques d’apparence.
Les assembler ne prendra pas le même temps s'il faut ajouter ou non les ceintures de sécurité, les attaches sièges enfant qui respectent les normes européennes, les airbags etc (front end).
Les assembler de sorte qu'en cas de crash la voiture absorbe une grande partie du choc et passe les crash test, impliquera plus de temps (R&D, modélisation, backend).
Et je ne parle même pas de toutes les sécurités sous le capot et assistance à la conduite...

[lvr]

Si la sécurité n'entrave pas du tout votre productivité, il n'y a que 2 solutions possibles :
- soit depuis toujours ils codent en mettant la sécurité au coeur de leur préoccupation et du coup ne doivent pas avoir une productivité de fou,
- soit le mot productivité doit faire un son étrange et nouveau à leurs oreilles...

La sécurité ne peut pas entraver ta productivité parce qu'elle doit être intégrée à la définition de ta productivité.
La sécurité est un must et a un coût. Important. Mais moindre que de ne pas le faire ou l'oublier.
Un développeur et un responsable de projet qui n'intégrent pas la sécurité dans leurs estimations de charge de travail font mal leur boulot.

[Neckara]

La sécurité ne peut pas entraver ta productivité parce qu'elle doit être intégrée à la définition de ta productivité.

Bah ça dépend ce que tu comptes. Ta "productivité" dépend des métriques que ton patron va regarder, e.g. heures bossées, lignes codés, nombre de tickets fermés, etc.


Après, ça dépend aussi de la manière dont la sécurité est gérée. Si c'est te dire "démerdes-toi"... c'est loin d'être facile. Si c'est une autre équipe qui se charge de la maintenant/pots cassés/tests, tu t'en fous. Si ça permet de vendre des services supplémentaires à un client, ben certains vont vouloir en profiter.

Si tu fais des démos/PoC, la sécurité n'est pas forcément nécessaire à ce niveau là. Tu as aussi le niveau de sécurité à adapter en fonction des risques.


On ne peut pas en vouloir à un développeur de dire "si je dois focus sur la sécurité, je pourrais moins traiter de tickets en une journée".

[JPLAROCHE]

Franchement, j'aimerai bien croiser un dév qui peut me regarder droit dans les yeux et me dire que coder une authentification en prenant la sécurité en compte n'influence pas sa productivité...

Franchement tu programmes ou pense informatique sans sécurité, sous prétexte que cela prends du temps ???? , Beinnnn oui moi je te voudrais pas dans mon équipe... Juste rajouté que la sécurité ne ce limite pas à l'authentification ... cela serait trop simple... as-tu seulement participé à la validation auprès d'assurance etc... voir une reprise à chaud....

[fodger]

Le premier problème de sécurité est souvent entre l'écran et le clavier...

[emixam16]

Pour moi les deux points que vous soulevez ne sont pas exclusifs.

• Oui, la sécurité prend du temps et fait baisser la productivité. Il est probable que 4% des répondants n'aient jamais touché à une vraie ligne de code (le CSS ne compte pas, hein?) car c'est vraiment évident.
• Il est largement préférable de perdre ce temps pour avoir un système robuste plutôt que quelque chose de rapide mais qui casse dès que Kévin, le premier script kiddie du coin s'amuse à faire une force brute metasploit pour impressionner ses copains.

[Jamatronic]

Le premier problème de sécurité est souvent entre l'écran et le clavier...

Oui, ce fameux "problème entre l'écran et le clavier" sur lequel on tape tout le temps... mais qui fait le boulot.

[watchinofoye]

Ça dépend de la définition de "sécurité". Dans une boîte (comme celle où je bosse) où la sécurité consiste à bloquer plein de sites pour des raisons obscures (dont Github ou le site de Gimp) mais ne pas bloquer d'autres sites qui peuvent poser problème (vous voulez découper ou fusionner un PDF confidentiel avec un outil en ligne dont on ne sait pas s'il récolte les données pour les revendre ? C'est possible !), on peut dire que la "sécurité" ruine à la productivité.

Pareil pour la "productivité". Si ça consiste à sortir un truc à l'arrache, mal étudié, mal codé et/ou mal testé, la sécurité peut bien faire partie des points qui nuisent à la "productivité".

Si on parle de sécurité et de productivité dignes de ce nom, la question ne se pose pas. Quand on produit quelque chose dont on veut de manière sécurisée, il faut prendre en compte que cela risque de prendre du temps. Mais si le projet avance bien, même s'il prend pas mal de temps mais qui était prévu à la base, ça ne nuit pas à la productivité (si on parle en termes de respect des délais impartis et non en termes de "Vite ! Vite ! Il faut sortir un truc sinon on va pas gagner assez perdre de l'argent !").

Il y a d'autres facteurs qui peuvent davantage nuire à la productivité que ne le ferait la sécurité : un management chaotique, des moyens techniques sous-dimensionnés, des deadlines irréalistes, etc