Discussion :

[Bill Fassinou]

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

Veracode est une entreprise de sécurité des applications basée à Burlington, dans le Massachusetts. Elle fournit un service automatisé basé sur le cloud pour sécuriser les applications Web, mobiles et d'entreprises tierces. La société a publié en décembre dernier le 11e volume de son rapport annuel sur l'état de la sécurité des logiciels. Ses conclusions révèlent que les applications défectueuses sont la norme, que les bibliothèques open source sont de moins en moins fiables et qu'il faut beaucoup de temps pour corriger les problèmes.

Le volume 11 du rapport de Veracode sur l'état de la sécurité des logiciels est considéré par l'entreprise comme un rapport avant-gardiste. La 11e version du rapport de Veracode sur l'état de la sécurité des logiciels est enrichie par les données de plus de 130 000 applications scannées. Les tendances relevées permettent non seulement d'avoir une idée des risques auxquels les équipes de développement et de sécurité sont régulièrement confrontées, mais elles mettent également en lumière les vulnérabilités et les langages les plus risqués que les développeurs doivent surveiller pendant leur travail.

Selon Veracode, il est aujourd'hui important que les développeurs soient capables d'écrire du code plus rapidement et plus efficacement pour répondre aux exigences du développement logiciel moderne. L'entreprise estime que, bien qu'il soit plus facile que jamais de trouver et de corriger les failles avec les bons outils de sécurité des applications (AppSec), les équipes de développement sont toujours confrontées à des défis spécifiques aux langages qui peuvent se transformer en obstacles. C'est pourquoi les développeurs doivent examiner les tendances de la fréquence des bogues dans divers langages courants.

Cela leur permettra d'avoir une meilleure compréhension des risques quotidiens auxquels ils sont confrontés lors du codage et ils pourront utiliser ces connaissances pour anticiper ces vulnérabilités avant qu'ils ne deviennent un problème.

État de la sécurité des logiciels v11 : principales conclusions

Dans le volume 10 de l'état de la sécurité des logiciels, Veracode s'était intéressé à la prévalence des failles dans les langues les plus courantes. L'entreprise a constaté que certains langages sont plus sensibles à certains types de vulnérabilités que d'autres. Les débordements de mémoire tampon et les erreurs de gestion de la mémoire tampon sont des problèmes courants en C++, mais les capacités intégrées de gestion de la mémoire tampon des langages de haut niveau (comme .NET et JavaScript) font que ces failles ont tendance à être rares dans ces applications.

Dans ce volume 11 de l'État de la sécurité logicielle, Veracode a constaté que les distinctions entre les langages restent valables : 59 % des applications C++ présentent des bogues de haute (et très haute) gravité, contre seulement 9 % pour les applications JavaScript. Le script est un peu chamboulé avec Java, car seuls 24 % des utilisateurs ont des bogues critiques cette fois-ci. En gros, le rapport a révélé que 76 % des applications analysées contiennent des bogues, et 24 % d'entre elles présentent des vulnérabilités considérées comme très graves.

Environ 70 % des applications héritent de failles de sécurité de leurs bibliothèques de logiciels libres. En outre, Veracode juge qu'il est important de noter que seulement 30 % des applications ont plus de bogues de sécurité dans leurs bibliothèques de logiciels libres que dans le code écrit en interne, ce qui suggère que ce ne sont pas seulement les projets de logiciels libres qui sont à blâmer. Dans son rapport de 2020, Veracode a déclaré que les bibliothèques open source sont une surface d'attaque massive en raison de leur omniprésence.

Le rapport souligne également qu'il n'y a pas de corrélation entre la qualité du code interne et les bogues des logiciels libres, soulignant que les développeurs devraient vérifier la sécurité des bibliothèques de logiciels libres, quelle que soit la qualité de leur propre code. En ce qui concerne la manière dont les bogues sont résolus, Veracode a constaté que 73% des bogues qu'il a trouvés dans le cadre du rapport ont été corrigés, ce qui constitue une grande amélioration par rapport aux années précédentes, où ce chiffre se situait dans la moyenne des 50 %.

Malgré ce bon signe, il faut encore six mois en moyenne pour fermer la moitié des failles découvertes. En ce qui concerne les types de failles de sécurité découvertes, le rapport indique que les résultats sont conformes aux années précédentes.

Les types de failles de sécurité découvertes par Veracode en 2020

Selon le rapport de Veracode, pour la plupart, les principaux types de failles sont restés assez constants au fil des ans. Le volume 10 de l'année 2019 a révélé que les fuites d'informations, les problèmes cryptographiques, l'injection de CRLF et les failles de qualité de code étaient les types de vulnérabilités les plus courants dans les applications. Dans la recherche de cette année, les trois premiers types de vulnérabilités n'ont pas bougé, et en troisième place, les problèmes cryptographiques sont également présents dans presque deux applications sur trois présentant des défauts dans ce rapport.

