RESPECT

Concepts

RESPECT organise le travail en cinq objets. Les comprendre suffit à se servir de l'outil.

Objet	Ce que c'est
Tenant	Une organisation. Cloisonne tout le reste : deux tenants ne voient jamais les données de l'autre.
Scope	Un périmètre d'évaluation, en général un audit ou une application. C'est l'unité sur laquelle on planifie et on mesure.
Asset	Une cible concrète dans ce périmètre : un hôte, un endpoint, un domaine.
Finding	Une vulnérabilité issue de votre rapport de pentest. Porte une référence, un titre, une sévérité et un état.
Check	Le test reproductible attaché à un finding. C'est lui qui décide si le correctif tient encore.

Un run de validation exécute tous les checks d'un scope et met à jour l'état de chaque finding. Chaque changement d'état est journalisé dans une transition.

Cycle de vie d'un finding

Un finding se déplace entre quatre états selon le résultat de son check. C'est le cœur du produit.

État	Signification
present	La vulnérabilité est ouverte. État initial à l'import.
remediated	Le check est passé : le correctif est vérifié.
regressed	Un finding déjà corrigé dont le check échoue à nouveau.
inconclusive	Le check n'a pas pu s'exécuter : cible injoignable, erreur réseau. État temporaire, sans conclusion.

            check PASS                    check FAIL
present ──────────────► remediated ──────────────► regressed
   ▲                                                    │
   └──────────────────── check PASS ───────────────────┘

n'importe quel état ── check ERROR ──► inconclusive

inconclusive ne compte jamais comme une régression. Une cible en maintenance ne déclenche pas d'alerte.

Démarrage

Le chemin le plus court entre un rapport de pentest et le premier contrôle automatique tient en quatre étapes.

• Créez un scope pour l'audit ou l'application concernée.
• Importez vos findings depuis un fichier CSV, JSON ou YAML.
• Attachez un check à chaque finding que vous voulez surveiller. Vous n'êtes pas obligé de tous les couvrir : commencez par les critiques.
• Planifiez le rejeu, puis laissez tourner.

L'éditeur de checks intégré permet d'exécuter un check en direct contre sa cible avant de l'attacher, et de voir le résultat assertion par assertion. Utilisez-le : un check qui n'a jamais été exécuté à la main est un check qui alertera à tort.

Importer des findings

Trois formats sont acceptés : CSV, JSON et YAML. Quel que soit le format, trois champs sont obligatoires.

Champ	Obligatoire	Détail
ref	oui	Votre référence interne, celle du rapport de pentest.
title	oui	Intitulé de la vulnérabilité. Une ligne sans titre est rejetée.
severity	oui	critical, high, medium, low ou info.
description	non	Texte libre, typiquement le constat et la remédiation attendue.
asset_kind	non	Nature de la cible, par exemple host ou endpoint.
asset_value	non	La cible elle-même : nom d'hôte, URL, endpoint.
source	non	Origine du finding. Sert à retrouver de quel audit il vient.
cwe, owasp	non	Référentiels. Les noms de colonnes courants des outils du marché sont reconnus.

Un CSV minimal ressemble à ceci :

ref,title,severity,asset_kind,asset_value,cwe,owasp
PT-2026-014,Injection SQL sur /api/orders,critical,endpoint,POST /api/orders,CWE-89,A03
PT-2026-015,En-tete HSTS absent,low,host,www.exemple.fr,CWE-319,A05

En JSON, la même chose s'écrit :

{
  "source": "audit-2026-04",
  "findings": [
    {
      "ref": "PT-2026-014",
      "title": "Injection SQL sur /api/orders",
      "severity": "critical",
      "description": "Parametre order_id concatene dans la requete.",
      "asset": { "kind": "endpoint", "value": "POST /api/orders" }
    }
  ]
}

Écrire un check

Un check se décrit en YAML. Il vise une cible, exécute une requête, puis évalue une liste d'assertions. Le check passe si toutes les assertions passent.

