Audit de sécurité applicative : quel niveau de preuve demander à un prestataire ?

Un audit de sécurité applicative ne désigne pas une prestation unique. Selon le projet, le prestataire peut proposer une revue de code, une analyse automatisée, une modélisation des menaces, un test d’intrusion ou une combinaison de ces approches. Le bon choix dépend moins du nombre d’outils utilisés que de la question à trancher.

Une PME qui prépare la mise en production d’un portail client ne cherche pas nécessairement la même preuve qu’une entreprise qui reprend une application ancienne, expose une API sensible ou traite des données personnelles. L’objectif est donc de relier le niveau d’évaluation au risque, au moment du projet et à la décision attendue.

La CNIL recommande d’intégrer la sécurité dès la conception, de séparer les environnements, d’utiliser des données fictives ou anonymisées et de réaliser des tests adaptés avant une mise à disposition ou une mise à jour. Un audit ponctuel ne remplace donc pas les contrôles intégrés au cycle de développement.

Première bifurcation : quelle décision devez-vous prendre ?

Avant de comparer les offres, formulez la décision attendue en une phrase. Si elle reste vague, le rapport final risque d’énumérer des vulnérabilités sans aider à arbitrer.

1. Le projet peut-il être conçu ou modifié sans risque architectural évident ? Orientez-vous vers une modélisation des menaces et une revue d’architecture.
2. Le code respecte-t-il les exigences de sécurité sur les zones sensibles ? Demandez une revue de code ciblée, complétée par des contrôles automatisés.
3. L’application exposée présente-t-elle une faiblesse exploitable depuis l’extérieur ? Un test d’intrusion peut apporter une preuve circonstanciée sur le périmètre testé.
4. Les contrôles récurrents sont-ils intégrés au développement ? Vérifiez le pipeline, la gestion des dépendances, les secrets, les exceptions et la conservation des preuves.

Cette séquence évite de demander un test d’intrusion à une application dont l’architecture ou les droits n’ont jamais été clarifiés. Elle évite aussi de considérer un rapport automatisé comme une validation générale du produit.

Si le projet est encore cadré : commencer par les menaces

La modélisation des menaces consiste à décomposer l’application, repérer les actifs, les points d’entrée et les frontières de confiance, puis à identifier les scénarios d’attaque et les mesures de réduction du risque. OWASP décrit cette démarche en quatre étapes : décomposition, identification et classement des menaces, choix des mesures, puis revue et validation.

Cette approche est particulièrement utile avant de choisir une architecture, d’ouvrir une API, d’ajouter un fournisseur SaaS ou de confier une action sensible à un traitement automatisé. Elle permet de faire apparaître des sujets souvent absents d’un devis technique : qui peut déclencher une action, quelles données franchissent une frontière, que se passe-t-il si un compte de service est compromis et comment interrompre un flux externe ?

Le livrable attendu n’est pas seulement un schéma. Il doit contenir le périmètre étudié, les actifs importants, les acteurs, les hypothèses, les scénarios retenus, leur niveau de priorité, les mesures proposées et les décisions restant à prendre. Pour une PME, un document court et relié aux choix du projet sera souvent plus utile qu’un référentiel très volumineux que personne ne met à jour.

Si une version existe déjà : cibler le code et les flux sensibles

Une revue de code de sécurité examine la logique applicative, les flux de données et les contrôles qui nécessitent une compréhension du contexte. Elle peut porter sur l’ensemble du produit ou sur une évolution précise. OWASP distingue notamment les revues de référence et les revues limitées aux changements.

La revue devient pertinente lorsque le risque se concentre dans des fonctions difficiles à déduire par un outil : autorisation métier, changement d’état, gestion des comptes, import de fichiers, paiement, traitement de données sensibles ou intégration avec un système tiers. Elle doit préciser les fichiers, modules, parcours et hypothèses examinés. Un rapport qui ne donne ni périmètre ni méthode ne permet pas de savoir ce qui a réellement été vérifié.

Les outils d’analyse statique, de détection de secrets, de contrôle des dépendances ou de test dynamique restent utiles pour couvrir largement le produit. Ils produisent toutefois des alertes à qualifier. Le devis doit donc indiquer qui trie les faux positifs, qui confirme la gravité, qui propose une correction et qui vérifie la résolution.

Si l’application est exposée : demander une preuve d’exploitation contrôlée

Le test d’intrusion répond à une question plus concrète : dans le périmètre et les conditions convenus, un intervenant peut-il exploiter une faiblesse pour atteindre un objectif défini ? Cette prestation nécessite des règles d’engagement précises : environnements autorisés, plages d’intervention, comptes fournis, données de test, limites sur les actions destructrices, contacts d’urgence et procédure d’arrêt.

Le résultat ne doit pas être présenté comme une garantie de sécurité générale. Il documente un périmètre, une période et des scénarios testés. Le rapport doit distinguer les constats reproduits, les hypothèses, les limites de couverture et les recommandations. Une contre-vérification après correction est également à prévoir, avec la liste des vulnérabilités effectivement retestées.

Un test externe peut être insuffisant si l’essentiel du risque se trouve dans une règle métier interne, une configuration d’identité ou un processus d’administration non accessible depuis Internet. Dans ce cas, le dispositif doit intégrer des comptes de test, des scénarios authentifiés ou une revue complémentaire.

Arbre de décision pour choisir la prestation

Dans de nombreux projets, la combinaison la plus proportionnée est progressive : modéliser les menaces sur les parcours critiques, automatiser les contrôles répétitifs, faire relire les zones métier sensibles, puis tester l’exposition du service avant son ouverture. Le prestataire doit expliquer pourquoi chaque brique est retenue et ce qu’elle ne couvre pas.

Les livrables qui rendent l’audit réellement exploitable

Le rapport final doit permettre à une personne absente des réunions de comprendre ce qui a été observé, ce qui reste incertain et qui doit décider. Demandez au minimum :

• un périmètre écrit : application, version, environnement, interfaces et comptes utilisés ;
• la méthode et les hypothèses, avec les exclusions explicites ;
• une classification des constats reliée à l’impact métier et à la facilité d’exploitation ;
• des preuves reproductibles sans exposer de données réelles inutiles ;
• une recommandation de correction, son propriétaire et son niveau de priorité ;
• un plan de retest ou de vérification après correction ;
• une restitution adaptée au décideur et une restitution exploitable par l’équipe technique.

La documentation ne doit pas contenir de secrets, de données personnelles non nécessaires ou de copies intégrales de fichiers sensibles. La CNIL rappelle également l’importance d’environnements séparés et de données fictives ou anonymisées pendant le développement et les tests.

Checklist avant de signer

• La question de décision est-elle formulée sans ambiguïté ?
• Le périmètre technique et métier est-il écrit dans le devis ?
• Les comptes de test, jeux de données et environnements sont-ils identifiés ?
• Les limites de la prestation sont-elles explicites ?
• Le rapport reliera-t-il chaque constat à un risque et à une action ?
• Un retest est-il prévu, avec une règle claire pour clore un constat ?
• Les exceptions et risques acceptés feront-ils l’objet d’une décision documentée ?

Pour situer cet audit dans une démarche plus large, comparez aussi les contrôles à placer dans un pipeline CI/CD sécurisé et les obligations de cadrage possibles lorsqu’un projet logiciel entre dans le périmètre du Cyber Resilience Act.

Le bon prestataire ne promet pas une sécurité absolue. Il explique quelle incertitude sa prestation réduit, avec quelles preuves, sur quel périmètre et à quel moment. C’est cette correspondance entre risque, contrôle et livrable qui permet de prendre une décision défendable.