Analyse du code - Sécurisation du cycle de développement applicatif

S’assurer de la qualité et de la sécurité du code tout au long du cycle de développement applicatif peut représenter une tâche fastidieuse, complexe et chronophage. Au cours de cet article, nous allons vous proposer des solutions pour réussir ce défi. Nous vous présenterons une solution technique pour répondre à ce challenge, son fonctionnement et ses intérêts.

Nous avons fait en sorte que cet article soit accessible aux métiers de gouvernance et de direction. La totalité des termes techniques sont référencés dans le glossaire en début d’article, n’hésitez pas à le consulter !

Au-delà de cet article, si ce sujet et la sécurité en général vous intéressent, on en parle dans notre formation DevSecOps.

Technologies de sécurisation du code applicatif

Analyse du code

Contexte

Le code est l’ADN d’une application. Il y a plusieurs façons, techniques, paradigmes pour arriver au résultat escompté. Le développement est coûteux en temps, en ressources humaines et budgétaires. Grossièrement, plus le développement est rapide, moins l’entreprise aura à dépenser dans l’immédiat. Comme il est quasiment impossible de produire quelque chose de qualitatif, rapidement et pour peu, c'est en général la qualité et la sécurité du code qui en pâtissent.

Les Static Application Security Testing (SAST)*, en français, tests statiques de sécurité des applications, sont des outils qui analysent le code source d’une application pour y déceler de potentielles failles et faiblesses de sécurité. À l’origine, ils servaient principalement à veiller à la qualité du code, mais depuis, leur utilité s'est étendue à l’aspect  sécurité.

Le SAST a pour objectif d’identifier les vulnérabilités liées au code source applicatif.

Il existe de nombreuses solutions de SAST sur le marché :

• SonarQube est une solution de SAST open-source
• GitLab intègre directement une solution de SAST
• Checkmarx offre une solution en SaaS*
• Klocwork de Perforce pour le C, C++, C#, Java et Javascript
• Veracode avec sa solution SaaS qui peut aussi s’intégrer dans une IDE
• Et d’autres encore …

Fonctionnement

Un analyseur de code travaille directement sur le code source applicatif, on dit qu’il fonctionne en white box car il a accès au code source. Pour identifier des vulnérabilités, un SAST exploite différents mécanismes :

• Analyse du flux de données : traque le parcours d’une donnée pour vérifier si l’entrée est validée avant d’être utilisée.
• Analyse des flux de contrôle : étudie la chronologie des opérations dans l’application pour détecter des séquences potentiellement dangereuses comme les conditions de courses (time-of-check-to-time-of-use), l’échec de transmission sécurisée de cookies, variables non initialisées, etc.
• Analyse structurelle : examine le code et les spécificités de son langage pour y trouver des écarts avec les bonnes pratiques. Par exemple, pour identifier les fragments de codes inutilisés ou qui ne fonctionnent pas, les matériaux cryptographiques générés à partir de sources de hasard non sécurisées ou encore des mots de passe en dur.
• Analyse sémantique : d’une manière limitée, un SAST est capable d’interpréter un code dans son contexte en détectant par exemple un risque d’injection SQL quand il rencontre une requête.
• Analyse de configuration : vérifie que les fichiers de configuration respectent les ensembles de bonnes pratiques (e.g : qu’une page d’erreur existe pour les applications web).

Au travers des différentes analyses que le SAST réalise sur un code, il peut détecter une pléthore de vulnérabilités :

• XSS* Stockées
• XSS Réfléchies
• Injections SQL
• Injections SQL Blind
• Injections de commandes
• Injections de code
• Code mort
• Non-validation/Non-assainissement d’entrée utilisateur
• Stack Buffer Overflow :
• Buffer Integer
• Mots de passe en dur
• etc.

Une fois l’analyse effectuée, le SAST, en fonction de ce qu’il aura détecté, met en évidence les vulnérabilités et faiblesses du code applicatif, leurs emplacements, leurs impacts et si c’est un bon SAST, les moyens de remédiation correspondants.

Le fonctionnement du SAST dans une CI peut se dérouler selon les étapes suivantes :

1. Contact avec le service de SAST
2. Chargement des règles d’évaluation du code
3. Analyse du code source
4. Génération du rapport
5. Notification en cas d’échec

Il est important de préciser que certaines solutions SAST peuvent s’intégrer directement dans l’IDE* du développeur/de la développeuse permettant ainsi de détecter les vulnérabilités le plus tôt possible dans le cycle de développement applicatif. Toutefois, une vérification une fois le code poussé reste nécessaire.

Intérêt

Le SAST est un outil essentiel pour aider les développeurs à sécuriser leur code. C’est une très bonne solution à mettre en place pour sécuriser son cycle de développement applicatif. En revanche, il faut garder en tête que la “magie” de cette technologie provient de la solution utilisée et de la configuration qui lui est apposée. Une expertise technique et des processus clairs doivent être mis en place pour profiter pleinement du potentiel de cet outil.

