Une étude récente de l’Université de Columbia a révélé que nous sommes embourbés dans plus de 70 décisions par jour. C'est à condition de ne compter que les plus importantes, car des recherches antérieures de l'Université Cornell ont déterminé que nous prenons plus de 200 décisions concernant uniquement la nourriture au cours d'une journée donnée.
La plupart des décisions que nous prenons au quotidien n’ont aucune conséquence à long terme. L’impact est minime et la plupart ne peuvent pas être classés comme « bons » ou « mauvais ». Ce n’est qu’un choix que nous avons fait. Mais certains choix ont des conséquences importantes. Certains sont intentionnels et réalisés avec prévoyance. D’autres ne sont pas intentionnels et ne deviennent évidents qu’avec le recul.
Certaines conséquences imprévues qui semblent évidentes avec le recul concernent la sécurité de nos applications.
Dès le premier jour de développement, vous faites des choix. Beaucoup concernent les plateformes, frameworks, bibliothèques et composants tiers. Vous prenez de nombreuses décisions de ce type durant le développement. On estime aujourd’hui que 80 à 90 % d’une application est constituée de composants open source ou tiers. Chaque choix d’inclure un composant open source ou tiers entraîne des conséquences, notamment pour la sécurité des applications. L’analyse de Black Duck Software révèle en moyenne 105 composants open source par logiciel commercial.
Ces conséquences ne sont pas si inquiétantes à première vue. En effet, les recherches de Contrast Security montrent que les bibliothèques logicielles ne représentent que 7 % des vulnérabilités. Black Duck a constaté une moyenne de 22,5 vulnérabilités open source par application. Quarante pour cent (40 %) de ces vulnérabilités ont été qualifiées de « sévères ». Pourtant, cela reste faible puisque les 10 à 20 % restants d’une application – le code personnalisé – expliquent la majorité des vulnérabilités applicatives.
Malheureusement, la plupart des vulnérabilités ne sont pas communiquées par des CVE ni accompagnées de codes d’exploitation accessibles aux attaquants. Les acteurs malveillants n’ont pas besoin de chercher longtemps pour trouver des cibles dans un environnement où des milliers d’applications web utilisent souvent les mêmes composants et bibliothèques. En ce moment, builtwith.com, qui analyse les technologies utilisées pour créer applications et sites web, recense près de 40 000 sites actifs reposant sur Apache Struts. Vous avez sûrement entendu parler de l’exploitation réussie de vulnérabilités publiées dans Apache Struts 2, qui a causé une certaine panique sur Internet. Des paniques similaires ont été déclenchées par des divulgations majeures de vulnérabilités affectant d’autres bibliothèques open source et tierces très répandues, comme OpenSSL.
Le choix d’intégrer des bibliothèques, des composants tiers ou de concevoir des applications à partir de frameworks libres ne constitue cependant qu’une partie du problème. D’autres décisions prises tout au long du développement peuvent aussi avoir des conséquences importantes, surtout si elles conduisent à des pratiques de développement non sécurisées.
Il n’est jamais surprenant d’entendre que la sécurité a été échangée contre la vitesse. Cela a toujours été le cas. Une enquête McAfee réalisée en 2014 auprès de 504 professionnels de la sécurité a révélé que « près d'un tiers des opérateurs d'organisations interrogées ont admis qu'ils tentaient d'améliorer les performances du réseau en désactivant systématiquement les fonctions de sécurité du pare-feu ».
Il s’avère que le développement n’est pas différent. Leur objectif n’est pas la vitesse d’exécution, mais la vitesse du pipeline. Pour répondre aux demandes de versions d'applications et de mises à jour plus rapides sur le marché, nombreux sont ceux qui admettent ignorer complètement la sécurité pendant le développement. Une enquête menée par Arxan | IBM en 2017 auprès de développeurs mobiles et IoT a révélé que 26 % des répondants ne testent pas du tout les applications mobiles pour détecter des problèmes de sécurité, et près de la moitié (48 %) ne testent pas les applications IoT. La pression de livraison a été citée par 69 % des personnes interrogées comme la raison pour laquelle la sécurité est souvent ignorée.
Un sondage auprès des participants à notre événement client, Agility , cet été, a renforcé cette réalité. Plus de la moitié – 62 % – ont admis avoir troqué la sécurité contre la rapidité au sein de leur organisation.
Et puis il y a les choix faits concernant la manière dont les organisations gèrent les vulnérabilités découvertes. L'analyse de Black Duck a révélé que 10 % des applications analysées en 2018 étaient toujours vulnérables à la vulnérabilité Heartbleed de 2014. Une étude ServiceNow menée par Ponemon a révélé que 57 % des victimes de violations ont déclaré qu'elles auraient pu empêcher la violation en installant un correctif disponible.
Du premier jour de développement jusqu’au déploiement, les choix que nous faisons concernant la sécurité de l’ensemble de la pile applicative sont importants. Ces choix ne sont pas comparables à ceux d'un hamburger ou d'une salade pour le déjeuner ; ce sont des décisions dont les ramifications peuvent se répercuter non seulement sur l'informatique et l'entreprise, mais également sur les clients qui comptent sur le fait que les fournisseurs d'applications prennent la sécurité au sérieux.
Rares sont ceux d’entre nous qui peuvent prétendre n’avoir jamais reçu de lettre « Cher utilisateur de l’application » nous informant que nos données ont été exposées. Ce n’est pas une licence pour être laxiste en matière de sécurité ; au contraire, nous devrions tous nous efforcer de faire mieux pour nos clients en protégeant leurs informations personnelles et privées.
La meilleure façon d’y parvenir est de reconnaître que chaque choix, dès le premier jour de développement, est une opportunité d’ améliorer la sécurité des applications que nous développons. Choisissez consciemment et judicieusement.