La société Akamai, acteur international de la cybersécurité, établit dans son dernier rapport State of the Internet (SOTI) que le nombre d’attaques sur des application web et API a dépassé les 311 milliards en 2024. C’est une augmentation de 33% par rapport à 2023, et cela n’est pas près de diminuer en 2025 avec notamment une utilisation massive de l’intelligence artificielle dans les attaques (création, développement, automatisation, etc.).

Dans ce paysage, la question n’est plus de savoir si vos applications seront mises à l’épreuve par un attaquant, mais quand. Auditer le code de ses applications devient donc une priorité, c’est pourquoi dans cet article nous allons étudier deux manières de tester la sécurité d’une application.

SAST (Static Application Security Testing)
Inspecte le code source, octet ou binaire pour identifier des vulnérabilités sans exécuter l’application, offrant ainsi une approche de test dîte en « boîte blanche ». L’analyse se fait par la reconnaissance de schéma de code indiquant un type connu de vulnérabilité.

DAST (Dynamic Application Security Testing)
Consiste à tester une application en cours d’exécution sans nécessairement accéder au code (approche dîte en “boîte noire”). L’analyse se fait via l’injection de charges malveillantes (XSS, SQLi…) et observe les comportements pour identifier des failles réellement exploitables. Ainsi, son intégration offre des indicateurs uniques sur des comportements au runtime et les vulnérabilités spécifiques à l’environnement, que l’analyse statique pourrait négliger.

IAST (Interactive Application Security Testing)
Combine les tests SAST et DAST. En effet, les outils analysent le code et surveillent les applications en temps réel.

SAST

• Avantages : Apparition précoce dans le SDLC, détection de vulnérabilités connues (OWASP Top Ten ou CWE), coûts et temps nécessaire à la correction des vulnérabilités identifiées réduits.
• Limites : Nombreux faux positifs possibles si les outils ne sont pas configurés avec des règles personnalisées. L’outil doit prendre en charge les langages de programmation utilisés.

DAST

• Avantages : Détection de problèmes et vulnérabilités qui ne se produisent que lorsque l’application est en cours d’exécution, validation réelle d’erreurs de configuration et de vulnérabilités vraiment exploitables.
• Limites : La détection des vulnérabilités s’effectue à un stade avancé du processus de développement. Exhaustivité dépendante de la couverture de l’application par l’outil.

IAST

• Avantages : Couverture plus complète, détecte en temps réel et génère moins de faux positifs.
• Limites : Mise en œuvre complexe, peut impacter les performances de l’application pendant les tests en cas de surveillance en continue.

En intégrant la méthode SAST dès le début du cycle de développement, idéalement juste après la validation du code, les développeurs reçoivent un retour d’information immédiat sur les problèmes de sécurité potentiels, ce qui permet d’apporter des corrections rapides.

Le DAST doit être exécuté à chaque fois que vous allez apporter une modification à votre application en production, idéalement lorsqu’elle est déployée dans un environnement de test afin que vous puissiez détecter les problèmes avant leur mise en production.

Gouvernance interne

Les entreprises qui développent des applications se doivent de mettre en place une stratégie relative à la sécurité des développements applicatifs. Cette pratique est d’autant plus importante qu’elle fait l’objet de projets de réglementations.

• Dans un premier temps, il faut rédiger et diffuser une politique sur le cycle de développement des applications dans laquelle sont décrites toutes les exigences de sécurité à respecter et les mesures de sécurité à mettre en place (dont l’audit de la sécurité du code fait partie).
• Ensuite, il faut mettre en place et documenter des processus pour les tests de sécurité (dont les SAST et DAST font partie) à effectuer au cours du cycle de vie de développement des applications.
• Enfin, les procédures décrivant aux équipes opérationnelles les fonctionnalités des outils choisis, de leurs intégrations (dans l’IDE par exemple) à leurs utilisations. Chaque procédure doit également contenir les méthodes de lecture des réponses générées (via des tableaux de bord par exemple) pour les acteurs de la chaîne de développement.

Outillage

Voici à titre informatif quelques outils clés du marché :

• SAST : Synopsys Coverity, SonarQube
• DAST : OWAS ZAP, Qualys
• IAST : Synopsys Seeker, Veracode

Vous l’aurez compris, la réponse efficace pour tester la sécurité de ses applications n’oppose pas SAST et DAST : elle les combine (séparément ou au sein d’un outil IAST). L’utilisation de ces méthodes d’audit de code au bon moment du cycle de développement de l’application (SDLC) permet de réduire la dette de sécurité en amont et de valider en aval l’exploitabilité en conditions réelles.

🤔 Vous souhaitez en savoir plus sur la gestion de la sécurité des applications web ?

• Formez-vous avec Kedros à la sécurité dans les développements !
• Faites-vous accompagner par Kedros sur votre SDLC !

👉 Suivez-nous pour ne rien manquer des dernières actualités !

• Notre page LinkedIn
• Notre site web