Le SAST (static application security testing) est une approche de sécurité bien établie, avec des dizaines d'outils disponibles sur le marché. Il analyse le code source ou le bytecode de l'application afin de détecter les vulnérabilités logicielles pouvant permettre à un cyberattaquant de s’introduire. Les outils SAST traditionnels protègent automatiquement tous les chemins et événements possibles dans lesquels une application pourrait se trouver et peuvent même déceler des bugs que les développeurs n’ont pas anticipés. Ils ont cependant quelques inconvénients. Ils ont la réputation d'être lents, de générer des faux positifs et d'être difficiles à utiliser. Les développeurs sont donc obligés de faire des compromis entre le temps nécessaire à l'exécution d'un scan, l'exhaustivité du scab et le nombre de faux positifs jugé acceptable.

Les dépendances doivent également faire l'objet d'une attention particulière

De leur côté les outils SCA (software composition analysis) aident à atténuer les risques qui se situent en dehors du code source du développeur. La vulnérabilité Log4Shell a mis en lumière les conséquences potentielles des attaques contre les paquets de logiciel tiers et open source qui sont utilisés comme éléments de base des applications. En effet, les applications logicielles modernes peuvent s'appuyer sur des centaines de paquets open source, définis comme étant des dépendances. Ces dernières découlent elles-mêmes d'autres paquets open source, dont les développeurs ne connaissent pas toujours l’existence et qui sont appelés des “dépendances transitives”. Les paquets open source peuvent couvrir des milliers d'opérations et de tâches à la place des développeurs. Les chiffres parlent d'eux-même. Aujourd'hui, plus de 98 % des applications contiennent du code open source et 75 % du code utilisé dans les applications est du code open source et non propriétaire.

La sécurité des paquets open source n’est pas garantie, notamment ceux qui ne sont plus activement maintenus. Pour y remédier, l’outil SCA analyse à la fois les dépendances directs et les dépendances transitives des applications, puis les compare avec les bases de données de vulnérabilités pour identifier les risques et les failles de sécurité. Enfin, les outils SCA identifient le type et la gravité des vulnérabilités trouvées et indiquent comment y remédier. L’analyse SCA aide également les entreprises à considérer les risques juridiques, en identifiant les licences des paquets et toutes les responsabilités ou obligations qui pourraient en découler.

Les outils SAST et SCA ont chacun un rôle essentiel à jouer dans le cycle de vie du développement logiciel. En les combinant, les développeurs peuvent obtenir une vision globale de la sécurité de leur application : les outils SAST pour tester le code source et détecter les failles de sécurité, et l’analyse SCA comme méthodologie de sécurité des applications pour gérer les composants open source. Pourtant de nombreux outils SCA et SAST ont la réputation d'être difficiles à intégrer et de créer un grand nombre de faux positifs. Leur adoption reste donc faible puisque seulement 38 % des entreprises déclarent utiliser des contrôles de sécurité en open source. La combinaison des deux approches n’est pour le moment que très peu répandue chez les développeurs. En effet, pour beaucoup d’entreprises le temps supplémentaire nécessaire à une détection plus poussée des faux positifs ne vaut pas le coup.

Comment choisir ses outils SAST et SCA

Au sein des pipelines de développement de logiciels modernes ayant adopté une CI/CD DevOps, il n’est pas envisageable d'attendre plusieurs jours pour que les tests soient terminés et que les vulnérabilités soient corrigées. Ainsi, les équipes de développement peuvent avoir à effectuer des centaines de modifications par jour. Pour fluidifier le processus, elles doivent être en mesure d'effectuer elles-mêmes des contrôles de sécurité pendant qu'elles codent. Il faut donc que les outils SAST et SCA soient adaptés aux développeurs, à leur flux de travail et aux outils qu’ils utilisent pour ne pas les forcer à se plier à de nouvelles pratiques. Une approche DevSecOps implique que les développeurs puissent s'assurer que le code est sécurisé au moment où il est écrit, et non pas lors d’une étape distincte et ultérieure qui ralentit le processus de déploiement en faisant passer le code des développeurs aux équipes de sécurité.

Dans l'environnement logiciel actuel, ces deux séries d'outils, bien que répondant à des objectifs différents, ont un objectif commun : permettre aux développeurs de prendre en charge la sécurité des applications, au fur et à mesure que le code est créé et modifié. Par conséquent, il y a un avantage considérable à consolider les deux outils ou à les exécuter simultanément afin de réduire le nombre d'étapes, de diminuer les compétences nécessaires à leur maîtrise. Enfin, le logiciel de test doit être basé sur le cloud computing et le code doit être optimisé de manière à ne pas créer de retards pour le développeur. Le monde du développement logiciel évolue à un rythme effréné et a donc besoin d’outils qui savent s’améliorer au même rythme.

Les pratiques et les outils auparavant répandus, lorsque les versions de logiciels étaient déployées à un rythme plus graduel, sont heureusement en train de disparaître. Les outils sont maintenant de meilleure qualité et plus nombreux. La sécurité ne peut toutefois pas être sacrifiée sur l'autel de cette évolution, et il est donc impératif de choisir des outils adaptés aux pratiques actuelles.