Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Quand l'analyse de composition logicielle (SCA) remplace-t-elle SAST ou DAST?

Par Arthur Hicken

22 août 2019

3  min lire

La réponse courte est jamais. Là, je viens de vous faire gagner suffisamment de temps pour que vous puissiez faire ce qu'il faut et exécuter SAST et DAST et travailler sur le renforcement de votre code au lieu d'essayer de tester la sécurité dans votre application.

Cela ressemble-t-il aux débuts d'une diatribe? Peut-être. Mais regardez, chaque fois qu'une nouvelle technologie, processus ou technique se présente, il y a des gens qui pensent que c'est la réponse à tout. Cela résoudra la sécurité des logiciels, économisera du temps de développement et de test, et éliminera peut-être même la faim dans le monde pendant qu'elle y est. Ok, je deviens dramatique. Mais dire que SCA finira par remplacer SAST signifie essentiellement que parce que vous recherchez des vulnérabilités connues dans le code d'autres personnes, vous n'avez plus à vérifier les vôtres.

Qu'est-ce que l'analyse de la composition logicielle (SCA)?

SCA est l'analyse de la composition logicielle. Théoriquement, il fonctionne main dans la main avec une nomenclature logicielle (quelque chose qui n'existe pas actuellement pour la plupart) et garde une trace des autres bibliothèques et composants utilisés dans votre application. Actuellement, ces outils analysent principalement les composants open source de votre application et ne fonctionnent pas nécessairement avec une nomenclature. (REMARQUE: certains de ces outils exécutent également d'autres fonctions, telles que la recherche d'extraits de code couper-coller à partir de projets OSS ou l'identification et la gestion des problèmes de licence OSS. Les deux sont intéressants et importants, mais ne remplacent toujours pas ce que fait SAST.)

L'une des principales fonctions de SCA est de rechercher les vulnérabilités connues des composants de votre application. Ceci est important afin que vous puissiez éviter les problèmes du jour zéro, ainsi que pour résoudre le problème que vous pourriez ne pas avoir de source pour certains composants et que vous ne pouvez donc pas utiliser SAST pour eux.

OWASP fournit des outils pour la sécurité de la chaîne d'approvisionnement

Je dois dire que SCA est certainement un élément précieux de votre boîte à outils pour sécuriser vos systèmes logiciels. L'organisation de sécurité populaire et utile connue sous le nom d'Open Web Application Security Project (OWASP) a même ajouté ce concept à la dernière itération de la populaire liste OWASP Top 10 des risques de sécurité les plus critiques aujourd'hui. Il apparaît comme élément A9 - Utilisation de composants avec des vulnérabilités connues. Si vous n'utilisez pas OWASP, vous devriez probablement. Si vous ne vérifiez pas votre application pour les vulnérabilités connues par rapport au CVEet un  NVD bases de données, vous devriez. Ces sources gardent une trace des attaques réelles et des correctifs et autres remédiations disponibles.

OWASP a même construit un outil appelé Vérification de la dépendance OWASP qui peut faire ce travail pour vous. Comme tout ce que l'OWASP a à offrir, il est gratuit. Dependency-Check est un utilitaire d'analyse de la composition logicielle qui identifie les dépendances du projet et vérifie s'il existe des vulnérabilités connues et divulguées publiquement.

La sécurité de la chaîne d'approvisionnement logicielle est un élément essentiel de la sécurité des applications

Je dois admettre qu'il n'y a pas trop d'années, la chaîne d'approvisionnement des logiciels était un toopic le plus souvent négligé. Certaines personnes clés, dont beaucoup font partie Forum sur l'assurance de la chaîne d'approvisionnement logicielle (SSCA) a travaillé dur pour mettre en évidence cette faiblesse de la sécurité des applications en se concentrant non seulement sur votre code, mais sur votre chaîne d'approvisionnement. En fait, le forum SSCA, qui est hébergé par le US Department of Defense (DoD), Département de la Sécurité Intérieure des États-Unis (EDS), Administration des services généraux (GSA) et le Institut National des Standards et de la technologie (NIST), s'appelait auparavant le Software Assurance Forum (SwA) et ils ont changé le nom pour aider à mettre davantage l'accent sur la chaîne d'approvisionnement. Mais l'intention était de expand le focus, ne le déplacez pas de votre code vers celui de quelqu'un d'autre.

Les Forum sur l'assurance des logiciels et de la chaîne d'approvisionnement (SSCA) fournit un lieu aux participants gouvernementaux, industriels et universitaires du monde entier pour partager leurs connaissances et leur expertise concernant les risques liés aux logiciels et à la chaîne d'approvisionnement, les pratiques efficaces et les stratégies d'atténuation, les outils et les technologies, ainsi que toute lacune liée aux personnes, processus ou technologies impliqué.

Dans la pratique, SCA est une activité de test - s'assurer que votre application est comparée à une liste et qu'elle est conforme à cette liste (comme les vulnérabilités connues telles que NVD). Inversement, SAST n'est pas avant tout une fonction de test (hérésie, je sais…) mais plutôt une fonction d'ingénierie. La plus petite valeur de SAST est de trouver une faiblesse ou une vulnérabilité plus tôt que le pen-testing. La plus grande valeur de SAST est de vous guider pour durcir votre code en premier lieu. Arrêtez d'essayer de colmater les fuites et de créer du code qui ne fuira pas en premier lieu. C'est le seul moyen de prendre une longueur d'avance en matière de sécurité des applications. Si vous le faites parfaitement, vous aurez toujours besoin de SCA, car vous avez toujours le problème de tous ces composants dans votre application, ainsi que des autres programmes avec lesquels il interagit et du système d'exploitation lui-même. Si vous faites bien SCA, vous avez toujours besoin de SAST car, bien que vous ayez résolu des problèmes dans le code d'autres personnes, vous n'avez rien fait pour vous-même. Les objectifs se complètent et ne se remplacent pas.

En résumé, SCA est génial, vous le voulez, en fait vous en avez besoin. Je suis heureux que cela retienne plus d'attention que par le passé. Mais dire qu'il remplacera DAST ou SAST, c'est comme dire que vous avez un marteau et que vous n'avez pas besoin d'un tournevis.

Intégrez la sécurité dans votre application dès le début

Par Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.