SAST et SCA : faites équipe avec Snyk

À mesure que les applications gagnent en complexité, leur sécurisation devient elle aussi plus complexe.

Le code source qui compose les applications comprend du code propriétaire, mais aussi une grande quantité de code open source tiers. Pour livrer du code sécurisé tout en maintenant un rythme de développement soutenu, les équipes de développement et de sécurité doivent donc associer l’analyse statique de la sécurité des applications (SAST) et l’analyse de la composition logicielle (SCA) dans le cadre d’une stratégie globale de sécurité logicielle.

Mais c’est plus facile à dire qu’à faire.

Plus ancienne et mieux établie, la stratégie de test SAST a traditionnellement constitué l’approche de référence en matière de sécurité des applications. Les professionnels ont le choix parmi des dizaines d’outils SAST, accompagnés de méthodologies et de bonnes pratiques bien documentées. Les solutions SAST souffrent toutefois d’une mauvaise réputation en matière de rapidité, de précision et de facilité d’utilisation. Ces inconvénients peuvent dissuader une équipe d’utiliser SAST ou la pousser à choisir SCA à la place.

Les solutions SCA traditionnelles ne font guère mieux : elles sont souvent difficiles à intégrer et génèrent beaucoup de faux positifs. Bien que les vulnérabilités des packages open source aient contribué à mettre SCA sur le devant de la scène, son adoption reste marginale : seules 38 % des organisations déclarent utiliser des contrôles de sécurité open source. Et même si elles analysent vos dépendances et leurs dépendances, les solutions SCA ne peuvent pas détecter les vulnérabilités du code que vous écrivez.

Mais utiliser séparément SAST et SCA va à l’encontre de la volonté croissante des organisations de limiter la prolifération des outils et de regrouper leurs outils de sécurité des applications. Le raisonnement conduit donc souvent à choisir entre SAST ou SCA, plutôt qu’à envisager SAST et SCA dans une approche combinée.

Dans cet article, nous verrons pourquoi associer SAST et SCA est la bonne approche, et comment mettre en œuvre les deux sans multiplier les outils.

Quelle est la différence entre SAST et SCA ?

Comprendre la différence entre SAST et SCA est essentiel pour adopter une approche combinée.

À quoi sert SAST ?

SAST est une méthodologie structurelle de test de la sécurité des applications qui analyse le code source ou le bytecode d’une application à la recherche de vulnérabilités, notamment celles du Top 10 de l’OWASP et des CWE. En plus du code source ou du bytecode, elle peut évaluer d’autres sources, comme la documentation et les spécifications. Les outils SAST modernes transforment le code d’origine en une représentation intermédiaire et exécutent différents types de tests à l’aide d’un ensemble de règles, généralement fondé sur un solveur logique.

L’avantage de SAST est que cette méthode couvre tous les chemins et états possibles d’une application et peut même détecter des bugs que les développeurs ne recherchaient pas au départ. Lorsqu’ils sont détectés, ces problèmes doivent être signalés avec leur emplacement précis ou le chemin suivi dans l’application, notamment le nom du fichier et le numéro de ligne, ainsi que des informations complémentaires sur le problème lui-même.

L’un des inconvénients des outils SAST traditionnels tient au compromis que leur éditeur doit trouver entre la détection des vrais problèmes, la détection de tous les problèmes possibles et les ressources de calcul utilisées. Ces outils font donc des compromis en surestimant le comportement des applications et en acceptant un certain taux de fausses alertes et de problèmes non détectés, afin de réduire le temps de calcul. Malgré cela, l’analyse de projets volumineux avec des outils SAST traditionnels peut prendre plusieurs jours, voire plusieurs semaines.

À quoi sert SCA ?

Les applications modernes s’appuient sur des dizaines, voire des centaines, de packages open source, souvent appelés dépendances. En effet, 98 % des applications contiennent des logiciels open source. Ces dépendances s’appuient à leur tour sur d’autres packages open source, appelés dépendances transitives. Les packages open source couvrent des tâches très diverses, du simple formatage de texte aux frameworks et environnements d’exécution plus complexes.

