Audit de code source orienté sécurité

Pourquoi un audit de code source

Un test d'intrusion observe le comportement de l'application : il trouve ce qui est exploitable depuis l'extérieur, dans le temps imparti. Un audit de code source analyse le fonctionnement interne de l'application : la logique d'autorisation contournable, le secret commité il y a deux ans, la désérialisation dangereuse dans un endpoint que personne n'appelle encore, la vérification de signature implémentée à moitié.

L'un ne remplace pas l'autre. Mais quand votre enjeu est le code lui-même, parce que vous devez en documenter la sécurité, c'est l'audit de code qui répond à la question.

Quatre situations déclenchent généralement la démarche :

• Un client ou un régulateur vous demande des garanties. Questionnaire sécurité avant signature, exigence contractuelle d'audit, conformité NIS2, DORA ou HDS. Vous avez besoin d'un rapport opposable, produit par un tiers identifiable et certifié.
• Une faille vient d'être détectée. La situation est stabilisée. La vraie question arrive : combien de ses sœurs dorment ailleurs dans la base de code ? Une faille isolée est rare ; le pattern qui l'a produite est généralement répété.
• Votre SAST vous noie d'alertes. Quand votre SAST génère des centaines d'alertes non pertinentes, c'est un problème de réglage : un accompagnement dans la qualification des alertes et la gestion des règles permet de retrouver un signal exploitable.
• Vous voulez simplement savoir où vous en êtes. Pas d'incident, pas d'obligation : une volonté d'établir un état des lieux avant que l'un des deux n'arrive. C'est le contexte le plus confortable pour auditer, et celui où le transfert de compétences rapporte le plus.

Comment se déroule l'audit

Un premier échange gratuit pour le devis, puis cadrage technique, accès au code, analyse, restitution. Vous gardez la main sur le périmètre et le mode d'accès au code source.

1. Premier échange (gratuit, sans engagement)

   Votre contexte, vos technologies, la taille de la base de code, vos objectifs. Il en sort une proposition forfaitaire ferme sous 48 h ouvrées. C'est là que se décide le périmètre, donc le coût.

2. Cadrage technique

   Au démarrage de la prestation : composants sensibles, contraintes d'accès, accord de confidentialité signé avant tout accès au code. Le cadrage fait partie de la prestation, pas de l'avant-vente.

3. Accès au code

   Selon vos contraintes : accès en lecture à votre dépôt Git, extraction d'archive, ou revue sur votre poste de travail dans vos locaux si le code ne doit pas sortir.

4. Analyse

   Revue manuelle, complétée d'outillage statique quand c'est pertinent. Si je découvre une vulnérabilité critique exploitable en production, vous êtes prévenu immédiatement, sans attendre le rapport.

5. Restitution

   Remise du rapport, puis une session de restitution avec l'équipe technique : revue des findings, discussion des corrections, priorisation. Cette session fait partie de la prestation, pas d'une option.

Ce que cet audit ne fait pas

• Un audit par revue constate des failles, il ne démontre pas leur absence : ne rien trouver sur le périmètre audité est rassurant, mais ne garantit pas que le code est exempt de vulnérabilités.
• Il ne couvre que le périmètre convenu. Un audit de 10 jours sur une base de code de 500 000 lignes est un audit ciblé, pas exhaustif, et le rapport le dira explicitement.
• Il ne remplace pas un test d'intrusion : les vulnérabilités d'infrastructure, de configuration ou de déploiement sont hors de son champ.
• Il ne vaut pas qualification PASSI. Si votre besoin est un audit sous qualification ANSSI (secteur public, OIV, SecNumCloud), il vous faut un prestataire qualifié PASSI, je vous le dirai dès le premier échange.

Questions fréquentes

Audit de code ou test d'intrusion : par quoi commencer ?

Si votre application est exposée publiquement et n'a jamais été testée, commencez par le test d'intrusion : il trouve les failles exploitables aujourd'hui. Si votre enjeu est contractuel ou réglementaire, ou si votre application n'est pas encore en production, l'audit de code est le bon point d'entrée.

Mon code peut-il rester dans nos locaux ?

Oui. La revue peut se faire intégralement sur site, sur un poste que vous me fournissez, sans qu'aucune ligne ne sorte de votre infrastructure. C'est une demande fréquente des éditeurs, et elle ne change pas la méthodologie.

Et un pentest « whitebox », avec accès au code ?

Le terme désigne un test d'intrusion mené avec le code en appui, mais dont le but reste de démontrer un impact exploitable. Si votre besoin est de couvrir le code en profondeur et de documenter chaque finding, c'est un audit de code, dans sa logique.

Utilisez-vous des outils d'IA pour analyser le code ?

Non, sauf accord explicite de votre part. Par défaut, aucun extrait de votre code n'est transmis à un service tiers, IA ou autre. La revue est manuelle, outillée localement (Semgrep, grep, analyse de flux).

Que vaut un consultant seul face à un cabinet ?

Vous savez exactement qui lit votre code : un profil identifiable, certifié OSCP, avec quinze ans de développement et une contribution de sécurité mergée dans dotnet/runtime. La contrepartie honnête : je ne parallélise pas, donc les très gros périmètres en délai court ne sont pas mon terrain.

Quel est le délai pour démarrer ?

Réponse à votre demande sous 48 h ouvrées. Démarrage généralement sous 2 à 4 semaines, selon mon planning.