Module EASM — Surface d'attaque externe

Le module EASM (External Attack Surface Management) est le cœur de Scanyze. Il orchestre 22 outils open-source réputés pour cartographier votre exposition publique : sous-domaines, ports, services, certificats TLS, vulnérabilités connues, configuration DNS/email, fuzzing, DAST, etc.

Tous les outils s'exécutent dans des workers Kubernetes isolés, en filesystem read-only, sans accès aux données des autres tenants. Les résultats sont normalisés en findings avec scoring CVSS, déduplication et corrélation cross-tools.

Les 22 outils orchestrés

Source de vérité : secuscan-api/internal/scanner/tools/.

Cycle de vie d'un scan EASM

[1] Création de la cible      → models.Target créé, statut=active
       ↓
[2] Lancement du scan          → POST /v1/scans, body { targetId, scanConfig }
       ↓
[3] Mise en file d'attente     → Job Asynq dans Redis (queue scanner)
       ↓
[4] Worker prend le job         → consumer dans cmd/worker/
       ↓
[5] Phase 1 : Découverte        → Subfinder + AssetFinder + WHOIS + ASN
       ↓
[6] Phase 2 : Network           → Nmap, services
       ↓
[7] Phase 3 : TLS / DNS / Email → TestSSL, DNS Audit, DMARC, SPF
       ↓
[8] Phase 4 : HTTP layer        → HTTPx, Headers, Crawler, Screenshots, WAF
       ↓
[9] Phase 5 : Vulnérabilités    → Nuclei, NSE scripts, Dir Discovery
       ↓
[10] Phase 6 : DAST + Fuzzer    → seulement si activés
       ↓
[11] Phase 7 : Threat intel     → seulement si activé
       ↓
[12] Post-scan                  → Déduplication, scoring, posture, alertes
       ↓
[13] Notifications              → Email / Slack / webhook si new critical

Chaque outil émet ses findings dans une table dédiée puis le post-scan service consolide tout dans findings avec déduplication par signature canonique (titre + cible + module).

Profils de scan

Les profils contrôlent uniquement le débit cumulé et la concurrence HTTP — pas le périmètre fonctionnel. Source : secuscan-api/internal/scanner/tools/rate_profile.go.

Si vous demandez standard ou aggressive sans avoir vérifié le domaine, Scanyze rétrograde silencieusement en gentle et journalise l'événement (helper NormalizeScanProfileWithOwnership).

Configuration d'un scan

Côté API, le body POST /v1/scans reflète exactement la struct ScanConfig (source : secuscan-api/internal/domain/models/target.go) :

{
  "targetId": "uuid",
  "scanConfig": {
    "scanProfile": "gentle",
    "scanSubdomains": true,
    "portScan": true,
    "sslCheck": true,
    "vulnScan": true,
    "credentialCheck": true,
    "dnsAudit": true,
    "emailSecurity": true,
    "whoisLookup": true,
    "httpHeaders": true,
    "wafDetection": true,
    "robotsSitemap": true,
    "dnsblCheck": true,
    "serviceAudit": true,
    "dirDiscovery": true,
    "webScreenshot": true,
    "webCrawler": true,
    "typosquatCheck": false,
    "threatIntel": false,
    "dastScan": false,
    "asnCartography": false,
    "dmarcCheck": true,
    "fuzzingEnabled": false,
    "excludedPaths": ["/api/internal", "/admin"],
    "customPorts": [8080, 9090, 9443]
  }
}

Tous les booléens sont à true par défaut sauf dastScan, asnCartography, typosquatCheck, threatIntel, fuzzingEnabled (modules avancés).

Lecture du rapport EASM

Liste des findings

Chaque finding contient :

Posture score par catégorie

Le rapport calcule une posture par grande catégorie (TLS, DNS, HTTP headers, Email auth, Vulnérabilités). Cela permet d'identifier les axes faibles : un score TLS de 45/100 vs un score Email auth de 92/100 indique une priorité claire.

Exploit Chains (Attack Paths)

Le sous-module Attack Path corrèle les findings pour identifier des chaînes d'exploitation réalistes :

[1] Sous-domaine `api-old.monentreprise.com` exposé
  → [2] Service Apache 2.4.49 détecté (CVE-2021-41773)
    → [3] LFI réussie sur /cgi-bin/.%2e/etc/passwd
      → [4] Fuite d'identifiants dans /home/.aws/credentials

Disponible à partir du plan Pro. Cliquez sur l'onglet Attack Paths sur la page d'un scan.

SBOM (Software Bill of Materials)

Détection automatique des stacks technologiques exposées (web servers, frameworks, CMS, librairies front-end). Export en CycloneDX 1.5 depuis Reports → Exporter.

Modules de monitoring continu (EASM Monitors)

Indépendamment des scans ponctuels, le sous-module EASM Monitors (/easm/monitors) surveille en continu :

• Apparition de nouveaux sous-domaines (Certificate Transparency log monitoring via crt.sh)
• Changement de propriétaire WHOIS
• Nouveaux certificats TLS émis
• Modification d'enregistrements DNS critiques (MX, NS, A)
• Apparition de la cible dans une DNSBL

À chaque détection, une notification est émise (email, Slack, webhook) et un finding info/low est créé pour traçabilité.

Quotas par plan

Source : migrations 000027_v1_pricing.up.sql, 000126_fix_pricing_add_essential.up.sql, 000033_update_plan_limits.up.sql.

Scan des cibles partagées (responsible scanning)

Scanyze applique systématiquement les pratiques suivantes :

• User-Agent identifiable : Scanyze/1.0 (https://scanyze.com/scan-info) — un opérateur peut bloquer Scanyze proactivement si nécessaire.
• Rate limit cumulé : un sémaphore HTTP global empêche la saturation du serveur cible.
• Backoff exponentiel : en cas de réponse 429 ou 503, le scan ralentit automatiquement.
• Timeout strict : 30 minutes max par scan complet ; aucun scan n'est laissé tourner indéfiniment.
• Filesystem isolé : aucun upload arbitraire — uniquement des requêtes HTTP/DNS conformes à RFC.

Sources de cette page

• Backend : secuscan-api/internal/scanner/, secuscan-api/internal/services/scanner/, secuscan-api/internal/services/easm/
• Outils : 22 fichiers dans secuscan-api/internal/scanner/tools/
• Modèle : secuscan-api/internal/domain/models/target.go (ScanConfig)

À jour pour Scanyze v0.130.x.