Développeurs et RSSI unis contre les cybercriminels
Des études comme celles du Cigref montrent que sur une échelle de 1 à 100, la détection d’une faille de sécurité dans une application coûte 100 si elle a lieu lors de la production, 10 lors des tests de qualité, et 1 lors du développement. Aussi, s’il fut un temps où les entreprises devaient réaliser 2 ou 3 nouvelles versions majeures de leur système d’information par an, elles doivent aujourd’hui en concevoir jusqu’à 20 par mois, quand ce n’est pas par semaine ou par jour.
Avec la transformation numérique, l’activité des grandes entreprises et des administrations évolue et est désormais dépendante d’applications : ces entreprises deviennent de véritables éditrices de logiciels. A mesure que la digitalisation accélère, la fabrication d’applications a dû être repensée afin de suivre la cadence. C’est ainsi que les entreprises se sont restructurées et ont donné naissance aux méthodes agiles et au DevOps. Elles sont aujourd’hui utilisées par toutes les entreprises impliquées dans des chantiers de transformation numérique. Leur objectif est de rapprocher les équipes de développement et de production, mais également d’automatiser la chaîne de fabrication d’applications de bout en bout.
Une fois cela mis en place, c’est au tour de la sécurité des applications d’être reconsidérée, et ce en 3 étapes :
1. Vérifier que le code de l’application ne comporte pas de
failles. La sécurité doit être intégrée dès le début de la chaîne de fabrication pour
des raisons de gain de temps et d’argent. En effet, ce n’est pas la détection
des failles de sécurité qui est onéreuse, mais leur correction. Naturellement,
plus tôt on identifie une vulnérabilité, plus tôt on peut la corriger.
2. Vérifier la propreté des librairies open-source. Aujourd’hui,
les développeurs assemblent presque plus qu’ils ne développent. Aussi, ils se
procurent certains composants d’applications dans des librairies open-source.
Gare aux malwares qui pourraient s’y cacher !
3. Simulation de piratage. Effectuer un test de pénétration, ou
simulation de piratage de l’application avant envoi en production, peut être
aujourd’hui réalisé par des solutions logicielles de tests dynamique. Ces dernières
pallient les problématiques de l’ancienne méthode qui consistait à faire
réaliser la manœuvre par une personne. Le coût était alors très élevé et les
ressources humaines très rares : les entreprises pouvaient donc difficilement
tester toutes leurs applications.
Équipes sécurité et développeurs : opération séduction
Intégrer la détection des failles de sécurité au cycle de fabrication le plus tôt possible permet de rapprocher les impératifs de sécurité des RSSI, des objectifs de délais de livraison des développeurs. En effet, ces derniers se regardent souvent d’un mauvais œil. D’un côté, le RSSI estime que l’application livrée par le développeur est truffée de failles de sécurité : un véritable enjeu puisque c’est par les applications que les cybercriminels infiltrent les entreprises aujourd’hui. Si auparavant les RSSI devaient protéger l’infrastructure informatique de l’entreprise, les réseaux, les identités et accès, c’est aujourd’hui dans le code même des applications que se trouvent les portes d’entrée pour les hackers. Mais de l’autre côté, les développeurs ont le sentiment que les équipes de sécurité jugent leur travail sans le comprendre et qu’ils leur imposent de corriger des erreurs découvertes très tard, quand ils ont déjà commencé à œuvrer à tout autre chose. Ils se sentent ralentis dans leurs impératifs de livraison imposés par les lignes métiers.
L’intégration de la sécurité au plus tôt dans le cycle permet aux développeurs de ne plus voir la sécurité comme une contrainte, mais comme un gage de qualité. Mettre en place des solutions de sécurité très intégrées dans les environnements de travail des développeurs et le plus automatisées possible permet de déceler les vulnérabilités au plus tôt et donc de leur faire gagner du temps.
Les faux-positifs ne sont pas une fatalité
L’une des principales sources de frustration des développeurs sont les faux positifs. Ces derniers consistent en des failles de sécurité détectées par les RSSI, qui en réalité n’en sont pas dans le contexte applicatif donné. Une fois la prétendue faille remontée, le développeur doit mettre en pause son travail en cours, revenir sur une application sur laquelle il a terminé d’œuvrer depuis 3 semaines pour la corriger, et se rendre compte qu’il s’agit en réalité d’un faux positif. Pour y pallier et optimiser les fonctionnalités de détections de vulnérabilités, des modules d’intelligence artificielle et de machine learning peuvent être intégrés.
En entreprise, la sécurité n’est pas seulement l’affaire du RSSI, elle est la responsabilité de tous, et en particulier du développeur lorsqu’il s’agit des applications. C’est pourquoi l’éducation est également un enjeu de sécurité important. Former les développeurs aux risques des failles de sécurité et leur inculquer les bonnes pratiques pour un code robuste les aidera à s’acculturer aux nouvelles méthodes qui mettent à l’honneur la sécurité.