Cloud, QA et sécurité

Revue de code sécurisé : repérer les failles dans la source

Gjethe examine votre code source à la recherche de failles de sécurité que les tests depuis l'extérieur peuvent manquer : authentification et autorisation faibles, traitement des entrées non sûr, secrets exposés, dépendances risquées et schémas dangereux. Nous combinons des outils avec une lecture manuelle par des développeurs et vous remettons des corrections applicables.

Réserver une consultation gratuiteDemander un devis
  • Première consultation gratuite
  • Devis écrit pour votre projet
  • Paiements échelonnés par étapes, avec souplesse
✓ build passed

En un coup d'œil

Reviews
Bases de code web, mobiles et d'API
Méthode
Outils plus relecture manuelle par des développeurs
Axe de travail
Authentification, entrées, secrets, dépendances
Livrable
Constats en contexte, avec corrections

Definition

Qu'est-ce que la revue de code sécurisée?

Une revue de code sécurisé est un examen du code source d'une application pour trouver des faiblesses de sécurité, en lisant le code et sa logique plutôt qu'en testant uniquement le système en fonctionnement depuis l'extérieur.

Certaines faiblesses sont difficiles à voir de l'extérieur mais évidentes dans le code : une vérification de permission mise en commentaire, un secret versionné dans le dépôt, une saisie transmise telle quelle à une requête, une bibliothèque présentant une faille connue. Une revue de code sécurisé lit la source comme le ferait un collègue attentif, en associant analyse automatisée et relecture manuelle par des développeurs qui connaissent les frameworks que vous utilisez. Elle se marie bien avec un test d'intrusion : le test montre ce qui est atteignable, la revue montre pourquoi, et ensemble ils couvrent bien plus que chacun seul.

À qui s'adresse-t-elle ?

  • Équipes de développement avant la mise en production

    Une revue avant la livraison détecte les failles tant qu'elles sont peu coûteuses à corriger.

  • Produits traitant des données sensibles

    Lorsque les enjeux sont élevés, lire le code apporte une assurance qu'un test en boîte noire ne peut pas donner.

  • Équipes ayant hérité d'une base de code

    Une revue cartographie l'état de sécurité d'un code que vous n'avez pas écrit avant de bâtir dessus.

  • Entreprises répondant à une due diligence

    Les investisseurs et les acquéreurs posent de plus en plus de questions sur la qualité et la sécurité du code.

Ce qui est inclus, et ce que vous conservez

Ce qui est inclus

  • Périmètre convenu et accès au dépôt
  • Analyse statique automatisée de la base de code
  • Revue des risques liés aux dépendances et aux licences
  • Analyse de l'historique à la recherche de secrets et d'identifiants
  • Revue manuelle de l'authentification et des sessions
  • Revue manuelle de l'autorisation et des contrôles d'accès
  • Revue du traitement des entrées et des sorties
  • Revue de la gestion et du stockage des données
  • Revue des schémas risqués et des mauvais usages de frameworks
  • Constats présentés en contexte, avec références au code
  • Conseils de correction pour chaque constat
  • Un appel de revue avec vos développeurs

Ce que vous recevez

Remis en fin de mission. À vous pour toujours.

  • Rapport de revue de code sécurisé
  • Constats avec références de fichier et de ligne
  • Niveau de gravité et correction pour chaque constat
  • Constats sur les dépendances et les secrets
  • Appel de revue avec les développeurs

Ce que nous recherchons dans le code

  • Contrôles de permission manquants, contournés ou incohérents
  • Saisies utilisateur utilisées dans des requêtes, des commandes ou des gabarits
  • Secrets, clés ou mots de passe versionnés dans le dépôt
  • Gestion faible des mots de passe, des sessions ou des jetons
  • Données sensibles journalisées ou stockées sans protection
  • Dépendances tierces obsolètes ou risquées
  • Gestion non sûre des fichiers, des envois ou de la désérialisation
  • Gestion des erreurs qui divulgue des détails internes

Pourquoi la revue de code et les tests fonctionnent mieux ensemble

Un test d'intrusion vous dit ce qu'un attaquant peut atteindre de l'extérieur. Une revue de code vous dit pourquoi la faiblesse existe et si la même erreur se répète ailleurs. Un schéma défaillant copié dans de nombreuses fonctionnalités peut apparaître comme un seul constat lors d'un test, mais comme une cause racine lors d'une revue.

Lire le code permet aussi d'atteindre des endroits que les tests peinent à toucher : chemins rarement utilisés, fonctions réservées aux administrateurs, tâches d'arrière-plan et branches d'erreur. Nous combinons l'analyse statique, rapide et large, avec une lecture manuelle par des développeurs, qui comprend l'intention et le contexte, afin que les constats soient exacts et que les corrections s'accordent à la façon dont votre application est réellement construite.

Des constats exploitables, pas un mur d'avertissements

Lancez un outil d'analyse statique sur une base de code et il renverra souvent des centaines d'avertissements. Beaucoup ne s'appliquent pas, certains sont des doublons, et quelques-uns sont réellement graves, mais enfouis. Remis bruts, ces résultats risquent davantage d'être ignorés que corrigés, et les vrais problèmes restent en place. La valeur d'une revue réside dans le tri : décider ce qui est réellement exploitable dans votre application, et pourquoi.

