Par Bernard Montel, Directeur technique EMEA et Security Strategist de Tenable.
Les services Web d’hébergement et de gestion de codes (ou référentiels) deviennent un vecteur de choix pour les hackers. L’attaque réussie sur les utilisateurs de SolarWind, qui reposait sur une ligne de code malveillant implanté dans un patch pourtant jugé de confiance a mis la puce à l’oreille des acteurs malveillants. Il faut noter que ces attaques, dites « low cost/high impact », peuvent, comme leur nom l’indique rapporter beaucoup pour un investissement très minime. Une ligne de code malveillante bien placée dans un patch ou sur un référentiel tel que GitHub ou MTN peut très vite se répandre et infecter de très nombreux systèmes. En fin d’année, nous avons ainsi vu une recrudescence de lignes de code malveillantes, toujours mieux dissimulées, apparaître sur ces référentiels Celles-ci font peser des menaces croissantes sur les entreprises, à cela s’ajoutent les cycles de développement de type DevOps de plus en plus rapides.. Dans ce contexte, il est d’autant plus important de penser la sécurité des applications dès leur conception et de s’appuyer sur les logiques de DevSecOps, quitte à ralentir les rythmes de développement. Le jeu en vaut la chandelle.
Dans ce contexte, la première chose à préciser est que les services Web d’hébergement de codes ne peuvent être tenus responsables des lignes de code qu’ils hébergent. Ce sont des espaces communautaires qui doivent s’autoréguler, mais à mon sens, il n’est pas du ressort de GitHub ou de MTN de vérifier tout le code qu’ils hébergent. Cela dit, c’est donc aux développeurs de s’assurer que le code qu’ils utilisent est sain.
C’est justement toute la problématique des logiciels “Open-Source”. En théorie, grâce à la transparence du code source, ils sont censés permettre une découverte des failles de sécurité rapides par la “communauté”. En pratique, l’exemple de Log4Shell nous a prouvé les limites de ce modèle et l’ampleur de la diffusion d’un code vulnérable très largement répandu et donc l’impact est littéralement planétaire.
Les développeurs disposent aujourd’hui de plusieurs outils d’analyse du code qui s’appuient sur des bases de connaissance pour détecter l’ensemble des menaces connues. Si une vulnérabilité est introduite sur du code malveillant et qu’elle est connue, les outils permettent de la détecter. Il en va de même pour l’infrastructure avec des outils qui permettent de s’assurer que les configurations ne laissent pas de failles béantes ouvertes pour les hackers (On parle d’”Infrastructure as Code”). Il existe aussi un ensemble de bonnes pratiques à respecter, comme s’appuyer sur des codes issus de sources de confiance, la vérification des codes, etc. Toutefois au-delà de ces choses simples, c’est l’ensemble du processus de développement qu’il faut accepter de revoir en se tournant vers les préceptes du DevSecOps.
Et c’est un changement radical dans la doctrine de développement. En l’espace de 20 ans, nous sommes passés d’architecture client-serveur sur lesquels les développements prenaient plusieurs mois, à des infrastructures à base de microservices sur lesquelles il est possible de sortir des applications en quelques jours. Les cycles de développement n’ont fait que s’accélérer et il va falloir aujourd’hui lever un peu le pied pour éviter de mettre des failles partout. Les développeurs, qui je le rappelle, n’ont pas à être considérés comme des experts de la sécurité, doivent se mettre à la même table que ces derniers et accepter de discuter plus en amont de la protection des applications. On ne peut plus se contenter de développer une application en 3 jours et ensuite la mettre en production en demandant aux équipes de sécurité de boucher les trous.
Face à cela, il faut vraiment injecter dans le cycle de développement un volet sécurité. Ce n’est pas seulement une réponse technique, mais bien organisationnelle. Cela va effectivement ralentir le cycle de développement, mais pour la bonne cause. Nous faisons aujourd’hui face à des hackers qui font du low cost/high impact et mise sur les rythmes effrénés de développement pour diffuser le plus largement des vulnérabilités. La réponse est de faire l’inverse, à savoir du high cost/low impact. Avec le DevSecOps, il est possible d’enrichir le processus de développement dès le début et d’assurer une protection bien plus élevée des applications. L’enjeu est ainsi d’analyser le code le plus tôt possible pour être sûr de ne pas diffuser de vulnérabilité et minimiser le risque.