Une bonne pratique courante consiste à traiter les packages open source comme des unités indivisibles. Il est possible de les corriger ou d’en modifier le code, à condition de contribuer ces changements au package et de les y intégrer. Les modifications locales rompent le versionnage du package et risquent d’être écrasées lors du téléchargement d’une nouvelle version.

SCA est une méthodologie de sécurité des applications qui consiste à analyser les dépendances open source utilisées, directement ou indirectement, puis à mettre les résultats en corrélation avec des données sur les vulnérabilités afin de suivre celles que ces dépendances pourraient contenir. Lorsqu’elles sont détectées, ces vulnérabilités sont signalées avec des informations à leur sujet et, dans certains cas, la correction recommandée. SCA aide également à cartographier les risques juridiques liés à l’utilisation de logiciels open source, en identifiant les licences incluses dans les packages.

Pourquoi utiliser SAST et SCA ensemble ?

Au vu des différences fonctionnelles entre ces deux méthodologies de test, il est clair qu’une comparaison directe n’a pas de sens.

Elles ont certes certains points communs, comme une mise en œuvre précoce dans le processus de développement et l’analyse du code source, mais elles couvrent deux types distincts de code qui composent une application : SAST contribue à réduire les risques liés au code écrit en interne, tandis que SCA aide à atténuer ceux qui sont associés au code développé en dehors de l’organisation.

Une approche efficace de la sécurité des applications doit donc intégrer des outils de tests de sécurité capables de gérer et d’atténuer ces deux types de risques. Cette approche offre une visibilité complète sur le code propriétaire et les composants open source, permet de détecter et de corriger les problèmes plus tôt et tout au long du cycle de développement, et réduit ainsi les risques globaux.

Les critères essentiels d’une approche combinée

Opter pour une approche combinée n’est pas une décision simple. Intégrer SAST et SCA à un programme de sécurité des applications peut représenter un défi culturel et technique.

Le modèle DevSecOps confie davantage de responsabilités en matière de sécurité aux développeurs. Pourtant, l’expérience passée et actuelle des solutions traditionnelles rend difficile l’adoption d’une méthodologie de test, sans parler de deux. Certaines équipes peuvent être réticentes à ajouter encore un outil de sécurité à ceux qu’elles utilisent déjà.

La solution la plus simple pourrait consister à intégrer les outils SAST et SCA au pipeline CI/CD et à renvoyer les résultats aux développeurs. Mais cela dissocie le processus et oblige à attendre la fin des analyses et l’application des correctifs avant les déploiements. Dans l’univers agile du DevOps, retarder une livraison de plusieurs semaines n’est tout simplement pas envisageable.

Pour réussir, un programme combinant la sécurité des applications doit donc s’appuyer avant tout sur des solutions adaptées aux développeurs. Ceux-ci sont plus susceptibles d’utiliser des outils SAST et SCA qui s’intègrent rapidement et facilement à leurs workflows existants, dès les premières étapes, plutôt que des outils lents, difficiles à utiliser et déployables uniquement à des stades avancés du développement.

De plus, un workflow unifié, dans lequel les analyses SAST et SCA s’exécutent simultanément ou sont regroupées dans un même outil, réduit la complexité pour les développeurs et les coûts globaux pour les équipes de sécurité.

L’approche Snyk : Snyk Code et Snyk Open Source

La plateforme Snyk propose une approche combinée de la sécurité des applications fondée sur SAST et SCA. Elle permet de développer rapidement et en toute sécurité les différents éléments qui composent les applications d’aujourd’hui.

Utilisés ensemble, Snyk Code pour SAST et Snyk Open Source pour SCA proposent des tests rapides, précis, faciles à utiliser et accessibles en libre-service. Les développeurs et les équipes de sécurité peuvent ainsi repérer, hiérarchiser et corriger facilement les problèmes de sécurité dans leur propre code propriétaire, ainsi que les vulnérabilités connues de leurs dépendances open source, afin de réduire les risques et d’accélérer le développement sécurisé.