Le type de failles le plus courant dans les applications .NET était la fuite d'informations, tandis que le Cross-Site Scripting (XSS) pour PHP et l'injection CRLF pour les applications Java étaient les plus courants. La première intersection se retrouve dans la deuxième faille la plus fréquente, la qualité du code apparaissant à la fois pour les applications .NET et Java. En fait, il existe plusieurs points de chevauchement pour les applications .NET et Java, ce qui est logique compte tenu des similitudes entre ces deux plateformes. Mais ce n'est pas tout.

Bien que la ventilation du langage soit utile, ce type d'analyse présente un risque important, car elle peut élever artificiellement certains types de failles. Le Cross-Site Scripting est également la faille la plus courante dans les applications JavaScript, mais cela s'applique à moins d'un tiers des applications analysées. Il est donc un peu problématique de le mettre sur le même plan de gravité que PHP, où XSS se trouve dans les trois quarts des applications scannées. Veracode a également publié une carte thermique des pires bogues dans les langages les plus populaires.

Il est intéressant de noter que le langage qui utilise le moins de bibliothèques open source est aussi celui qui présente le plus de bogues : PHP. En regardant la carte thermique, il est facile de repérer lequel des cinq langages populaires inclus a la plus mauvaise sécurité. Après PHP, il y a C++, puis Java, .Net, JavaScript et Python. Ces deux derniers font beaucoup mieux que la concurrence, les pires bogues de chacun d'eux n'étant trouvés que dans environ 30 % des applications. Comparativement à PHP, dont 74,6 % des applications sont vulnérables aux scripts intersites, JavaScript et Python sont des moteurs de sécurité.

Enfin, Veracode estime que, quel que soit le langage que vous choisissez, il est essentiel de mettre en œuvre les meilleures pratiques, que l'entreprise décrit dans le rapport comme "nature vs. culture". En substance, la nature des applications est constituée d'éléments qui ne peuvent être contrôlés, alors que les aspects de l'enrichissement sont ceux que vous pouvez contrôler. Selon le rapport, même si le développeur a hérité d'une vieille application gargantuesque avec des tas de dettes de sécurité, et qu'il n'y a plus personne qui se souvienne pourquoi certaines choses ont été codées de cette façon, réparer les défauts et ajouter de nouvelles fonctionnalités ne doit pas continuer à être difficile.

« Nous avons examiné l'effet de la nature et de la culture sur la sécurité de nos applications. Nous avons constaté que la culture, nos décisions et nos actions peuvent surmonter et améliorer la nature de l'application et de l'environnement », a conclu Veracode.

Source : Rapport de Veracode

Et vous ?

Cette étude est-elle pertinente ou pas ?
Quelle est votre expérience en la matière pour ce qui est de vos applications ?

Voir aussi

The State of the Octoverse 2020 : Python et TypeScript gagnent en popularité parmi les langages de programmation, alors que JavaScript continue d'être le langage le plus populaire sur GitHub

État de JavaScript en 2019 : les développeurs aiment un peu plus React, Angular est en déclin, un groupe de développeurs pense que JS est « trop complexe »

Les tendances dans les métiers de la technologie en France en 2017, une enquête réalisée par CodinGame

Les bibliothèques JavaScript ne reçoivent presque jamais de mise à jour une fois qu'elles sont installées, selon une enquête de Cloudfare

[grunk]

Cette étude est-elle pertinente ou pas ?

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.

[Uther]

L’intérêt c'est que certains langages permettent d’éviter plus facilement certains types erreurs. Parce que le développeur qui peut éviter toutes les d'erreurs, c'est juste une légende.

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.

[Invité]

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

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. Le troll ultime, c'est de devoir maîtriser 3 langages (HTML/CSS/JS) rien que pour faire une UI correcte, là où il existe des éditeurs visuels qui rendent la conception de l'interface triviale pour les applis de bureau.

[scandinave]

La seule chose que dit cette étude, c'est que les langages massivement utilisés sur le web ont plus de faille web, les langages utilisés pour du système n'ont pas ces failles mais d'autre comme la gestion des erreurs et enfin les langages utilisés pour, entre autre, des calculs/maths ont des problèmes avec de la crypto. Bref rien de nouveau sous le soleil.

[Aurelien.Regat-Barrel]

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.

[GreatDeveloperOnizuka]

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

[redcurve]

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.

Ouais enfin dans les faits tout le monde veut faire du cloud et du web, même quand ça n'a aucun sens. Cette décision est généralement prise à la machine à café par des types sachant à peine utiliser un ordi les fameux décideurs.

[Invité]

