Le moyen le plus rapide d'obtenir un rapport de pentest prêt pour l'audit SOC 2

Le moyen le plus rapide d'obtenir un rapport de pentest prêt pour l'audit SOC 2 est une plateforme de pentest par IA à la demande, qui associe exploration autonome et validation des exploits. Les startups testent ensemble le web, les API et le mobile, reçoivent une preuve d'exploitation déterministe et obtiennent une lettre d'attestation ; une évaluation Core est estimée à 5 à 7 jours, et les périmètres plus vastes prennent de 10 à 20 jours.

Conclure une vente à un grand compte est l'une des étapes les plus exigeantes pour une entreprise SaaS B2B en phase de démarrage. Votre équipe passe des mois à démontrer la valeur du produit, à rallier les parties prenantes et à négocier les conditions commerciales. Puis, à la dernière porte d'approbation, les achats du grand compte interrompent tout le processus. Leur équipe de gestion des risques liés aux tiers (Third-Party Risk Management, TPRM) envoie un questionnaire d'évaluation de la sécurité du fournisseur qui exige un rapport de test d'intrusion indépendant et une lettre d'attestation formelle datée de moins de douze mois.

Les cabinets de conseil en sécurité traditionnels demandent trois à cinq semaines de délai de planification et facturent entre 15 000 et 40 000 $ une évaluation ponctuelle. Pour une startup au budget opérationnel limité et soumise à un quota de ventes trimestriel urgent, attendre un mois pour obtenir un créneau de test planifié casse l'élan du chiffre d'affaires. À l'inverse, lancer un simple scanner de vulnérabilités automatisé et soumettre le PDF obtenu conduit à un rejet immédiat, aussi bien par les achats des grands comptes que par les auditeurs SOC 2.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           FAST-TRACK AUDIT EVIDENCE PIPELINE                            │
└─────────────────────────────────────────────────────────────────────────────────────────┘

   [Target Assets] ──► [Agentic Deep Scan] ──► [Deterministic Proof] ──► [Developer Remediation]
      • Web Apps          • Autonomous Agents     • HTTP Request/Resp        • Actionable Curl PoCs
      • REST/GraphQL      • Contextual Chaining   • Differential Baseline    • Zero Triage Friction
      • iOS & Android     • Logic & Auth Checks   • Low False Positives
                               │
                               ▼
   [1-Click Re-Test] ──► [Finding Review] ────► [Audit Package Export] ──► [Unblock Sales]
      • Risk Rerun Pass     • Named Sign-off      • Attestation Letter (LoA)   • Pass SIG / CAIQ
      • Verified Retest     • Quality Review      • Executive Summary (NDA)    • Close Deals Fast

Que vérifient réellement les équipes TPRM des grands comptes dans un rapport de pentest ?

Les équipes de gestion des risques liés aux tiers (TPRM) des grands comptes vérifient quatre critères principaux dans un dossier de pentest : une lettre d'attestation indépendante datée de moins de 12 mois, un périmètre multi-actifs complet (web, API et mobile), aucune vulnérabilité de sévérité élevée ou critique non résolue, et des tests alignés sur des référentiels reconnus (OWASP et NIST SP 800-115).

Pour évaluer le risque fournisseur, les équipes de sécurité des grands comptes s'appuient sur des référentiels standardisés comme Shared Assessments SIG Lite (v2024/2025), le Consensus Assessments Initiative Questionnaire de la Cloud Security Alliance (CSA CAIQ v4) et les profils fournisseurs Whistic. Ces évaluations reposent sur des règles de validation strictes au titre de la gestion des menaces et des vulnérabilités (Threat and Vulnerability Management, TVM).

Les équipes achats des grands comptes examinent rarement le code de votre application ni les détails sensibles de reproduction des vulnérabilités. Partager des exploits bruts sous forme de preuves de concept introduit des risques pour la propriété intellectuelle et des dangers opérationnels. À la place, les acheteurs évaluent deux documents de vérification externes, sous accord de non-divulgation :

