Méthodologie
Tests d'intrusion manuels,
vérifiés dans le code
On ne vous livre pas un export de scanner. Chaque vulnérabilité est identifiée manuellement, confirmée dans votre code source, et documentée avec sa preuve d'exploitation et son correctif. Méthodologie OWASP WSTG et PTES, en 5 étapes.
100%
Des findings vérifiés manuellement
0
Faux positifs dans nos rapports
48h
Délai de livraison Rapide
OWASP WSTG
Référentiel méthodologique
$ salvor audit --start
─────────────────────────────────────────
[01] Cadrage .................. 1 jour
[02] Reconnaissance ........... 1–2 jours
[03] Tests d'intrusion ........ 2–10 jours
[04] Rapport .................. inclus
[05] Restitution .............. inclus
─────────────────────────────────────────
✓ Audit terminé. 0 vulnérabilités non documentées.
Processus
De l'appel de cadrage au correctif mergé
Cadrage
Appel de cadrage pour définir le périmètre exact, le modèle de menaces et les objectifs de l'audit. On identifie les fonctionnalités critiques, les rôles utilisateur et les contraintes techniques. Vous recevez une proposition signée sous 24h.
1 jour
Reconnaissance
Cartographie passive et active de la surface d'attaque : stack technique, endpoints, flux d'authentification, points d'entrée exploitables. Tout est documenté avant les tests.
1–2 jours
Tests d'intrusion
Tests manuels selon la méthodologie OWASP WSTG : injection, broken access control, logique métier, gestion des sessions, cryptographie. Chaque vulnérabilité est vérifiée, reproduite et classée par sévérité avant d'intégrer le rapport.
2–10 jours
Rapport
Rapport PDF structuré avec synthèse exécutive et détail technique. Chaque finding inclut son score CVSS 3.1, sa preuve d'exploitation reproductible, le mapping CWE/OWASP, et un correctif que vos développeurs peuvent appliquer directement.
Inclus
Restitution
Présentation orale des résultats à votre équipe technique et direction. Questions-réponses, priorisation des correctifs selon l'impact business, et planification des retests pour valider vos corrections.
Inclus
Notre format Pentest Rapide compresse ce processus pour livrer un rapport complet en 48 heures ouvrées sur un périmètre défini.
Approches
Trois niveaux de test, toujours avec le code
On accède au code source dans chaque audit — black box inclus. C'est ce qui nous permet de confirmer que chaque vulnérabilité est réelle, pas un faux positif. Ce qui change entre les approches : le niveau d'authentification utilisé pendant les tests.
Black box
Simulation d'un attaquant externe sans authentification, avec accès au code source pour valider chaque finding. On teste la surface exposée — endpoints publics, formulaires, configurations serveur — et on vérifie dans le code que la vulnérabilité est réelle et exploitable. Idéal pour un premier audit ou une évaluation de votre posture défensive.
Code source + aucune authentification
Grey box
Tests avec un ou plusieurs comptes utilisateur aux rôles différents, combinés à l'accès au code source. On cible les failles IDOR, l'élévation de privilèges, la logique métier et le contrôle d'accès entre rôles — puis on vérifie chaque finding dans le code. Le format le plus courant pour les SaaS multi-tenant.
Code source + compte(s) utilisateur
White box
Accès complet au code source, à l'environnement et à tous les rôles applicatifs. Revue de code approfondie combinée aux tests d'intrusion pour une couverture maximale : patterns anti-sécurité, secrets hardcodés, dépendances vulnérables, architecture applicative et flux de données sensibles.
Code source + accès complet
Prérequis
Ce qu'on vous demande avant de commencer
On gère l'intégralité de l'audit. Voici ce dont on a besoin de votre côté pour démarrer.
01
Accès au code source
Accès en lecture au repo Git (GitHub, GitLab, Bitbucket). Inclus dans chaque audit, quel que soit le niveau black, grey ou white box.
02
Comptes utilisateur
Un ou plusieurs comptes avec des rôles différents (admin, user, viewer) pour les audits grey et white box. Pas nécessaire en black box.
03
URL de l'environnement
Environnement de staging ou de production selon ce qu'on définit lors du cadrage. On s'adapte à vos contraintes.
04
1h d'appel de cadrage
Un appel avec votre CTO ou lead dev pour comprendre l'architecture, les fonctionnalités critiques et les modèles de menaces spécifiques à votre application.
05
Documentation API
Collection Postman, spec OpenAPI, ou documentation interne si disponible. On peut aussi mapper les endpoints directement depuis le code.
Périmètre
Les vecteurs d'attaque couverts par chaque audit
Les applications SaaS multi-tenant partagent une infrastructure commune, exposent des APIs publiques et déploient en continu. Voici les vecteurs d'attaque qu'on teste systématiquement — dans le code et en conditions réelles — pour vérifier l'isolation des données entre tenants et la robustesse de chaque couche.
Injection
SQL, NoSQL, LDAP, OS command, template injection (SSTI). Tous les points d'entrée utilisateur sont testés avec des payloads adaptés au contexte technique de votre application.
Broken access control
IDOR, élévation de privilèges horizontale et verticale, contournement RBAC, accès non autorisé entre tenants. Rôles, ressources, tenants : tout est testé pour vérifier l'isolation des données.
Authentification & sessions
Bruteforce, credential stuffing, fixation de session, tokens JWT mal configurés, contournement 2FA. On vérifie la robustesse de l'ensemble des mécanismes d'authentification et de gestion de session.
Logique métier
Race conditions, manipulation de workflows, abus de fonctionnalités (coupons, limites, exports), contournement de règles business. Ces failles ne sont détectables que par des tests manuels contextualisés.
Exposition de données
APIs qui sur-exposent des champs sensibles, réponses verbose, stack traces en production, données dans les logs ou le localStorage. On identifie toute fuite d'information exploitable.
Configuration & déploiement
Headers de sécurité (CSP, HSTS, X-Frame-Options), CORS permissifs, erreurs de configuration serveur, secrets dans le code source. Tout composant d'infrastructure exposé est audité.
Philosophie
Pourquoi on ne lance pas de scanner
Les scanners automatiques — Burp Scanner, OWASP ZAP, Nessus — génèrent du bruit. Faux positifs, findings non reproductibles, aucune compréhension de la logique métier de votre application. Un rapport de scanner ne vous dit pas si un utilisateur peut accéder aux données d'un autre tenant, ni si une race condition permet de contourner vos limites de paiement.
Un test d'intrusion manuel identifie les vulnérabilités que les scanners ne trouvent pas : IDOR entre tenants, élévation de privilèges via la logique métier, race conditions sur les endpoints critiques, chaînes d'exploitation multi-étapes qui combinent plusieurs faiblesses pour un impact réel. Ces failles représentent le risque réel pour un éditeur SaaS.
Chaque finding de nos rapports est vérifié manuellement, reproduit dans un contexte réaliste, et accompagné d'une preuve d'exploitation concrète — requête HTTP, payload, capture d'écran. Pas un copier-coller de CVE, pas une alerte générée par un outil. Un finding que votre équipe peut comprendre, reproduire et corriger.
C'est aussi pour ça qu'on demande l'accès au code source sur chaque mission. Un finding identifié en black box est systématiquement tracé jusqu'à la ligne de code vulnérable. Le rapport ne contient que des vulnérabilités confirmées et exploitables.
Chaque audit est réalisé par un pentester senior spécialisé SaaS. Pas de sous-traitance, pas de junior.
Livrable
Ce que contient chaque rapport
Synthèse exécutive
Résumé non technique pour la direction et les investisseurs. Score de risque global, nombre de findings par sévérité, recommandations prioritaires.
Findings détaillés
Chaque vulnérabilité documentée individuellement : description, impact, preuve d'exploitation, score CVSS 3.1, classification CWE et OWASP.
Preuves d'exploitation
Requêtes HTTP, captures d'écran, payloads utilisés. Chaque finding est reproductible par votre équipe technique.
Correctifs proposés
Extraits de code, configuration recommandée, ou changement d'architecture. Applicable directement par vos développeurs.
Mapping conformité
Chaque finding mappé vers NIS2, DORA, SOC 2, ISO 27001 ou PCI DSS selon votre secteur et vos obligations réglementaires.
Matrice de risque
Vue synthétique des vulnérabilités par sévérité (critique, haute, moyenne, basse) et par catégorie OWASP Top 10.
Référentiels
Les standards qui encadrent chaque audit
Chaque finding est classé, scoré et mappé vers les référentiels de conformité applicables à votre secteur.
Standards de test
Scoring & classification
Mapping conformité
Questions fréquentes
Questions sur notre méthodologie
Quelle est la différence entre un test black box et white box ?
En black box, on teste sans authentification — mais toujours avec accès au code source pour valider chaque finding. En white box, on a accès complet : code, environnement, et tous les rôles applicatifs pour une revue de code approfondie. Le grey box (avec des comptes utilisateur) est le format le plus courant pour les SaaS car il permet de tester le contrôle d'accès entre rôles. Dans les trois cas, l'accès au code source est inclus.
Quels référentiels suivez-vous pour les tests d'intrusion ?
Chaque audit suit la méthodologie OWASP Web Security Testing Guide (WSTG) et les critères de l'Application Security Verification Standard (ASVS). On applique également le PTES (Penetration Testing Execution Standard) et l'OSSTMM. Les vulnérabilités sont scorées en CVSS 3.1 et classées selon les catégories CWE.
Combien de temps dure un audit de sécurité complet ?
Un audit Rapide est livré en 48 heures ouvrées sur un périmètre défini. Un audit à périmètre étendu (application complète + API + revue de code) prend entre 5 et 10 jours ouvrés selon la complexité. Le cadrage initial dure 1 jour, la restitution orale est incluse dans chaque format.
Est-ce que les tests risquent de perturber notre production ?
Non. Le périmètre et les conditions de test sont définis lors du cadrage. On peut intervenir sur un environnement de staging ou directement en production avec des précautions adaptées : pas de tests destructifs, pas d'injection de données permanentes, fenêtres horaires définies. Chaque test est contrôlé et réversible.
Quelles technologies et langages couvrez-vous ?
On audite les applications web (React, Vue, Angular, Next.js), les APIs REST et GraphQL, les applications mobiles iOS et Android, et les infrastructures cloud AWS, GCP et Azure. Côté backend : Node.js, Python, PHP, Go, Java, Ruby et leurs frameworks principaux. Le périmètre technique exact est confirmé lors du cadrage.
Comment sont classées les vulnérabilités dans le rapport ?
Chaque vulnérabilité reçoit un score CVSS 3.1 (de 0.0 à 10.0) qui mesure sa sévérité objective. Elle est également classée par catégorie CWE et mappée vers le référentiel OWASP Top 10. Le rapport inclut une matrice de risque visuelle qui agrège les findings par sévérité (critique, haute, moyenne, basse) pour prioriser la remédiation.
Que se passe-t-il si une faille critique est découverte pendant l'audit ?
Les vulnérabilités critiques (CVSS 9.0+) sont signalées immédiatement par email sécurisé, sans attendre la fin de l'audit. Vous recevez la description de la faille, la preuve d'exploitation et le correctif recommandé dans les heures qui suivent la découverte. Le rapport final intègre ensuite l'ensemble des findings.
Que se passe-t-il après la livraison du rapport ?
Vous recevez le rapport et la restitution orale. Votre équipe corrige les vulnérabilités, puis on réalise un retest gratuit pour vérifier que chaque correctif est effectif. On reste disponible pendant 30 jours après la livraison pour répondre aux questions techniques de vos développeurs sur les findings et les correctifs proposés.
Êtes-vous qualifiés PASSI ?
Salvor Labs applique les référentiels méthodologiques utilisés par les prestataires PASSI (OWASP WSTG, ASVS, PTES). Nos rapports suivent le même format et la même rigueur que ceux exigés par l'ANSSI.
Vous savez comment on travaille.
On passe au cadrage ?
Décrivez votre projet en 2 minutes. On revient vers vous le même jour avec une proposition de périmètre et un devis détaillé.
Réponse le jour même — audits à partir de 2 500 € HT