name: "Injection SQL corrigee sur /api/orders"
type: http_probe
target: "https://app.exemple.fr/api/orders?order_id=1'"
method: GET
severity: critical
assertions:
  - field: status_code
    operator: eq
    value: 400
  - field: body
    operator: not_contains
    value: "SQL syntax"
tags: [sqli, owasp-a03]

Le raisonnement est inversé par rapport à un scanner : vous écrivez ce qui doit être vrai quand la faille est corrigée. Ici, l'application doit rejeter l'entrée et ne jamais laisser fuiter d'erreur SQL. Le jour où l'un des deux cesse d'être vrai, le finding repasse en régression.

Deux modes de détection

Le sélecteur DETECTION de l'éditeur décide de ce que vos assertions décrivent. C'est le réglage le plus structurant d'un check, et le plus facile à se prendre à l'envers.

Mode	Vos assertions décrivent…
Normal	l'état corrigé. Le check passe quand elles sont vraies. C'est le mode par défaut et celui de l'exemple ci-dessus.
Signature	le motif vulnérable. Le check passe quand elles ne se vérifient plus. Pratique quand la faille est plus facile à décrire que sa correction.

Opérateurs disponibles

Famille	Opérateurs
Égalité	eq, neq, in, not_in
Texte	contains, not_contains
Expression régulière	matches, matches_regex, not_matches_regex
Comparaison	gt, lt, gte, lte
Présence	exists, not_exists
URL	eq_url, neq_url - comparent des URL en ignorant les différences non signifiantes

Plusieurs checks peuvent être enchaînés dans un même document en les séparant par ---.

Bonnes pratiques

• Ne suivez pas les redirections sans raison. follow_redirects vaut false par défaut, et c'est voulu : si vous l'activez, une assertion status_code eq 301 ne verra jamais le 301, masqué par le suivi.
• Préférez in à eq sur les codes de statut. Un 401 et un 403 disent tous les deux « non autorisé ». Tester in [401, 403] évite une fausse régression le jour où l'application change de code.
• Doublez toujours d'une assertion sur le corps. Un 200 ne prouve rien si la page renvoie encore la trace d'erreur. Ajoutez un body not_contains sur la chaîne révélatrice.
• Pour une cible décommissionnée, utilisez expect_unreachable: true plutôt que de laisser le check tomber en erreur. Sans ça, la suppression du DNS produit des inconclusive à répétition au lieu d'un vert franc.
• Gardez un timeout entre 5 et 15 secondes. Au-delà, le check immobilise l'ordonnanceur sans rien apprendre de plus.
• Cinq à sept assertions par check, pas davantage. Au-delà, découpez : quand le check échoue, vous voulez savoir lequel des deux problèmes est revenu.
• N'oubliez pas l'authentification. Sur un endpoint protégé, un check sans profil d'authentification renverra 401 en permanence - un vert ou un rouge qui ne veut rien dire.

Quand un check échoue sans raison apparente

• Rejouez-le en direct depuis l'éditeur et lisez le résultat assertion par assertion : le détail indique laquelle a échoué.
• Une valeur obtenue vide signifie que la cible n'a pas répondu. C'est un cas pour expect_unreachable, pas pour une assertion plus permissive.
• Une expression régulière rejetée l'est par la protection anti-ReDoS. Un motif comme (a+)+ est refusé : simplifiez-le.
• Un résultat en erreur plutôt qu'en succès ou échec vient du transport - délai dépassé, TLS, DNS - et non de vos assertions.

Types de checks

Les cinq types ci-dessous couvrent la grande majorité des remédiations d'un rapport de pentest applicatif.

Type	Ce qu'il fait
http_probe	Envoie une requête HTTP, puis teste le code de statut, le corps et les en-têtes.
dns_resolve	Résout un nom et vérifie qu'il pointe, ou justement qu'il ne pointe plus.
tls_inspect	Ouvre une session TLS et vérifie le protocole négocié. Sert à confirmer qu'une version faible a bien été coupée.
port_scan	Tente une connexion TCP et vérifie qu'un port est ouvert ou fermé.
header_check	Vérifie la présence, l'absence ou la valeur d'un en-tête de sécurité.