1. La lettre d'attestation indépendante (LoA) : Une déclaration signée, sur papier à en-tête du prestataire de test, qui confirme les dates de l'évaluation, le périmètre de test défini, la méthodologie standardisée et la posture de risque globale.
2. Le rapport de synthèse : Une vue d'ensemble expurgée à destination de la direction, qui résume la couverture des tests, la répartition des vulnérabilités par sévérité et l'état de la remédiation, sans exposer de payloads d'exploit bruts.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           ENTERPRISE TPRM EVALUATION WORKFLOW                           │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   Enterprise Prospect                                     Startup / Vendor              │
│  ┌────────────────────┐   Sends Questionnaire (SIG / CAIQ) ┌─────────────────────────┐  │
│  │ Procurement & TPRM │ ─────────────────────────────────► │ Sales & Security Team   │  │
│  └─────────┬──────────┘                                    └────────────┬────────────┘  │
│            │                                                            │               │
│            ▼ Verifies Attached Evidence                                 ▼ Evidence      │
│  ┌───────────────────────────────────────────────────────────────────────────────────┐  │
│  │ 1. Independent Third-Party Letter of Attestation (LoA) (Signed, < 12 months)      │  │
│  │ 2. Scoping Document (Production Web, APIs, Mobile Apps, Cloud Boundaries)          │  │
│  │ 3. Remediation Verification (Zero unresolved Critical / High findings)             │  │
│  │ 4. Recognized Methodology (OWASP Top 10, OWASP WSTG, NIST SP 800-115, PTES)        │  │
│  └───────────────────────────────────────────────────────────────────────────────────┘  │
│            │                                                                            │
│            ├─► Raw Scanner Export (Nessus/ZAP) ──────────► REJECTED (Deal Blocked)      │
│            │                                                                            │
│            └─► AI Pentest Attestation + PoC Traces ──────► APPROVED (Deal Unblocked)    │
└─────────────────────────────────────────────────────────────────────────────────────────┘

Pour franchir les achats d'un grand compte, votre dossier de test d'intrusion doit satisfaire quatre critères non négociables :

• Indépendance structurelle d'un tiers : Les auto-évaluations, les revues d'ingénierie internes et les sorties brutes d'outils lancés par vos propres développeurs échouent immédiatement à l'inspection. Les acheteurs exigent une évaluation externe et objective.
• Cohérence complète du périmètre : Le périmètre de test doit refléter les frontières de production qui stockent les données clients. Si votre architecture comprend des tableaux de bord web, des microservices backend REST ou GraphQL et des applications mobiles (iOS/Android), ne tester que le domaine web marketing déclenche des exceptions d'audit.
• Méthodologie de test standardisée : L'évaluation doit citer des référentiels sectoriels reconnus, notamment NIST SP 800-115, l'OWASP Web Security Testing Guide (WSTG), l'OWASP API Security Top 10 et l'OWASP Mobile Application Security Verification Standard (MASVS).
• Remédiation documentée et vérification par un nouveau test : Les acheteurs des grands comptes écartent les fournisseurs qui ont des vulnérabilités de sévérité critique ou élevée ouvertes. Si des failles sont identifiées lors du test initial, votre dossier doit inclure la documentation d'un nouveau test vérifié, qui montre leur correction effective.

Pourquoi les auditeurs SOC 2 rejettent-ils les scans de vulnérabilités automatisés ?

Les auditeurs SOC 2 rejettent les scans de vulnérabilités automatisés comme substitut au test d'intrusion, car les Trust Services Criteria de l'AICPA distinguent la détection des vulnérabilités (CC7.1) de l'évaluation du fonctionnement des contrôles (CC4.1). Si le scan automatisé répond à l'exigence d'identification des vulnérabilités connues (CC7.1), les auditeurs et les équipes de sécurité des grands comptes exigent des évaluations distinctes qui vérifient activement si les contrôles internes fonctionnent face à la pression d'un adversaire (CC4.1), un niveau d'exigence que des vérifications isolées par un scanner ne peuvent pas satisfaire.

Les fondateurs demandent souvent si lancer un scanner de vulnérabilités automatisé comme Nessus, Qualys ou OWASP ZAP satisfait l'exigence de test d'intrusion pour la conformité SOC 2. En pratique, les auditeurs SOC 2 distinguent le scan de vulnérabilités automatisé du test d'intrusion : le scan identifie des failles potentielles à partir de signatures connues, alors que le test d'intrusion demande de vérifier activement si les contrôles peuvent être contournés et de démontrer la viabilité des exploits.