Quelqu'un a lu le rapport en question ?
Personnellement, j'aurais bien voulu mais je refuse de laisser mon mail pour vérifier si une boite qui vend de la sécurité a raison de nous alarmer sur le manque de sécurité.

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

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

Quelle est votre expérience en la matière pour ce qui est de vos applications ?

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.
Je sais que c'est un gros "si", mais pour moi la situation viendrait plus du fait que les devs moins expérimentés sont beaucoup plus nombreux dans la majorité des projets IT.
Quand vous avez des Ingés qui ce considères Senior après 5 ans à faire du Qt (pas du "vrai" C++, ) et qu'ils/elles ne veulent plus coder mais faire uniquement de la gestion de projet, ceci explique cela beaucoup mieux que le langage utilisé selon moi.

[GreatDeveloperOnizuka]

Quelqu'un a lu le rapport en question ?
Personnellement, j'aurais bien voulu mais je refuse de laisser mon mail pour vérifier si une boite qui vend de la sécurité a raison de nous alarmer sur le manque de sécurité.

T'as ce site de mail temporaire que j'utilise tout le temps

https://temp-mail.org/en/

Sinon à noter que j'ai vu pas mal d'applications Java avec bcp de bugs mais c'était surtout lié à l'organisation et non à la techno. Généralement, une SSII 90% sous-traitée par des SSII, le turnover était quasi permanent donc le mec de passage soit s'en tape tant que ça marche, reste là 1 à 3 ans et se cassent, soit c'était de super vieilles applications et on voulait foutre des trucs sortis il y a 1 an pour être à la mode. Donc un gros legacy avec des règles métiers non connues par la "MOA" qu'il faut migrer vers un truc un peu récent pour faire genre. Par exemple, un ORM maison qu'on a fait en 2000 et on se dit qu'il serait bien de passer par NHibernante ou Entity Framework pour .NET.

[Invité]

T'as ce site de mail temporaire que j'utilise tout le temps

https://temp-mail.org/en/

Merci.

Donc en gros ils scannent les codes envoyés par leurs clients pendant le dév, ainsi que les dépendances externes.

Veracode methodology for data analysis uses a sample of applications that were under active development from a 12-month sample window. The data represents the full history of applications that had assessments submitted from April 1, 2019 through March 31, 2020
...
For the software component analysis, each application is examined for third-party library information and dependencies. These are generally collected through the applications build system. Any library dependencies are checked against a database of known flaws.
...
The report contains findings about applications that were subjected to static analysis, dynamic analysis, software composition analysis, and/or manual penetration testing through Veracode’s cloud-based platform.
...

[foetus]

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.

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.

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

[OuftiBoy]

Je ne sais qui disait plus haut, qu'il y'a avait des langages plus facile a "prendre en main". C'est vrai, mais "prendre en main" un langages ne fait pas de vous un spécialiste de ce langage. Il faut des années pour "maîtriser" un langage. Même python, dont la "prise en main" est très simple, peut offrir à votre cerveau de quoi tourner en rond quand on approfondis les choses ;-)

Non, ce qu'il faut, c'est connaitre ses outils, et utiliser le bon ou celui qu'on maîtrise pour arriver à l'objectif désiré.

Dans la phrase précédente, il y'a :
- outil
- le bon
- maîtriser
- objectif désiré

l'outil ? Si un ébéniste choisit une truelle pour enfoncer un clou, peut-on en vouloir à la truelle ?
le bon ? Il faut donc un marteau, et si un ébéniste se tape sur les doigts avec le bon marteau, on accuse le marteau ?
maîtriser ? Du temps, ne pas vouloir suivre les modes, de l'humilité, de la rigueur. Pas lire "devenez développeur web en 24H" :-)
objectif désiré... Là, c'est plus souvent LE problème...

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

[fodger]

Ce genre d'étude est un peu bidon, les contextes sont bien différents d'un langage à l'autre et en 10 ans ça a beaucoup changé côté PHP.

Qui plus avec 80% des sites écrits en php, forcément que sur la masse il y'aura bien plus de cas foireux, surtout avec des CMS comme wordpress qui ont permis à des millions de gugus n'y connaissant rien d'installer des plugins codés salement.

Quand à Javascript qui est "un moteur de sécurité", c'est une vaste blague.

[Invité]

en 10 ans ça a beaucoup changé côté PHP.

Côté C++, .NET, Java et JavaScript aussi.

Qui plus avec 80% des sites écrits en php, forcément que sur la masse il y'aura bien plus de cas foireux, surtout avec des CMS comme wordpress qui ont permis à des millions de gugus n'y connaissant rien d'installer des plugins codés salement.

D'après ce que j'ai compris, ce n'est pas ce que mesure l'étude.

[Uther]

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.

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.

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.

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.

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.

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.