La quête du code source fiable et securisé par Sébastien Giora, Advens

Les GS Days 2015 furent l’occasion pour Advens de présenter une approche simple et pragmatique de détection et de correction des vulnérabilités dans le code source d’une application. Cette approche, en collaboration avec SonarSource, permet dans le même temps de maintenir le niveau de sécurité sur le long terme.

Aujourd’hui, la sécurité du code source se résume à la mise en place de tests d’intrusion et/ ou de revue de code¹.

Pour le RSSI, ces deux méthodes lui permettent d’appréhender le niveau de sécurité, via des cabinets externes, des applications à publier.

Pour les développeurs, cette approche, arrivant tard dans la chaine de développement, est souvent mal perçue. En effet, le cabinet externe n’implique pas assez le développeur et fournit souvent des rapports trop complexes, sans prise en compte du contexte logiciel. L’approche sécuritaire est donc identifiée comme un couperet que l’on veut à tout prix éviter, ou repousser aux calanques grecques.

Au final, le résultat n’est satisfaisant pour personne. Au point de remettre en cause l’intérêt même de ces méthodes.

Il est donc important d’impliquer fortement les développeurs pour réussir la sécurisation de son application, et cela au plus tôt dans le cycle de développement. Encore faut il savoir parler « développeur » !!

La gestion d’une chaine de production applicative a bien changé depuis le début de l’informatique. L’époque des makefiles, des sources stockées sur un disque réseau partagé, des éditeurs de texte simple est révolue. Aujourd’hui, une équipe de développement parle d’intégration continue, voire de déploiement continu. Cela signifie qu’il est impératif d’intégrer la sécurité applicative dans cette approche en apportant à l’équipe les outils nécessaires pour appréhender correctement le processus de développement.

L’approche traditionnelle d’audit de code source s’intéresse, dans la majorité des cas, à l’ensemble du code source de l’application ce qui peut donner lieu à d’interminables négociations, à du pushback des équipes de développements et, comble de l’ironie, à des injections de potentielles régressions fonctionnelles. Si on reste cohérent avec le changement de paradigme lié à la pratique de l’intégration continue, seul le code source qui a évolué entre deux versions devrait être analysé. Les effets de bords positifs induits sont nombreux : effort de mise à niveau lissé dans le temps, pas de risques de régressions fonctionnelles comme on touche uniquement à du code très récent, pas de pushback des équipes de développement comme on touche à du code frais chez eux et donc de leur responsabilité … C’est la fameuse métaphore de la fuite d’eau.

Il est donc possible en introduisant un mécanisme de contrôle continu d’imposer les besoins sécurité aux développeurs (que vous aurez précédemment formé correctement à l’utilisation des bibliothèques sécurisée et au code sécurisé voir slides ci-dessous) et de s’assurer du maintien de ce niveau.

Slides disponibles ici : Secure Coding For Java – Une introduction from Sebastien Gioria

L’outil d’analyse de code SonarQube² permet d’effectuer ces contrôles en continu (ou du moins, à la demande ou à chaque buil). Connu de tous, et souvent bien implémenter dans la communauté des développeurs, il détecte les défauts logiciels grâce à l’intégration de règles connues (CERT, MITRE, OWASP, etc).

Ce logiciel, largement adopté par les développeurs, possède une interface cohérente et supporte de nombreux langages (JAVA, JavaScript, COBOL, C/C++, ABAP, PHP, ….). C’est donc tout naturellement que nous avons mis en place avec SonarSource le projet OWASP-SonarQube

Ce projet, développé en commun avec l’OWASP (via le support d’Advens par son expertise en sécurité applicative) et SonarSource, présente déjà plus de 100 règles destinées à la sécurité sur l’ensemble des plug-ins langage. Il s’appuie sur des référentiels tels que MITRE-CWE, Cert Secure Coding,… De nouvelles règles de détection sont ajoutées régulièrement.

Intégrer la sécurité applicative au cœur du cycle de développement (et ne pas imposer uniquement de grandes politiques et des outils non développeurs) va vous permettre d’améliorer au fur et à mesure la sécurité des applications.

Je vous invite donc à regarder ce projet OWASP, et à contribuer via les différents moyens dont vous pouvez disposer.

Les slides de l’événement ici : La Quete du code source fiable et sécurisé – GSDAYS 2015 from Sebastien Gioria

Sébastien Gioria
Consultant Sénior en Sécurité des Systèmes d’Informations.
¹ (sur ce sujet, une présentation lors de l’Application Security Academy Saison-2 a été effectuée, je vous invite a la revoir http://www.advens.fr/news/application-security-academy-saison-2-episode-3)
² https://www.owasp.org/index.php/OWASP_SonarQube_Project).