L'explication tient à la formulation exacte des Trust Services Criteria de l'American Institute of Certified Public Accountants (AICPA), dans la section TSP 100.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                       AICPA TRUST SERVICES CRITERIA & AUDIT MAPPING                     │
├──────────────────────────────────────────┬──────────────────────────────────────────────┤
│ CC7.1: Vulnerability Identification      │ CC4.1: Monitoring & Separate Evaluations     │
├──────────────────────────────────────────┼──────────────────────────────────────────────┤
│ • Goal: Detect vulnerabilities & patches │ • Goal: Evaluate if controls actually WORK   │
│ • Tooling: Vulnerability Scanners        │ • Tooling: Penetration Testing               │
│   (Nessus, Qualys, Trivy, Dependabot)    │   (Autonomous Agents + Human Validation)     │
│ • Mechanism: Version checks & signatures │ • Mechanism: Active Adversary Simulation     │
│ • Artifact: Scan summaries, patch logs   │ • Artifact: Proof of Concept (PoC), LoA      │
│ • Audit Role: Core Evidence for CC7.1    │ • Audit Role: Industry Benchmark for CC4.1   │
└──────────────────────────────────────────┴──────────────────────────────────────────────┘

La différence entre CC7.1 et CC4.1

Les Trust Services Criteria séparent la gestion des vulnérabilités du test des contrôles opérationnels :

1. CC7.1 (opérations système - gestion des vulnérabilités) : Exige d'une entité qu'elle mette en œuvre des procédures de détection pour identifier les changements de configuration et les vulnérabilités du système. Les scans de vulnérabilités automatisés, les vérifications de dépendances et les scans d'images de conteneurs satisfont CC7.1 en prouvant que votre équipe recherche les failles logicielles connues.
2. CC4.1 (principe 16 du COSO - évaluations continues et distinctes) : Exige des évaluations distinctes pour s'assurer que les composants du contrôle interne sont présents et fonctionnent sous pression réelle. Vérifier une politique de sécurité confirme qu'une règle existe sur le papier ; attaquer l'application en production confirme que le contrôle résiste effectivement aux accès non autorisés. Même si les critères de l'AICPA n'imposent pas nommément le test d'intrusion, les auditeurs et les équipes TPRM des grands comptes considèrent le test d'intrusion indépendant comme l'activité de contrôle standard pour étayer les évaluations CC4.1.

Quatre failles structurelles des scans de vulnérabilités bruts

Les scans de vulnérabilités bruts échouent au seuil CC4.1 pour quatre raisons distinctes :

• Aucune preuve d'exploitation : Les scanners comparent des bannières logicielles et des motifs regex pour émettre des hypothèses spéculatives (comme « faille Apache potentielle »). Ils n'exécutent pas d'attaque pour confirmer si le endpoint est accessible, exécutable ou protégé par des pare-feu en amont.
• Incapacité à tester les failles de logique métier : Les scanners envoient des requêtes HTTP isolées. Ils ne peuvent pas évaluer des workflows d'autorisation en plusieurs étapes, comme la Broken Object Level Authorization (BOLA/IDOR), les fuites de données multi-tenant ou l'élévation de privilèges entre des rôles authentifiés.
• Taux élevés de faux positifs : Les scanners automatisés produisent régulièrement de 20 % à 50 % de bruit en faux positifs. Les auditeurs CPA refusent de trier des alertes non vérifiées et obligent le fournisseur à en prouver manuellement la validité.
• Absence de contexte adversarial : Les auditeurs exigent la preuve qu'un attaquant ne peut pas enchaîner plusieurs problèmes de faible sévérité pour former un chemin critique d'exfiltration de données. Les scanners évaluent les paramètres isolément et ne peuvent pas enchaîner des étapes d'attaque.

Le rôle de la responsabilité nominative dans l'acceptation par l'audit

Les auditeurs ne jugent pas les évaluations selon que des outils d'IA ont été utilisés pendant leur exécution. Ils évaluent la crédibilité des preuves, la transparence de la méthodologie et la responsabilité humaine nominative. Un rapport généré uniquement par un script automatisé non vérifié, sans supervision humaine, se lit comme une auto-évaluation non validée.

