Les applications PHP, C++, Java et .NET sont les plus fréquemment défaillantes, selon un rapport de Veracode

Quel intérêt « d’accuser » un langage quand c’est le developpeur derrière qui est responsable du problème.Que 75% des app PHP comporte des failles XSS comparé à seulement 31% en javascript veux seulement dire que les dév JS sont plus sensibilisé à cette problématique particulière.Quelle est l’échantillon analysé ? Y’a t’il autant d’application de chaque langage ? Parce que si dans le lot j’ai 50% de wordpress pas à jour forcément ca fausse les résultats.

Est ce que c’est que du backend ? Front + back ? Parce que par exemple ne pas voir de problème de XSS sur du C++ alors qu’il n’y a pas nativement de solution ca me fait doucement rire.

15

3

C’est vrai que comparer directement le nombre de bug n’est pas forcément pertinent vu que généralement ils ne sont pas utilisés dans le même contexte. Par contre, comparer les types d’erreur par langage a beaucoup de sens car certains types d’erreurs sont moins facile voire impossible a faire dans certains langages, c’est utile de savoir où porter son attention en priorité suivant le langage qu’on utilise.

11

0

Envoyé par Jeff_67

Mauvais titre ! Ça devait être « Les applications web dans le cloud sont de plus en plus défaillantes… ». Ce n’est pas le langage de programmation qui est en cause ici, mais l’approche dans sa globalité.

Ce n’est clairement pas ce qu’on peut déduire de ce rapport qui traite uniquement de code dans le cloud et ne le compare pas avec du code développé de manière classique. Vous n’aimez pas le cloud, peut-être avec de bonnes raison, mais ça n’est pas le sujet ici.

Envoyé par ok.Idriss

Je reste très mitigé sur la pertinence de ce genre d’étude. Vu la liste des langages cités, on a dans les quoi… 60 à 80% du parc logiciel mondial ? Donc en mettant de côté les considérations « c’est les devs, les commerciaux, le langage le responsable », il est de toute façon statistiquement normal que la majorité des logiciels défaillants soient réalisés avec les langages majoritairement utilisés.

Bref on est pas loin du « 100% des consommateurs ont acheté le produit » en terme d’étude…

Je pense pas que le but soit de dire que tous les logiciels sont défaillants. Normalement tout les développeurs sont au courant, même si ça ne semble pas totalement inutile à rappeler.
Le but de la publication de ce rapport est en bien sûr avant tout publicitaire. Si la société présente bien gracieusement ses résultats, c’est une manière de mettre en avant son produit d’analyse. Il ne s’agit pas d’une analyse scientifique rigoureuse. Juste des chiffres brut des résultats de l’outil sans analyse des biais possibles dans les entrées.

Envoyé par defZero

Cette étude est-elle pertinente ou pas ?Ca dépend de si vous considérez que c’est de la faute du langage, s’il y a des bugs dans vos apps .
Si vous choisissez les bons langages, pour les bons projets, en théorie et sous réserve de les maitriser, il n’y a pas de raison que l’un soit plus « buge-ogéne » qu’un autre.

Ça fait beaucoup de conditions dont certaines sont à peu près sures de ne pas être remplies dans la pratique, parce que le nombre de développeurs de disponibles qui maitrisent parfaitement un sujet est limité, et que même les experts ne sont pas infaillible et finiront par laisser passer des erreurs sur une base de code suffisamment complexe. Donc avoir des outils et des langages qui peuvent empêcher certaines erreurs peut toujours s’avérer utile.

Envoyé par defZero

Après comme noté à de nombreuse fois dans les commentaire précédent, c’est évident que certaines class de bug sont dépendante des domaines dans lesquelles les langages sont utilisés.

Le domaine à son importance : c’est sur qu’on aura pas d’erreur XSS dans une appli non web. Mais même dans un domaine identique le langage a un impact. Pour une appli identique en C++ ou en Java, on pourra avoir des problèmes de sécurité dus à un buffer overflow en C++ alors qu’en Java c’est strictement impossible.

Envoyé par Eric80

encore une étude qui semble mélanger corrélation et causalité!

Comparer des défaillances des langages sans parler du champ d’utilisation des logiciels fait avec ces langages ne permet pas de conclure quoi que se soit, sauf comme dit scandinave qu’un langage utilisé pour A aura plus de failles liées à A et qu un autre pour B aura des failles pour B…

Je crois surtout que c’est l’article qui essaie de faire dire des choses au rapport qu’il ne prétend pas. Il ne s’agit en aucun cas d’une étude scientifique rigoureuse mais d’un rapport des résultats d’un outil sur la base de code soumise par les clients. Ces chiffres peuvent être intéressant mais il faut prendre en compte tous les biais possible que cette situation entraine.

Envoyé par walfrat

Je suis curieux comment le Javascript peu avoir une courbe aussi basse sur la qualité de code.

Pour moi elle devrait pas être si différente de Java/C#/PHP car ils vont ensemble dans le cas d’appli web.

Je me suis fait la même remarque. Si le Java et le C# offrent quand même un langage plus structuré qui peut prévenir certaines erreurs, le JavaScript n’offre pas plus que le PHP du point de vue sécurité.

