Le jour 0 était le jour 1 du développement
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.
CHOIX : PLATEFORMES, CADRES et COMPOSANTS
Dès le premier jour de développement, des choix sont faits. La plupart de ces choix tournent autour des plateformes et des frameworks, des bibliothèques et des composants tiers. De nombreux choix de ce type sont effectués au cours du développement. On estime aujourd’hui que 80 à 90 % d’une application est constituée de composants open source/tiers . Chacun des choix qui conduisent à l’inclusion d’un composant open source/tiers a des conséquences potentielles, notamment en matière de sécurité des applications. L'analyse de Black Duck Software fait état d'une moyenne de 105 composants open source par offre de logiciel commercial.
Ces conséquences, à première vue, ne sont pas si terrifiantes. Après tout, les recherches de Contrast Security révèlent que les bibliothèques de logiciels ne représentent que 7 % des vulnérabilités. Black Duck a trouvé en moyenne 22,5 vulnérabilités open source par application. Quarante pour cent (40 %) de ces vulnérabilités ont été jugées « graves ». Cela reste néanmoins minime si l'on considère que les 10 à 20 % restants d'une application (le code personnalisé) sont responsables de la plupart des vulnérabilités des applications.
Malheureusement, la plupart des vulnérabilités ne sont pas divulguées via des CVE et des exemples de code d'exploitation rendus facilement accessibles aux attaquants. Les mauvais acteurs n’ont pas besoin de travailler si dur pour trouver des cibles dans un environnement où les mêmes composants et bibliothèques sont souvent utilisés par des milliers et des milliers d’applications Web. À l'heure actuelle, builtwith.com, qui suit l'utilisation de la technologie utilisée pour créer des applications et des sites Web, compte près de 40 000 sites en ligne qui s'appuient sur Apache Struts. La plupart d’entre nous sont conscients de l’exploitation réussie de vulnérabilités publiées dans Apache Struts 2 qui a conduit à une légère panique sur Internet. Des paniques similaires ont été provoquées par de graves divulgations de vulnérabilités impliquant d’autres bibliothèques open source et tierces très utilisées, telles qu’OpenSSL.
Mais ce n’est pas seulement le choix d’inclure ou non des bibliothèques ou des composants tiers ou de créer des applications sur des frameworks open source qui est potentiellement problématique. D’autres choix que nous faisons au cours du développement peuvent également avoir de graves répercussions, en particulier lorsqu’ils conduisent à des pratiques de développement non sécurisées.
CHOIX : ÉCHANGEZ LA SÉCURITÉ CONTRE LA VITESSE
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.
LES CHOIX ONT DES CONSÉQUENCES
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.