Pour répondre aux normes d'audit, un dossier d'évaluation requiert : * Une preuve vérifiable par requête/réponse qui montre un impact réel. * Une méthodologie documentée et inspectable, alignée sur des standards établis. * Une revue humaine nominative et qualifiée, qui valide l'exactitude des constats et signe l'attestation. * Des limites de périmètre claires, reliées directement à la description du système SOC 2.

Comparer vos options : cabinets de conseil traditionnels, scanners ou Ostorlab AI Pentest

Les startups qui évaluent leurs options de test d'intrusion ont le choix entre trois modèles de livraison distincts. Comprendre leurs différences structurelles aide les équipes à choisir l'approche adaptée à leur vitesse de vente et à leur rigueur en matière de conformité.

Comment Ostorlab offre une rigueur de niveau audit sans les délais du conseil

Ostorlab associe la technologie autonome Agentic Deep Scan à la validation des exploits. Au lieu de générer des alertes hypothétiques, des agents autonomes explorent l'état de l'application, formulent des hypothèses d'attaque contextuelles et exécutent des exploits vérifiés, et chaque vulnérabilité confirmée est livrée avec un exploit fonctionnel.

Figure 1 : Aperçu du rapport d'évaluation Ostorlab Agentic Deep Scan. Le tableau de bord affiche la note de risque globale, le périmètre de l'architecture cible, la durée du scan et la répartition des vulnérabilités par catégorie, prêtes pour l'inspection par les auditeurs.

1. Preuve déterministe d'exploitabilité (PoC)

Les auditeurs et les évaluateurs des grands comptes exigent des preuves vérifiables. Les vulnérabilités d'Ostorlab ne reposent pas sur des scores de confiance subjectifs. Chaque vulnérabilité signalée s'accompagne d'une preuve déterministe adaptée à l'actif cible (des paires requête/réponse HTTP complètes avec des commandes curl pour le web et les API, des déclencheurs IPC et des journaux d'exécution pour les applications mobiles, et des chemins d'exécution vérifiés pour les problèmes au niveau du code), ainsi que d'une analyse précise de la cause racine.

Figure 2 : Vue détaillée d'une vulnérabilité dans la plateforme Ostorlab. Le rapport établit la sévérité, la confirmation de la cause racine, les chemins de code affectés et des étapes de reproduction claires, afin que les développeurs corrigent le défaut sous-jacent sans ambiguïté.

Prenons l'exemple de cette vulnérabilité de type Broken Object Level Authorization (BOLA), expurgée, découverte lors d'une évaluation d'API authentifiée :

POST /api/v2/workspaces/ws_89234/billing/invoices HTTP/1.1
Host: target-api.internal-saas.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "target_tenant_id": "tenant_enterprise_7710",
  "request_export": true
}

La réponse du serveur confirme l'exfiltration de données de tenants au-delà des frontières organisationnelles :

HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 11 Sep 2026 14:22:04 GMT

{
  "status": "success",
  "tenant_id": "tenant_enterprise_7710",
  "invoices": [
    {
      "invoice_id": "inv_99812",
      "amount_usd": 124500.00,
      "billing_contact": "finance@fortune500-client.com",
      "payment_method": "ACH_****8812"
    }
  ]
}

Figure 3 : Preuve d'exploitation à l'exécution générée par l'agent. La réponse déchiffrée démontre une exposition réelle de données et donne aux auditeurs une preuve indiscutable de compromission, plutôt qu'une heuristique théorique.

La vulnérabilité est accompagnée d'une vérification par baseline différentielle prouvant que les endpoints non vulnérables appliquent des contrôles stricts d'isolation entre tenants. Les développeurs reçoivent une commande de reproduction exploitable, tandis que les auditeurs reçoivent une preuve indiscutable d'exploitation.

2. Pile multi-actifs unifiée : web, API et mobile

Les architectures SaaS modernes vont au-delà des applications web traditionnelles. Les microservices backend, les passerelles GraphQL et les clients mobiles natifs (iOS et Android) interagissent directement avec les données des clients grands comptes.

Figure 4 : Méthodologie de test inspectable d'un Ostorlab Agentic Deep Scan. Les auditeurs peuvent inspecter l'agent de planification nommé, les objectifs explicites et les tâches d'exécution par phases, ce qui prouve la conformité aux normes formelles de test d'intrusion.