Malgré ses qualités, le SAST apporte son lot d’inconvénients :

• Dépendance forte de sa configuration : la capacité d’un SAST à détecter des vulnérabilités dépend fortement de sa propre configuration et de celle de l’utilisateur, ce qui peut élever son taux de faux-positifs ou le rendre aveugle.
• Liaison à X langages de programmation : il existe beaucoup de solutions SAST, certes, mais la majorité est associée à un langage de programmation en particulier.
• Génération élevée de faux-positifs : principal défaut de cette technologie, le SAST est connu pour relever des vulnérabilités inexistantes, ce qui peut rapidement être chronophage et non productif.
• Non-détection de toutes les vulnérabilités : une analyse du code statique a ses limitations intrinsèques qui la rendent par nature non exhaustive.
• Corrections proposées floues : les pistes de réflexion pour corriger les vulnérabilités mises en avant ne sont pas forcément les plus évidentes. Une expertise technique est de mise.

De par l’utilisation d’un analyseur de code, vous avez à disposition une liste des vulnérabilités et faiblesses de votre code applicatif. Comme nous l’avions précisé dans notre article sur l’analyse des dépendances, mettre des outils en place ne suffit pas. La sécurité gravite toujours autour de 3 composants essentiels :

• l’outil,
• l’humain/la compétence,
• et le processus.

Mettre en place un SAST ne représente qu’un tiers de ce qui est nécessaire pour avoir une dynamique de sécurité performante autour de l’analyse de code. Sans des personnes formées et sensibles à la sécurité, la mise en place de ce type d’outil n'apporte rien. Il faut des personnes capables de comprendre le risque pour l'évaluer et le traiter efficacement. De même, sans la mise en place des processus adéquats, le SAST risque de devenir un élément optionnel, ce qui va grandement mitiger son intérêt.

SAST & IaC

Dans cet article, nous faisons un focus particulier sur le code applicatif mais on peut aller plus loin. Aujourd’hui avec l'essor de l’Infrastructure as Code (IaC)*, les architectures deviennent du code et de facto sont auditables par des analyseurs de code statique. Le code représente l’infrastructure, il est source de vérité. On peut donc lui appliquer des contrôles de conformité et de sécurité adaptés au contexte de l’entreprise. Cela n’empêche pas de continuer à réaliser des pentests* et de former les personnes à la sécurité.

Il existe de nombreuses solutions de SAST pour l’audit d’IaC :

• SonarQube est capable aujourd'hui d'analyser de l'IaC
• Checkov qui peut analyser du Kubernetes, Terraform et Cloudformation
• Tfsec un outil de scan de templates Terraform
• Terrafirma un autre outil de scan de templates Terraform
• CloudSploit de Aqua pour scanner des templates CloudFormation
• etc.

Conclusion

J’espère que cet article vous aura plu et qu’il vous aura permis d’apprendre et de comprendre l’approche DevSecOps autour de la sécurisation du développement applicatif, ses termes et ses concepts. La sécurité est au cœur des cybers-enjeux de demain. Il est important de l’adresser dès maintenant au travers de vos processus, outils et compétences. Les outils d’analyse de code permettent de répondre en partie au besoin de sécurisation de l’application. Nous verrons dans de futurs articles qu’il existe d’autres technologies qui pourront nous aider à relever le défi de la sécurité.

Glossaire

CI/CD (Continuous Integration / Continuous Deployment) : combinaison des pratiques d'intégration continue et de livraison continue ou de déploiement continu.

IaC (Infrastructure as Code) : consiste à gérer et approvisionner une infrastructure à l'aide de lignes de code plutôt que par des processus manuels.

IDE (Integrated Development Environment) :  ensemble d'outils qui permet d'augmenter la productivité des programmeurs qui développent des logiciels.

Pentest :  est une méthode d'évaluation de la sécurité d'un système d'information ou d'un réseau informatique. (fr : test d’intrusion)

SaaS (Software as a Service ou logiciel en tant que service) : modèle d'exploitation commerciale des logiciels dans lequel ceux-ci sont installés sur des serveurs distants plutôt que sur la machine de l'utilisateur.

SAST (Static Application Security Testing) : outil d’analyse statique de code. Statique, car l’objet analysé est du code qui est considéré comme inerte.

XSS (Cross Site Scripting) : type de faille de sécurité des sites web permettant d'injecter du contenu dans une page, provoquant ainsi des actions illégitimes sur les navigateurs web visitant la page.

Et la saga continue...

A lire et à relire, les articles de la saga "Sécurisation du cycle de développement applicatif".

-Episode 1 : "Analyse des dépendances"

-Episode 2 : "Analyse du code"