Skip to main content

EASM — External Attack Surface Management

EASM is the first module of the Scanners platform. It discovers what an organization exposes to the internet, turns those observations into prioritized Findings and remediation Tasks, and serves them over an authenticated API that a UI (or your customers' portal) consumes.

Live in production (2026-06-10). The Scanners platform is deployed in AWS eu-north-1 (Stockholm) and serving the live REST API at https://modules.binarynetworks.ai/api/v1 (OpenAPI/Swagger at /docs). See Production Deployment for the as-built architecture.

Non-intrusive by design. EASM observes and infers; it sends no exploit payloads. Active, payload-based testing is the job of the separate DAST module.

What it does​

  1. Discover — from the organization's domains, enumerate subdomains, resolve addresses, identify live web services and exposed sensitive ports.
  2. Enrich — correlate against exposure data, IP reputation, and public vulnerability and end-of-life data.
  3. Finalize — one deterministic pass classifies each observation (inventory / expected / should-not-be-public / issue), computes severity with a recorded provenance chain, guards against attributing third-party infrastructure, validates exposed secrets, de-duplicates, and attaches a plain-language description, risk, and four remediation steps.
  4. Serve — results, progress, and a feedback loop are exposed through the public API.

What makes a finding trustworthy​

  • Computed severity, not copied — CVSS base, raised for actively-exploited (CISA KEV) or high exploit-probability (EPSS) issues, lowered for shared or third-party infrastructure, with every step recorded.
  • Every finding is explained — a finding-specific description, the risk, and exactly four remediation steps. Non-CVE detections draw on a curated knowledge base of ~2,460 per-template entries; CVEs draw their description and fixed version from the NVD. A must-map guard ensures nothing ever ships with vague filler.
  • Noise control — technology fingerprints are inventory (hidden by default), secret false positives are filtered deterministically, and duplicate detections are merged.

The feedback loop​

Customers answer findings (false positive, accepted risk, in progress, resolved). On the next full scan the engine reconciles those answers against reality and reports the outcome: confirmed fixed, regressed, still open, newly found. This is how a rescan validates the customer's feedback.

  • Architecture — how the platform is built (multi-tenancy, the scanner contract, the pipeline, the finalization pass), with diagrams.
  • Implementation Reference — the deep detail (config, scanners, ports, knowledge base, secret validator, data model).
  • API Overview / Reference / Usage Guide — how to integrate from your UI.