Les scanners web à usage unique ne peuvent ni décompiler des binaires mobiles ni contourner l'épinglage de certificat. Ostorlab propose des tests multi-actifs unifiés : * Deep scan web et API : Exploration autonome de l'état, ingestion de collections OpenAPI et Postman, et tests dynamiques des contrôles d'autorisation. * Instrumentation dynamique mobile : Tests automatisés des applications Android (APK) et iOS (IPA) avec le framework de test dynamique Monkey, l'instrumentation à l'exécution et la détection des risques liés au stockage local. * Analyse de pivot inter-actifs : Découverte de secrets mobiles codés en dur et enchaînement de ceux-ci pour extraire des ressources d'API backend non autorisées.

3. Nouveau test de remédiation en un clic via les Risk Reruns

Dans un test d'intrusion traditionnel, corriger une vulnérabilité n'est que la moitié du chemin. Vérifier le correctif suppose de contacter le cabinet, d'attendre qu'un testeur soit disponible et, souvent, de payer des frais supplémentaires de nouveau test.

Ostorlab supprime cette friction opérationnelle grâce aux Risk Reruns et à la Single Vulnerability Assessment (SVA) : 1. Les développeurs inspectent le payload de reproduction exact et déploient un correctif de code en staging ou en production. 2. En un clic, l'équipe d'ingénierie déclenche un Risk Rerun ciblé directement sur l'endpoint concerné. 3. L'agent autonome réexécute exactement la même chaîne d'exploitation avec des identifiants de session récents. 4. Si l'attaque est bloquée avec succès, la plateforme met à jour le statut de la vulnérabilité en « Remediated » et enregistre une entrée de vérification horodatée dans le journal d'audit.

Figure 5 : Interface Risk Reruns en un clic. Les développeurs retestent instantanément les vecteurs corrigés et produisent des enregistrements de vérification horodatés cryptographiquement, que les auditeurs acceptent pour valider proprement la remédiation.

4. Validation et attestation nominative

Chaque package AI Pentest inclut un exploit fonctionnel pour chaque vulnérabilité confirmée par les agents et une fenêtre de nouveau test. La validation humaine ne fait pas partie de tous les packages ; consultez la comparaison des plans pour savoir où elle est incluse ou disponible en option. Le package final du rapport comprend : * Un rapport de synthèse avec des indicateurs de risque de haut niveau pour la direction et les acheteurs des grands comptes, sous accord de non-divulgation. * Une cartographie complète du périmètre technique et de la méthodologie (NIST SP 800-115, OWASP WSTG). * Un journal de remédiation vérifié prouvant l'absence de vulnérabilités critiques ou élevées ouvertes. * Une lettre d'attestation formelle et signée, acceptée par les principales plateformes de conformité (Vanta, Drata, Secureframe).

Comment les startups obtiennent un rapport de pentest prêt pour l'audit en environ une semaine

Les startups peuvent passer du cadrage initial à une lettre d'attestation signée et prête pour l'audit en 5 à 7 jours estimés pour une évaluation Core (10 à 14 jours pour Advanced, 15 à 20 jours pour Elite) en suivant un workflow de pentest en 4 phases. Les phases ci-dessous indiquent l'ordre des tâches, et non des durées garanties :

Mis à jour le 1er octobre 2026 : les mentions de délai de livraison et de validation humaine de cet article ont été corrigées pour correspondre à la page actuelle des plans. Mis à jour le 5 octobre 2026 : suppression du badge de sécurité, qui n'est pas proposé.

