Au cours des dernières années, l’adoption d’Agile et de DevOps a augmenté, et avec elle, nous avons également observé la montée en puissance de DevSecOps. Une telle pratique recommande de déplacer les tests de sécurité vers la gauche et de corriger les vulnérabilités de sécurité le plus tôt possible au sein du SDLC. Bien que l’idée soit excellente et que nous ayons vu la montée en puissance de nombreux types d’outils de test de sécurité, pour les développeurs qui ne sont pas des experts en sécurité, trouver l’aiguille dans une botte de foin blanche à l’aide de tels outils est un défi et un retard dans le cycle de publication global .
La pile d’outils disponible aujourd’hui pour les développeurs et les ingénieurs en sécurité pour exécuter des tests de sécurité se compose de SAST, DAST et SCA, et bien qu’il s’agisse d’outils puissants et principalement automatisés, ils ont leurs limites lorsqu’il s’agit d’inonder les développeurs avec beaucoup de problèmes de sécurité, faux positifs et autres bruits.
Dans cet article, je vais donner un bref aperçu des outils SAST et SCA pour le meilleur et pour le pire, et suggérer d’utiliser l’approche d’observabilité dynamique dans le cadre de la hiérarchisation globale des CVE et de la réduction du bruit du pipeline du développeur.
Pour donner un peu de contexte à cet article, je voudrais apporter un rappel de l’une des vulnérabilités de sécurité les plus célèbres et les plus dangereuses de ces dernières années. La vulnérabilité Log4Shell trouvée dans le populaire utilitaire de journalisation Java Log4j a été considérée par le Department of Homeland Security comme « l’une des vulnérabilités logicielles les plus critiques de l’histoire ». Le problème avec cette vulnérabilité était que, même s’il s’agissait d’un problème très risqué, il n’affectait pas nécessairement toutes les applications qui utilisaient la bibliothèque, car une telle vulnérabilité n’était pas exposée dans le chemin d’exécution de toutes les applications.
Test de sécurité des applications statiques
SAST est une méthodologie de test qui analyse le code source d’une application logicielle pour identifier les vulnérabilités de sécurité potentielles avant le déploiement de l’application, et dans de nombreux cas, elle est également appelée test en boîte blanche.
L’analyse du code est effectuée automatiquement pour les identifications de problèmes de sécurité courants et utilise des profils de sécurité basés sur des règles, des langues et d’autres normes pour garantir que la couverture est appropriée et à jour., Parmi les éléments clés qui sont analysés, vous trouver des éléments tels que les faiblesses de validation des entrées, les dépassements de mémoire tampon et les attaques par injection SQL.
Si vous regardez un exemple de sortie de l’un des outils SAST commerciaux sur le marché (dans notre cas, Codacy), vous pouvez observer plus d’une centaine de violations de sécurité qu’un développeur obtiendrait lors d’une exécution SAST. Une telle exécution peut se produire à chaque nouvelle validation de code ou à d’autres déclencheurs, ce qui génère beaucoup de pression sur les développeurs.
Du point de vue du développeur, le rapport ci-dessus déclenche un flux de travail assez fastidieux consistant à examiner d’abord les problèmes classifiés hautement prioritaires, à les analyser et, le cas échéant, à appliquer un correctif et à les redéployer. Il s’agit d’un long processus continu où le développeur ne dispose pas, dans de nombreux cas, des informations pertinentes pour savoir si un problème de sécurité a même un impact sur les chemins d’exécution de l’application ou non.
Dans cet esprit, gardez à l’esprit que le processus d’analyse SAST ne s’exécute que sur le code source propriétaire de votre application et ne couvre pas le code source des bibliothèques tierces. D’après l’expérience historique et l’incident log4J mentionné ci-dessus, de nombreux problèmes de sécurité sont attribués à des codes tiers. Cela signifie que même après avoir exécuté le SAST et, espérons-le, résolu les problèmes, les parties du code qui exploitent le code open source tiers ne sont pas encore couvertes. Pour cette partie, les développeurs doivent utiliser les outils SCA.
Analyse de la composition logicielle
L’analyse de la composition logicielle (SCA) est une méthodologie de sécurité des applications pour la gestion des composants open source dans le développement de logiciels. Ce processus permet aux équipes de développement de suivre et d’analyser facilement tous les composants open source qui sont intégrés à un projet. L’objectif de SCA est de minimiser les risques de sécurité qui pourraient potentiellement nuire au projet en identifiant les vulnérabilités et les exploits potentiels dans les bibliothèques tierces. Dans le tableau de comparaison ci-dessous créé par GitHub, nous pouvons clairement voir comment SCA et SAST se complètent et maximisent l’analyse de sécurité de la couverture du code. Nous pouvons également en apprendre davantage sur les pièges des deux ; faux négatifs et positifs, ce qui se traduit par plus de bruit pour les développeurs.
En un mot, les outils SCA s’exécutent sur les bibliothèques open source et tierces de l’application testée et créent une nomenclature logicielle (SBOM) qui contient toutes les bibliothèques tierces utilisées dans l’application.
À la fin d’une analyse de code SCA, ces outils génèrent une comparaison des résultats avec une liste publique de vulnérabilités connues (CVE) pour identifier celles qui pourraient avoir un impact potentiel sur le code.
Comme souligné dans l’exemple SAST ci-dessus de CODACY, vous trouverez ci-dessous un exemple différent d’une sortie d’analyse SCA fournie par CAST.
Ici aussi, les développeurs reçoivent une longue liste de résultats qui, bien que classés par gravité, n’ont pas le contexte et la hiérarchisation basés sur l’application réelle telle qu’elle est utilisée dans l’exécution.
Le résultat des outils SAST et SCA du point de vue des développeurs est qu’ils sont submergés par l’ampleur des indicateurs de sécurité que les outils reflètent, et ils n’ont pas de moyen rapide et facile de hiérarchiser tous ces problèmes d’une manière qui ne impact sur la vitesse de livraison des logiciels. Pour résoudre de manière proactive les problèmes de sécurité « BON », les développeurs ont besoin d’un moyen de déterminer si une classe pertinente est chargée, si le chemin de code est appelé, et plus d’informations spécifiques à l’application.
Observabilité dynamique : bénéficier de SCA et de SAST pour un meilleur flux de travail DevSecOps ?
Comme mentionné précédemment, les développeurs doivent obtenir un « filtre » pour tout bruit de sécurité que les outils traditionnels exposent dans leurs tableaux de bord et dans les pipelines CI/CD. À cette fin, il existe une excellente méthodologie appelée Dynamic Observability qui permet aux développeurs de dépanner les applications en direct directement à partir de leurs IDE – à la demande, en temps réel et quel que soit l’endroit où l’application est déployée.
Lors de l’exécution de SAST et de SCA pour obtenir le SBOM des CVE, vous pouvez tirer parti d’une méthode aussi moderne pour déterminer facilement au moment de l’exécution si une vulnérabilité signalée comme log4J ou un problème plus récent dans les bibliothèques Python a un impact réel sur votre application. En outre, vous pouvez également déterminer spécifiquement l’impact d’une telle vulnérabilité sur un segment de vos utilisateurs ou clients, et y remédier efficacement.
Une telle approche peut contribuer à la réduction du bruit en déterminant uniquement les CVE qui sont réellement exploitables en production au lieu d’être inondés de centaines d’alertes.
Exemple concret : Priorisation Lightrun CVE
Lightrun est une plate-forme d’observabilité dynamique qui permet aux développeurs d’ajouter des journaux, des métriques et des instantanés aux applications en direct, sans avoir à publier une nouvelle version ni même à arrêter le processus en cours d’exécution.
En vous permettant d’interroger votre code d’exécution à la demande et en temps réel, Lightrun peut être utilisé pour déterminer l’impact réel d’une vulnérabilité donnée sur votre application en direct et ainsi hiérarchiser vos alertes de sécurité.
Ce processus se compose de trois étapes.
1. Recevoir une alerte CVE via l’outil SAST/SCA ou équivalent.
Vous recevez une alerte vous informant qu’une vulnérabilité a été signalée dans l’une des bibliothèques tierces utilisées par votre application.
2. Déterminer l’impact de la vulnérabilité sur le déploiement proprement dit.
En utilisant Lightrun, vous pouvez déterminer si :
- Le code de la vulnérabilité est en fait chargé dans un chemin de code en direct.
- Quels utilisateurs/chemins/clients sont concernés ?
- Quelle est l’étendue de la vulnérabilité (c’est-à-dire quelles sections du code sont affectées).
- La fréquence à laquelle la vulnérabilité pourrait être exploitée (en examinant le nombre d’invocations de chemin de code).
- Ajoutez des journaux, prenez des instantanés et définissez des métriques à divers endroits dans le code pour mieux comprendre l’impact de la vulnérabilité.
3. Redéfinissez les priorités en fonction de l’effet réel sur l’application Runtime.
Armé des connaissances pertinentes, vous pouvez désormais redéfinir la priorité de toutes les vulnérabilités de gravité « critique » et « élevée » et les atténuer dans le bon ordre.
Ne vous contentez pas de me croire sur parole, ce qui suit est un exemple (avec l’aimable autorisation de Tom Granot) d’exécution de l’observabilité dynamique sur un code pour déterminer s’il est impacté par le récent log4J.
Observabilité dynamique : le résultat final
En utilisant des solutions comme Lightrun, les développeurs obtiennent les informations dont ils ont besoin pour hiérarchiser les alertes directement depuis l’application en cours d’exécution, directement dans leurs IDE.
Les développeurs interrogent leur code qui s’exécute en production et discerne quels modules spécifiques de celui-ci sont vulnérables et lesquels ne le sont pas. C’est ainsi qu’ils hiérarchisent efficacement les alertes de sécurité et conservent un peu de bon sens !
Cette dernière évolution de l’observabilité dynamique permet aux développeurs de hiérarchiser correctement leurs alertes de sécurité et de réduire massivement le nombre de faux positifs. Ils peuvent passer moins de temps à se gratter la tête sur des alertes déroutantes et plus de temps à écrire du code précieux (et sécurisé !).
Le déplacement de DevSecOps vers la gauche en combinant la puissance de SAST, DAST et SCA avec des outils d’observabilité dynamiques est un changement majeur vers une productivité accrue et une meilleure correction des vulnérabilités de sécurité qui augmentent d’année en année.