L’application est corrigée avant son entrée dans le pipeline CI/CD, ce qui évite les délais liés aux analyses et la charge du triage et de la création de rapports de problèmes. L’équipe de sécurité des applications peut ainsi se concentrer sur la posture de sécurité globale de l’organisation.

Les tests unifiés de Snyk interviennent tôt et à chaque étape du cycle de développement, par exemple directement dans l’IDE :

Un outil, deux méthodes d’analyse : le plugin IDE JetBrains de Snyk en action.

Les analyses sont rapides et les résultats s’affichent dans l’environnement de développement, accompagnés d’explications claires et compréhensibles. Le flux de données qui traverse l’application est superposé au code d’origine, avec la possibilité de naviguer entre différents fichiers. Des exemples issus de projets open source montrent comment d’autres équipes ont résolu des problèmes similaires dans un contexte comparable. Mieux encore, comme les analyses sont rapides et illimitées, les développeurs peuvent analyser fréquemment de petites modifications et corriger les problèmes avant qu’elles n’intègrent le système de gestion de versions du code source.

Snyk lance automatiquement des analyses unifiées aux étapes ultérieures du développement. Par exemple, lors de l’importation d’un nouveau projet depuis GitHub, Snyk exécute automatiquement des tests SAST (1) et SCA (2) sur le code source du dépôt :

Un projet importé dans Snyk. Les résultats des analyses SAST et SCA dans une vue consolidée unique.

La plateforme Snyk repose sur la Snyk Intel Vulnerability Database, qui regroupe plusieurs sources publiques, les retours de la vaste communauté de développement de Snyk et les travaux de recherche de l’équipe dédiée de Snyk. Elle fournit ainsi les données sur les vulnérabilités les plus complètes, les plus récentes et les plus exploitables du marché. Les résultats d’analyse et les recommandations de correction sont donc précis.

L’interface Snyk permet aux équipes de développement et de sécurité de surveiller régulièrement leur base de code afin de repérer les vulnérabilités récemment découvertes. Lors de la récente vulnérabilité Log4shell, par exemple, Snyk Open Source a permis aux utilisateurs de Snyk d’analyser facilement et rapidement l’ensemble du code de leurs applications, d’identifier les dépôts vulnérables et d’agir en conséquence. Grâce aux contrôles de pull request ou à l’intégration de Snyk dans un pipeline CI/CD, ces tests peuvent être automatisés et rendus obligatoires.

La licence Snyk n’est pas facturée par analyse, par ligne de code ou par projet. Les équipes de sécurité des applications n’ont pas à limiter leurs analyses aux projets essentiels ni à une fréquence donnée pour des raisons de coût. Elles peuvent analyser autant de code qu’elles le souhaitent, aussi souvent que nécessaire.

Enfin, la plateforme Snyk analyse également les vulnérabilités des conteneurs et de l’infrastructure as code (comme vous l’avez peut-être remarqué dans une capture d’écran précédente), offrant une vue globale des différents éléments qui composent une application.

Le grand gagnant… les deux

En combinant SAST et SCA, vous obtenez une approche plus efficace qui donne aux organisations une vue complète de tous les logiciels utilisés.

La sécurisation des applications modernes doit être aussi agile que les processus qui guident leur développement. Utiliser les deux outils est désormais une norme de fait en matière de sécurité des applications et devient de plus en plus nécessaire pour se conformer à différents types de réglementations, comme la norme PCI DSS, ainsi qu’aux nombreuses initiatives gouvernementales dans le monde qui visent à renforcer la sécurité des applications et à lutter contre la progression des attaques contre la chaîne d’approvisionnement logicielle.

Les organisations qui souhaitent livrer des applications sécurisées ne devraient pas avoir à choisir une méthodologie plutôt qu’une autre en raison d’expériences passées, d’une préférence pour l’une d’entre elles ou même de budgets limités. SAST et SCA offrent une visibilité complète et indispensable sur l’ensemble du code source qui compose une application. Elles devraient donc être des éléments essentiels de tout programme de sécurité des applications.

Vous ne savez pas par où commencer avec SAST et SCA ? Essayez Snyk gratuitement !