1. Phase 1 : prise en charge du périmètre et identifiants de départ : Définissez les frontières des données clients documentées dans la description de votre système SOC 2. Importez les URL web, les schémas d'API et les binaires mobiles, en fournissant deux identifiants utilisateur distincts pour tester les contrôles d'autorisation multi-tenant.
2. Phase 2 : Agentic Deep Scan autonome : Des agents autonomes cartographient l'état de l'application, découvrent des endpoints non indexés et exécutent des chaînes d'exploitation à travers les workflows d'authentification, d'autorisation et de logique.
3. Phase 3 : remédiation ciblée par les développeurs : Les développeurs examinent les vulnérabilités critiques et élevées priorisées. Comme chaque vulnérabilité est livrée avec des preuves de reproduction propres à l'actif (traces HTTP et commandes curl pour le web et les API, déclencheurs IPC et journaux d'exécution pour les applications mobiles, chemins d'exécution vérifiés pour les vulnérabilités au niveau du code), les ingénieurs corrigent la cause racine sans ambiguïté de triage.
4. Phase 4 : nouveau test en 1 clic et export de la LoA : L'équipe d'ingénierie déclenche des Risk Reruns sur les vecteurs corrigés pendant la fenêtre de nouveau test incluse. Les fermetures vérifiées sont enregistrées, et la lettre d'attestation et le dossier d'audit sont livrés pour débloquer les achats.

Questions fréquentes sur le pentest SOC 2

Un auditeur SOC 2 acceptera-t-il un rapport de test d'intrusion piloté par l'IA ?

Oui. Les Trust Services Criteria de l'AICPA (TSP Section 100) précisent la rigueur des tests et les standards de preuve, et non l'identité biologique du testeur. Les grands cabinets d'audit CPA acceptent les tests d'intrusion agentiques à condition que l'évaluation suive des méthodologies établies (comme NIST SP 800-115 et OWASP WSTG), inclue une preuve déterministe d'exploitation, définisse un périmètre de test et comprenne une lettre d'attestation indépendante, relue par un humain, qui confirme la remédiation.

En quoi un pentest agentique à la demande diffère-t-il d'un scan de vulnérabilités automatisé ?

Les scanners de vulnérabilités automatisés reposent sur la correspondance statique de motifs, des vérifications de payloads isolées et l'inspection des bannières de version, et produisent des taux élevés de faux positifs sans confirmer l'exploitabilité. Un test d'intrusion agentique interagit activement avec les workflows de l'application, génère des exploits dynamiques, enchaîne plusieurs faiblesses, valide les frontières d'autorisation entre des comptes distincts et fournit des preuves de concept vérifiées.

Les achats d'un grand compte exigent-ils un rapport technique complet ou seulement une lettre d'attestation ?

Les acheteurs des grands comptes exigent en général une lettre d'attestation (LoA) signée et un rapport de synthèse expurgé, sous accord de non-divulgation. Partager des rapports techniques bruts de vulnérabilités expose des endpoints d'application sensibles et des instructions d'exploitation, dont les équipes de risque des grands comptes n'ont pas besoin. La lettre d'attestation confirme l'indépendance du tiers, l'exhaustivité du périmètre et l'absence de vulnérabilités élevées ou critiques non atténuées.

Comment la tarification d'Ostorlab se compare-t-elle au test d'intrusion traditionnel ?

Les cabinets de test d'intrusion traditionnels facturent entre 15 000 et 40 000 $ des évaluations ponctuelles avec des semaines de délai. Ostorlab propose une tarification transparente par paliers, avec des packages Core AI Pentest à partir de 499 $ à la demande (évoluant de façon transparente avec le périmètre et la complexité de l'application), avec prise en charge multi-actifs et une fenêtre de nouveau test. La validation humaine dépend du plan ; consultez la comparaison des plans.

Le test d'intrusion agentique peut-il couvrir les périodes d'observation SOC 2 Type 2 ?

Oui. Les audits SOC 2 Type 2 exigent la preuve de l'efficacité continue des contrôles sur une fenêtre de trois à douze mois. Les pentests annuels traditionnels laissent des mois de modifications de code sans preuve. Les tests agentiques à la demande permettent aux équipes de sécurité d'exécuter des évaluations récurrentes à chaque version majeure, et d'établir une piste de preuves ininterrompue sur toute la fenêtre d'audit.

Normes et références principales

• American Institute of Certified Public Accountants (AICPA). Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (TSP Section 100).
• National Institute of Standards and Technology (NIST). Technical Guide to Information Security Testing and Assessment (NIST SP 800-115).
• Open Web Application Security Project (OWASP). Web Security Testing Guide (WSTG v4.2).
• Open Web Application Security Project (OWASP). API Security Top 10.
• Shared Assessments. Standardized Information Gathering (SIG Lite) Questionnaire.
• Cloud Security Alliance (CSA). Consensus Assessments Initiative Questionnaire (CAIQ v4).