L’analyse statique (SAST) est une technique utilisée dans le développement web pour identifier les failles de sécurité. Dans les pipelines DevSecOps, les outils SAST interviennent à 3 niveaux principaux.
Dans le domaine du développement logiciel, les équipes sont soumises à différents défis, parmi lesquels, la nécessité de livrer rapidement les travaux et la multiplication des cyberattaques. Dans son 11ème rapport State of Software Security sorti en 2020, Veracode annonçait que 76% des applications souffraient de défauts de sécurité dès leur première analyse. Ce chiffre montre l’urgence d’intégrer la sécurité à partir des phases initiales du développement. C’est justement en pensant de cette façon que le mouvement DevSecOps est né. Dans cette approche, on retrouve l’analyse statique, une technique qui permet l’identification des failles de sécurité. Comment cette technique s’intègre-t-elle aux pipelines DevSecOps ?
Ce qu’il faut savoir sur l’analyse statique dans le contexte DevSecOps
La Static Application Security Testing (SAST) est une technique consistant à examiner le code source, le bytecode ou les binaires d’une application sans l’exécuter. Le but de cette manœuvre est de rechercher des patterns qui sont des signes de vulnérabilités connues ou des pratiques de codage dangereuses.
Cette approche est classée dans la catégorie « white-box », puisqu’elle permet d’accéder directement à l’intégralité du code interne. Elle s’oppose donc aux tests dynamiques « black-box », qui observent seulement la façon dont l’application se comporte en externe lors de l’exécution. Pour l’appliquer, il est possible d’avoir recours à des SAST tools qui utilisent des techniques d’analyses diverses comme :
- Le parsing syntaxique pour la construction de l’arbre de syntaxe abstraite du code,
- L’analyse de flux de données pour tracer la circulation des données entre variables et fonction,
- L’analyse de flux de contrôle, qui permet la cartographie des différents chemins d’exécution.
Aujourd’hui, vous pouvez trouver des outils SAST basés sur l’IA. Ces derniers sont capables d’analyser rapidement de larges portions de code, réduisant ainsi le travail manuel et les coûts des corrections tardives des défauts.
L’intégration de l’analyse statique dans les pipelines CI/CD
L’analyse statique dans les pipelines DevSecOps se fait généralement dans les processus d’intégration continue (CI) et de livraison continue (CD). L’efficacité de cette analyse repose sur son automatisation et son intégration complète dans les pipelines. Normalement, les scans de sécurité doivent être invisibles et ne pas nécessiter l’intervention humaine, sauf si un problème est détecté. Trois niveaux de la chaîne sont concernés par cette implémentation.
Le premier niveau s’intègre directement dans l’environnement de développement intégré (IDE) du développeur grâce à certaines extensions. Ces dernières analysent le code en temps réel pendant son écriture et soulignent immédiatement les lignes avec des erreurs. Le développeur peut donc corriger les vulnérabilités au fur et à mesure qu’il tape son code. Il est même possible d’avoir des suggestions de correction avec certains outils.
Le deuxième niveau entre en jeu lors des commits dans le système de gestion de versions. Les outils analysent rapidement le code modifié et peuvent bloquer le commit en cas de détection de vulnérabilités critiques. Grâce à cette façon de procéder, vous pouvez être rassuré qu’aucun code dangereux n’entre dans le repository.
Le troisième niveau, qui est d’ailleurs considéré comme le principal, s’exécute directement dans le pipeline CI/CD. Cela se fait généralement pendant les pull request vers les branches principales. C’est une analyse complète qui touche tout le code et ses dépendances. À la fin, vous avez droit à un rapport détaillé des vulnérabilités, de leur sévérité, de leur localisation et des suggestions pour les corriger.
Les défis liés à l’adoption de l’analyse statique
Si l’usage de l’analyse statique dans les pipelines DevSecOps offre divers avantages comme la détection facile des vulnérabilités et la diminution des coûts de correction de failles, il y a également certains défis auxquels les développeurs peuvent faire face. L’un de ces défis est la gestion du grand volume de résultats générés. Parmi tous ces résultats, il arrive qu’une grande proportion constitue des faux positifs ou des vulnérabilités mineures.
Pour gérer un tel problème, il existe plusieurs techniques, dont la priorisation intelligente. Elle consiste à classifier automatiquement les vulnérabilités en fonction du niveau de sévérité et du contexte d’exploitation. Une autre technique est le tuning progressif des règles d’analyse. Il consiste à analyser les alertes récurrentes et ajuster la configuration de l’outil.
Il est aussi possible d’enrichir les résultats avec du contexte applicatif pour améliorer leur pertinence. Les solutions modernes complètent les résultats SAST avec d’autres sources de données comme :
- l’analyse de composition pour identifier les vulnérabilités dans les bibliothèques tierces,
- les tests dynamiques (DAST) pour confirmer l’exploitabilité des failles détectées statiquement,
- les inventaires des assets exposés sur internet pour prioriser les vulnérabilités.
Les bonnes pratiques pour l’intégration continue de la sécurité
Afin d’optimiser l’impact de l’analyse statique dans un pipeline DevSecOps, il est important d’adopter un certain nombre de bonnes pratiques organisationnelles et techniques. D’abord, il faut former les développeurs à l’interprétation des résultats produits par les outils et à l’ajustement des règles de sécurité en fonction des priorités de l’entreprise. Les développeurs doivent également savoir combiner la SAST avec les autres stratégies de test pour couvrir toutes les vulnérabilités.
Il faut par ailleurs que l’intégration de la SAST soit pensée comme un élément de culture DevSecOps dans laquelle la sécurité est l’affaire de tout le monde. Des boucles de rétroaction efficaces doivent exister entre les équipes Dev, Sec et Ops ainsi que des métriques pour suivre l’évolution de la sécurité.
