Une étude récente de l’université Columbia a révélé que nous sommes accaparés par plus de 70 décisions par jour. Et ce, uniquement si l’on compte les décisions importantes, car une précédente étude de l’université Cornell a établi que nous prenons chaque jour plus de 200 décisions rien qu’en matière d’alimentation.
Bon nombre des décisions que nous prenons au quotidien sont sans conséquence à long terme. Leur impact est minime, et la plupart ne peuvent être qualifiées de « bonnes » ou de « mauvaises ». Ce sont simplement les choix que nous avons faits. Mais certains choix ont des conséquences importantes. Certains sont intentionnels et mûrement réfléchis. D’autres sont involontaires 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, FRAMEWORKS ET COMPOSANTS
Dès le premier jour de développement, des choix sont effectués. Nombre d’entre eux concernent les plateformes et les frameworks, les bibliothèques et les composants tiers. De nombreux choix de ce type sont faits au cours du développement. On estime aujourd’hui que 80 à 90 % d’une application est constituée de composants open source ou tiers. Chacun des choix conduisant à l’intégration d’un composant open source ou tiers peut avoir des conséquences, notamment sur la sécurité de l’application. L’analyse de Black Duck Software fait état d’une moyenne de 105 composants open source par logiciel commercialisé.
À première vue, ces conséquences ne sont pas si alarmantes. Après tout, une étude de Contrast Security révèle que les bibliothèques logicielles ne représentent que 7 % des vulnérabilités. Black Duck a recensé en moyenne 22,5 vulnérabilités liées à des composants open source par application. Quarante pour cent (40 %) de ces vulnérabilités ont été jugées « graves ». Cela reste toutefois minime si l’on considère que les 10 à 20 % restants d’une application — le code personnalisé — sont à l’origine de la plupart des vulnérabilités des applications.
Malheureusement, la plupart des vulnérabilités ne sont pas divulguées par le biais de CVE accompagnées d’exemples de code d’exploitation facilement accessibles aux attaquants. Les acteurs malveillants n’ont pas besoin de chercher bien loin 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 recense les technologies utilisées pour créer des applications et des sites web — dénombre près de 40 000 sites actifs reposant sur Apache Struts. La plupart d’entre nous connaissent l’exploitation réussie de vulnérabilités publiées dans Apache Struts 2, qui a provoqué un léger vent de panique sur Internet. Des mouvements de panique similaires ont été provoqués par la divulgation de vulnérabilités graves concernant d’autres bibliothèques open source et tierces très répandues, telles qu’OpenSSL.
Mais le problème potentiel ne réside pas uniquement dans le choix d’intégrer ou non des bibliothèques ou des composants tiers, ou de développer des applications à partir de frameworks open source. D’autres choix effectués 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 : SACRIFIER LA SÉCURITÉ AU PROFIT DE LA RAPIDITÉ
Il n’est jamais surprenant d’apprendre que la sécurité a été sacrifiée au profit de la vitesse. Cela a toujours été le cas. Une étude menée par McAfee en 2014 auprès de 504 professionnels de la sécurité a révélé que « dans environ un tiers des organisations interrogées, les opérateurs ont reconnu qu’ils tentaient d’améliorer les performances du réseau en désactivant régulièrement des fonctionnalités de sécurité du pare-feu ».
Il s’avère que le développement ne fait pas exception. L’accent n’est pas mis sur la vitesse d’exécution, mais sur la rapidité du pipeline. Pour répondre à la demande de mises sur le marché plus rapides des applications et de leurs mises à jour, beaucoup reconnaissent faire totalement l’impasse sur la sécurité pendant le développement. Une étude menée en 2017 par Arxan | IBM auprès de développeurs d’applications mobiles et IoT a révélé que 26 % des personnes interrogées ne soumettent leurs applications mobiles à aucun test de sécurité et que près de la moitié (48 %) ne testent pas leurs applications IoT. Pour 69 % des répondants, la pression liée aux délais de livraison explique pourquoi la sécurité est souvent négligée.
Un sondage réalisé auprès des participants à notre événement client, « Agility », cet été, a confirmé qu’il s’agissait bien d’une réalité. Plus de la moitié d’entre eux — 62 % — ont reconnu avoir privilégié la rapidité au détriment de la sécurité au sein de leur organisation.
Il y a ensuite les choix faits quant à la manière dont les organisations traitent les vulnérabilités découvertes. L’analyse de Black Duck a révélé que 10 % des applications analysées en 2018 étaient encore vulnérables à la faille Heartbleed de 2014. Une étude de ServiceNow menée par Ponemon a révélé un constat inquiétant : 57 % des victimes de violations de données ont déclaré qu’elles auraient pu les éviter en installant un correctif disponible.
LES CHOIX ONT DES CONSÉQUENCES
Du premier jour du développement jusqu’à la phase suivant le 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 au fait de prendre un hamburger ou une salade au déjeuner : ce sont des décisions dont les répercussions peuvent se faire sentir non seulement au sein du service informatique et de l’entreprise, mais aussi auprès des clients qui comptent sur les fournisseurs d’applications pour prendre la sécurité au sérieux.
Très peu d’entre nous peuvent affirmer n’avoir jamais reçu un courrier commençant par « Cher utilisateur de l’application » nous informant que nos données ont été exposées. Cela ne nous autorise pas à relâcher notre vigilance en matière de sécurité ; au contraire, nous devons tous nous efforcer de mieux protéger les informations personnelles et confidentielles de nos clients.
La meilleure façon d’y parvenir est de reconnaître que chaque choix effectué dès le premier jour du développement est une occasion de renforcer la sécurité des applications que nous développons. Faites des choix réfléchis et judicieux.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
Pourquoi devriez-vous vous intéresser à WebAssembly ?
WebAssembly (Wasm) est un jeu d’instructions binaires portable, rapide et sécurisé, qui permet d’exécuter des applications hautes performances sur n’importe quelle plateforme.
Trois choses à savoir sur les applications d’IA
Les applications d’IA sont des applications modernes, mais elles présentent certaines particularités. Découvrez les points essentiels à connaître sur les applications basées sur l’IA.
État des lieux de la stratégie applicative 2022 : il est temps de moderniser les opérations
Il est devenu évident que, pour maintenir la dynamique de leur transformation numérique, les organisations doivent recentrer leurs efforts sur les fonctions métier. Si les expériences destinées aux clients restent prioritaires, il est également indispensable de permettre la numérisation de fonctions telles que les services juridiques, les ressources humaines et la finance. Les DSI prennent donc les commandes, tandis que la transformation numérique passe de la modernisation des applications à celle des opérations.
Clouds multiples ou multicloud : faciliter la transition
La gestion et la sécurisation des charges de travail deviennent complexes à mesure que les entreprises adoptent une stratégie de cloud connecté. Découvrez comment F5 répond au besoin d’une nouvelle approche de la mise en réseau multicloud.
L’expérience client dépend de la visibilité
Une enquête menée par Dimensional Research auprès de plus de 3 000 utilisateurs d’applications mobiles a confirmé ce que beaucoup d’entre nous pensent des attentes actuelles des clients.
Transformation numérique et explosion du portefeuille d’applications
La transformation numérique stimule la croissance des portefeuilles d’applications et modifie la manière dont celles-ci sont développées, déployées, intégrées et, en définitive, utilisées.