Notre rapport se lit donc comme les notes d'un ingénieur senior, pas comme un export d'outil. Chaque constat pointe vers le fichier et la ligne exacts, explique le risque en contexte, évalue sa gravité et montre la modification qui le résout. Lorsque la même erreur apparaît à plusieurs endroits, nous le disons, car corriger le schéma une fois vaut mieux que rafistoler dix symptômes. Le résultat est une liste que vos développeurs peuvent traiter par ordre de priorité et réellement terminer.

Comme nous sommes une équipe de développement, nous pouvons aller plus loin que le rapport. Nous pouvons ouvrir nous-mêmes les pull requests, ou relire les corrections de votre équipe, afin que les faiblesses soient fermées et pas seulement répertoriées.

Comment fonctionne la revue de code sécurisée, étape par étape

Chaque étape produit un résultat clair que vous pouvez relire. Le calendrier est convenu dans votre devis.

  1. 1

    Périmètre

    Dépôts, langages, frameworks et priorités convenus par écrit.

  2. 2

    Mise en place

    Accès en lecture au code et courte présentation de l'architecture.

  3. 3

    Analyse

    Analyse statique, des dépendances et des secrets sur l'ensemble de la base de code.

  4. 4

    Révision

    Lecture manuelle du code critique pour la sécurité par des développeurs.

  5. 5

    Rapport

    Constats en contexte, avec références, gravité et corrections.

  6. 6

    Restitution

    Un appel pour présenter les constats à vos développeurs.

Les outils, et ce qui détermine votre devis

Le prix dépend de votre projet et est convenu dans votre devis. Voici ce qui le fait varier.

Revue de code sécurisée : facteurs de prix
FacteurPourquoi c'est important
Taille de la base de codePlus de code et plus de langages impliquent plus à analyser et à lire.
Langages et frameworksCertaines stacks demandent des connaissances et des outils de revue spécialisés.
Profondeur de la revueUne revue ciblée de modules critiques diffère d'une lecture complète de la base de code.
Qualité et historique du codeUne base de code enchevêtrée ou un long historique demande plus de temps pour être revu en toute sécurité.
Aide à la correctionMettre en œuvre les corrections, plutôt que de seulement les signaler, ajoute de l'effort.

Erreurs courantes à éviter

Ce qui tourne le plus souvent mal, et comment un bon projet l'évite.

  • Se fier uniquement à l'analyse statique

    Les outils signalent des schémas mais manquent l'intention et les failles de logique ; une lecture manuelle détecte ce qu'ils ne peuvent pas voir.

  • Ignorer l'historique des commits

    Les secrets supprimés du code le plus récent restent souvent dans l'historique du dépôt.

  • Ne revoir que le code récent

    Les failles graves se cachent souvent dans de vieux modules de confiance que personne n'a regardés depuis des années.

  • Laisser les dépendances sans contrôle

    La plupart des applications exécutent bien plus de code tiers que de code propre ; ses faiblesses sont aussi les vôtres.

Questions fréquentes

Comment accédez-vous à notre code en toute sécurité ?

Par un accès en lecture que vous accordez et révoquez, sous accord de confidentialité. Nous pouvons réaliser la revue dans votre environnement si vous le préférez, et nous ne conservons aucune copie après la mission.

Quels langages examinez-vous ?

Couramment JavaScript et TypeScript, Python, PHP et les frameworks qui s'appuient sur eux. Indiquez-nous votre stack et nous confirmerons l'adéquation avant de commencer.

Une revue de code vaut-elle mieux qu'un test d'intrusion ?

Ils répondent à des questions différentes et sont plus efficaces ensemble. Le test montre ce qui est atteignable ; la revue montre pourquoi et si le schéma se répète.

Vérifiez-vous nos dépendances ?

Oui. Nous examinons les bibliothèques tierces à la recherche de faiblesses connues et de risques de licence, car la plupart des applications en dépendent fortement.

Trouverez-vous les secrets codés en dur ?

Nous analysons le code et son historique à la recherche de clés, de mots de passe et de jetons versionnés, et conseillons sur la rotation de tout ce qui a été exposé.

Pouvez-vous corriger ce que vous trouvez ?

Oui. En tant qu'équipe de développement, nous pouvons mettre en œuvre les corrections ou travailler en binôme avec vos développeurs pour les appliquer.

Examinez-vous le code d'applications mobiles ?

Oui, pour les stacks mobiles courantes, y compris la façon dont l'application stocke les données et communique avec son backend.

Signez-vous un accord de confidentialité ?

Oui, avant tout accès à votre code. Les conditions sont convenues par écrit, et les conclusions ne sont communiquées qu'aux personnes que vous désignez.

Quelle part de notre base de code lisez-vous ?

Autant que le périmètre le permet. Pour une revue ciblée, nous nous concentrons sur les parties critiques pour la sécurité : tout ce qui touche à l'authentification, aux permissions, aux paiements et aux données personnelles. Pour une revue complète, nous lisons toute la base de code.

Services associés

Tous les services de cloud, QA et sécurité

Revue de code sécurisée par secteur

Trouvez les failles dans votre source.

Dites-nous ce dont vous avez besoin. Vous recevez une évaluation honnête, un plan clair et un devis écrit. La première consultation est toujours gratuite.

Réserver une consultation gratuiteDemander un devis
  1. Et ensuite ?
  2. 1Vous nous dites ce dont vous avez besoin
  3. 2Nous nous efforçons de répondre sous 24 heures avec des questions
  4. 3Vous recevez un devis écrit pour votre projet