Audit de code source

"Un audit de code source consiste à examiner le code d’une application afin de détecter les failles de sécurité, les erreurs de conception et les mauvaises pratiques de développement, dans le but de prévenir les vulnérabilités avant qu’elles ne soient exploitées et d’améliorer durablement la qualité du logiciel."

Contexte

En 2025, la France est championne d'Europe de fuite de données, avec 90% de la population qui a vu ses informations personnelles vendues sur le dark web.

Le risque zéro n'existe pas, ainsi la CNIL ne sanctionne pas systématiquement les fuites. En revanche, l'absence de mesures préventives est pénalement répréhensible avec des amendes allant jusqu'à 4% du chiffre d'affaires.

Un test d'intrusion web est une première étape clé dans la sécurisation de vos applications.

Afin de consolider votre site web après les résultats satisfaisants d'un pentest web, il est recommandé d'effectuer un audit de code source.

A qui s'adresse cette offre ?

Vous êtes une PME basée sur un portail Web ayant fait l'objet de tests d'intrusion web ? Bienvenue à bord.

Le marché de la cybersécurité est vaste, il est essentiel de bien choisir son prestataire. Les grands cabinets disposent d'une force commerciale et d'une présence sur les réseaux, mais leurs tarifs sont parfois élevés, ils offrent peu de flexibilité et la qualité n'est pas toujours au rendez-vous.

Avec QS, vous faites le choix d'un prestataire réactif assurant un niveau de qualité à l'état de l'art, et ce pour un tarif 20% inférieur au marché.

Étapes

En nous faisant confiance pour effectuer cette prestation, voici ce à quoi vous pouvez vous attendre.

Réunion de cadrage

Également appelé "kickoff", ce point réunit tous les acteurs nécessaires au bon déroulement de la prestation, incluant :

  • L'expert en charge des tests ;

  • Votre RSSI ;

  • Un développeur expérimenté en charge de l'application.

Ce point doit idéalement être planifié en amont de la prestation afin de déterminer les prérequis à fournir, confirmer les dates des tests et leurs modalités.

C'est également l'occasion d'échanger avec un développeur maitrisant l'application afin d'identifier les segments critiques. Ces parties du code devront faire l'objet d'une attention accrue lors de l'audit.

Déroulement des tests - méthodologie

L'audit de code source sera effectué via plusieurs approches :

  • Approche automatisée : utilisation d'un outil d'audit comme SonarQube afin d'identifier les vulnérabilités liées à de mauvaises pratiques de développement ou à des fonctions réputées vulnérables ;

  • Approche manuelle : analyse de la logique applicative en commençant par les sections critiques identifiées précédemment. L'objectif est de détecter les vulnérabilités liées à la logique applicative qu'un outil automatisé manquerait.

Ces phases se basent sur l'expertise du consultant, notre capitalisation interne ainsi que sur des référentiels éprouvés :

  • La méthodologie OWASP ASVS dont la pertinence est mondialement reconnue ;

  • Les résultats de l'audit sont mis en perspective avec les exigences ISO27001 ;

  • Les recommandations tiennent compte des guides et bonnes pratiques de l’ANSSI.

Remise du rapport d'audit

Un rapport d'audit au format PDF vous sera remis à l'issue des tests. Il se compose notamment des éléments suivants :

  • Une synthèse managériale présentant les risques stratégiques et métiers identifiés, pondérés en fonction de vos enjeux spécifiques ;

  • Un tableau récapitulatif des vulnérabilités identifiées et des recommandations associées, ordonnées par score CVSS ;

  • Une synthèse technique détaillant les différentes analyses effectuées ;

  • Le détail des vulnérabilités identifiées, preuves à l'appui, avec pour chacune d'elles :

    • Une description de la vulnérabilité ;

    • Le constat ;

    • L'impact métier et technique ;

    • Les mesures de remédiation à implémenter.

Réunion de restitution

Après livraison du rapport, une réunion de restitution de 30 à 60 minutes est organisée avec les parties prenantes ayant pris connaissance du rapport.

L'objectif n'est pas de détailler le rapport dans une présentation, mais de présenter les principaux risques, les vulnérabilités les plus critiques, leurs recommandations et conclure sur le niveau de sécurité observé durant la prestation.

C'est également l'occasion de traiter des points spécifiques du rapport qui nécessitent des informations supplémentaires en harmonie avec le contexte client.