Je pense que ça doit s’expliquer par un biais quelconque dans les données en entrée du rapport. Encore une fois une vraie étude devrait faire attention de traiter des données comparables, ici ça n’est pas le cas. Vu que la qualité du code soumis n’est pas forcément similaire, on peut par exemple supposer que les application PHP correspondent a des projet plus anciens qui datent d’une époque ou la sécurité n’était pas un préoccupation. Si le nombre de client étudiés n’est pas assez élevé il peut aussi tout simplement y avoir un facteur chance. Le rapport ne montre que les erreurs relevés par l’outil. On peut aussi supposer que l’outil est plus efficace pour détecter des erreurs PHP que JavaScript.

Globalement, je pense que ce rapport n’est pas vraiment intéressant pour comparer les langage entre eux vu que les projets comparés ne sont pas forcément équivalent.

7

0

Envoyé par defZero

Très concrètement les langages n’ont pas vraiment d’incidences sur les qualités du code, SI vous avez des devs avec de la bouteille derrière.

on peut te retourner ton argument : plus 1 langage est facile à prendre en main, et plus il y a des « juniors » qui l’utilisent (<- c’est d’ailleurs le but recherché)

C’est le cas du PHP

Python est aussi 1 langage facile à apprendre. Mais je pense que c’est le domaine (R&D) qui fait que de bons développeurs l’utilisent. JavaScript me semble à 1 sale réputation et est « transcompilé » avec TypeScript.

Envoyé par defZero

Ca dépend de si vous considérez que c’est de la faute du langage, s’il y a des bugs dans vos apps . Si vous choisissez les bons langages, pour les bons projets, en théorie et sous réserve de les maitriser, il n’y a pas de raison que l’un soit plus « buge-ogéne » qu’un autre.

Après comme noté à de nombreuse fois dans les commentaire précédent, c’est évident que certaines class de bug sont dépendante des domaines dans lesquelles les langages sont utilisés.

Bof il faut remarquer que seul le C++ à des problèmes/ erreurs liés au « matériel » (dépassement de tampon, gestion des erreurs, …)
Les autres qui sont derrière des machines virtuelles ou des serveurs, ont tous des problèmes/ erreurs MÉTIER.

Donc, oui le langage est important . Et ce n’est pas pour rien que depuis 2011 le C++ évolue tous les 3 ans (C++11, C++14, C++17, C++20) pour supprimer cet écueil pour arriver à ce que les développeurs ne se concentrent que sur le métier.

On peut aussi parler des « sucres syntaxiques ». Par exemple le langage go c’est du C qui permet de faire du concurrentiel très facilement.

6

0

Comparer des défaillances des langages sans parler du champ d’utilisation des logiciels fait avec ces langages ne permet pas de conclure quoi que se soit, sauf comme dit scandinave qu’un langage utilisé pour A aura plus de failles liées à A et qu un autre pour B aura des failles pour B…

6

0

Envoyé par Jeff_67

Cessons de nous voiler la face, passer d’un client lourd à une appli web dans le cloud apporte plus de problèmes que cela n’en résout.

Histoire d’être un peu plus constructif que cette assertion qui n’engage que toi, je dirais plutôt : passer d’un client lourd à une appli web dans le cloud expose les développeurs à tout un tas de nouveaux problèmes. Mais aussi à tout un tas d’avantages.

Chaque approche a ses avantages et inconvénients, ses coûts et bénéfices. Peser le pour et le contre de chaque solution, argumenter de façon factuelle ses choix d’archi, c’est précisément là que se trouve l’aspect ingénierie de notre métier. Ca va de pair avec une vision stratégique claire et précise du projet, d’où l’importance de la communication entre les équipes. Beaucoup d’échecs sont à chercher de ce côté là plus que dans une façon de coder. Ou dit autrement : la bonne utilisation d’une techno adaptée au besoin dépend beaucoup de la culture d’entreprise en place.

6

1

Envoyé par Aurelien.Regat-Barrel

Histoire d’être un peu plus constructif que cette assertion qui n’engage que toi, je dirais plutôt : passer d’un client lourd à une appli web dans le cloud expose les développeurs à tout un tas de nouveaux problèmes. Mais aussi à tout un tas d’avantages.

Chaque approche a ses avantages et inconvénients, ses coûts et bénéfices. Peser le pour et le contre de chaque solution, argumenter de façon factuelle ses choix d’archi, c’est précisément là que se trouve l’aspect ingénierie de notre métier. Ca va de pair avec une vision stratégique claire et précise du projet, d’où l’importance de la communication entre les équipes. Beaucoup d’échecs sont à chercher de ce côté là plus que dans une façon de coder. Ou dit autrement : la bonne utilisation d’une techno adaptée au besoin dépend beaucoup de la culture d’entreprise en place.

Voilà, faut arrêter d’être extrémiste mais comme ce boulot est blindé de commerciaux (je parle commerciaux aussi dans le sens un petit chef IT qui croit qu’il est balaise et vend ça à la direction pour avoir du budget et donc augmenter sa visibilité) qui veulent vendre tout et n’importe quoi, tu te retrouves avec des applications web là où c’est pas forcément nécessaire (au hasard une appli intranet qui remplace un classeur Excel que gère 10 gus dans un open space ).

4

0