Le moteur en expose d'autres, plus spécialisés, notamment cert_expiry, ssh_audit, spf_check, dmarc_check, dkim_check, cors_check, jwt_probe, smtp_check, ldap_check, snmp_check et http_chain pour les scénarios multi-requêtes.

Rejeu de charges

Le type attack_replay ne teste pas une requête mais un jeu de charges complet. Vous désignez un payload_set et le champ où l'injecter, et le moteur les rejoue toutes.

name: "XSS réfléchi corrigé sur /?name="
type: attack_replay
target: "https://demo.exemple.fr/?name={{payload}}&r=greet"
method: "get"
timeout: 10
payload_set: "xss_reflected_basic"
injection_field: "url"

Le résultat est global : 12 charges sur 12 bloquées vaut succès, une seule passée vaut échec. C'est le bon outil quand la remédiation est un filtre - encodage de sortie, pare-feu applicatif, validation d'entrée - plutôt qu'un correctif ponctuel.

Modèles prêts à l'emploi

L'éditeur embarque une bibliothèque de 91 modèles rangés par famille : vulnérabilités web, rejeu de charges, rappels hors bande pour les failles aveugles, mauvaises configurations, fuites d'information, TLS et cryptographie, réseau, en-têtes de sécurité, authentification et session, FTP, SSH, certificats, sécurité du courriel, CORS, infrastructure, force brute et limitation de débit, IDOR et BOLA multi-contextes, mutations de jetons JWT, garde-fous anti faux positifs, attestation de posture. Une entrée dédiée les filtre par catégorie OWASP Top 10.

Planification

La planification se règle par scope, pas par finding : tous les checks d'un périmètre sont rejoués ensemble, ce qui donne un état cohérent à une date donnée. Un scope peut être mis en pause puis repris sans perdre son historique.

Choisissez la fréquence en fonction du rythme de déploiement de l'application surveillée, pas de la sévérité des findings. Une application livrée chaque semaine mérite un rejeu quotidien : c'est le déploiement qui casse les correctifs, pas le temps qui passe.

Un run peut aussi être déclenché à la main avec Run now, sans toucher à la planification. Utile après un déploiement dont vous voulez vérifier l'effet immédiatement, plutôt que d'attendre le prochain passage.

Rapports et couverture

Chaque scope produit un rapport PDF reprenant la posture, les findings et leur état. C'est le livrable à joindre à un comité de sécurité ou à renvoyer au client d'un audit.

Le tableau de bord affiche par ailleurs une couverture par référentiel : vos findings sont rattachés aux catégories de l'OWASP Top 10, avec un score par catégorie et le compte de ceux qui ne sont rattachés à rien. Ces derniers méritent un coup d'œil - un finding non classé est souvent un finding mal décrit à l'import.

Alertes

Une transition vers regressed déclenche une alerte par courriel et par webhook. Le webhook permet de router l'information vers votre messagerie d'équipe, votre SIEM ou votre outil de ticketing.

Seules les régressions alertent. Un finding qui reste ouvert ne génère pas de bruit quotidien, et un check inconclusive n'alerte pas non plus.

Score de posture

Le score résume l'exposition d'un scope sur une échelle de 0 à 100, pondérée par la sévérité.

score = 100 × (1 − exposition_ouverte / exposition_totale)

Sévérité	Poids
critical	10
high	6
medium	3
low	1
info	0,2

Tous les findings corrigés donnent un score de 100. La pondération fait qu'un critique ouvert pèse autant que dix findings faibles : le score ne peut pas être gonflé en corrigeant les broutilles.

Rôles

Rôle	Portée
client_admin	Administre son organisation : scopes, findings, checks, utilisateurs.
check_creator	Écrit et modifie les checks, sans toucher à l'administration.
analyst	Consulte les findings, les runs et la posture. Pas de modification.
mssp_admin	Prestataire gérant plusieurs organisations clientes.