Earthshaker Security Book a scan

← All field notes

Testing practice 13 October 2026 · 9 min read · Caleb

Attack Surface Review: Discovery Every 7 Days Still Needs Human Checks

Learn how an attack surface review connects discovery, asset fields, KEV, MITRE ATT&CK, and SSVC, then pairs automation with human verification.

Hand-drawn security review title card

An attack surface review is a structured process that inventories every system, service, and API an organization exposes, then validates which of those exposures carry real risk. The output is a living asset inventory, a prioritized list of verified findings, and a remediation plan tied to ownership. If you haven't mapped your external footprint in the last quarter, start discovery today or schedule a validated external review.

TL;DR:

  • Run automated external discovery continuously or weekly, and follow CISA’s baseline of asset discovery every 7 days and vulnerability enumeration every 14 days.
  • Prioritize external and API exposures first, then rank validated findings against known exploited vulnerabilities and exploit telemetry before weighing business impact and remediation cost.
  • Use automated scans for breadth, authenticated scans for hidden configuration issues, and manual verification or code review for high risk assets and business logic flaws.
  • Review again immediately after deployments, API launches, acquisitions, or authentication changes; retest fixes and track detection time, repair time, exposure trends, and critical asset coverage.

Table of Contents

What an Attack Surface Review Covers and Which Types to Include

A thorough review treats the attack surface as several overlapping zones, not one list of IP addresses. Each zone has its own typical entry points and failure modes.

  • External: internet-facing servers, forgotten subdomains, and exposed admin panels are common entry points for opportunistic scanning.
  • Internal: flat networks, over-permissioned service accounts, and unpatched internal hosts let an initial foothold spread.
  • Supply-chain and third-party: vendor integrations, SaaS connectors, and shared credentials introduce risk you don't directly control.
  • API: undocumented or deprecated endpoints, weak authentication, and excessive data exposure are frequent findings.
  • OT/ICS: legacy protocols and devices that can't be patched quickly make even passive discovery sensitive.

When resources are limited, address external and API exposure first since these are the paths attackers reach without any prior access, then work inward toward internal and supply-chain risk.

When and How Often to Run an Attack Surface Review

Cadence should match exposure and criticality, not a fixed calendar.

  1. Run automated external discovery continuously or at least regularly for internet-facing assets, since new subdomains and forgotten services can appear between periodic checks.
  2. Run a full authenticated and manual review periodically for high-criticality systems, and less frequently for lower-risk internal assets.
  3. Trigger an immediate re-review after any production deployment, new API launch, merger or acquisition, or change to authentication and session management.
  4. Wire discovery tools into CI/CD pipelines and cloud event streams so new assets are flagged and queued for review automatically, rather than waiting for the next scheduled scan.

CISA guidance recommends automated asset discovery roughly every 7 days and vulnerability enumeration roughly every 14 days as baseline visibility practices, with results feeding into a monitoring dashboard rather than a static report.

Asset Inventory Schema and Classification Fields to Collect

A discovery scan is only useful once its output becomes a structured inventory. Each asset record should capture enough to assign ownership and risk without a second lookup.

  • Identity fields: IP address, hostname, and the system or team that owns the asset.
  • Role and protocol fields: asset type (web server, API gateway, database), exposed protocols and ports, and authentication method.
  • Risk fields: criticality tier, logging and monitoring posture, and last-verified date.

Classify assets by business function and criticality, not just technical type, so a prioritization pass later can weigh a customer-facing payment API differently from an internal wiki. Use consistent naming and ownership conventions so the same asset doesn't get entered twice under different names. A simple network diagram alongside the inventory helps teams visualize exposure, and both the diagram and the records need a scheduled owner, otherwise the inventory goes stale within a few months.

Prioritization Frameworks: KEV, MITRE Mapping, and SSVC Reasoning

Once you have validated findings, the hard part is ranking them.

  • Known exploited vulnerabilities: cross-reference findings against KEV and current CVE exploit telemetry first, since these represent active attacker activity rather than theoretical risk.
  • MITRE ATT&CK mapping: map each exposure to the tactics and techniques it enables, which clarifies the likely attacker path rather than just the flaw's severity score.
  • SSVC or FAIR-style reasoning: weigh exploitability, business impact, and remediation cost together instead of relying on a single CVSS number.

CISA's operational guidance recommends prioritizing assets using known-exploited-vulnerability data and exploit telemetry before applying business-impact reasoning, which shortens the time between discovery and real risk reduction. A prioritization approach built around exploit risk rather than CVSS alone tends to surface the findings attackers actually use first.

Testing Methods: Automation, Authenticated Scans, and Manual Verification

Automated attack surface management tools are fast and good at breadth: they catch open ports, expired certificates, and known CVEs at scale, but they also generate false positives and miss business-logic flaws entirely. Authenticated scans and endpoint-based enumeration go a layer deeper, revealing internal misconfigurations that an unauthenticated scan never sees.

  • Automated ASM: broad, fast, and continuous, but prone to false positives without a human check.
  • Authenticated scans: reach configuration and access issues hidden behind a login.
  • Manual verification and targeted pen tests: confirm which findings are actually exploitable on high-risk assets.
  • Secure code review: catches business-logic and context-specific flaws that scanners can't reason about.

The OWASP Attack Surface Analysis Cheat Sheet frames attack surface analysis and threat modeling as a loop: changes discovered in a review should trigger renewed threat modeling, which then points testers back to the parts of the surface that need deeper manual work. OWASP's secure code review guidance makes the same point about manual review complementing automated SAST and DAST tools rather than replacing them.

Pro Tip: Reserve manual verification and pen testing for the assets your prioritization framework ranks highest, since that effort doesn't scale across every finding.

Remediation Patterns and How to Measure Attack-Surface Reduction

Fixing a finding and proving the fix worked are two different tasks, and both need a defined workflow.

  1. Apply direct controls first: patching, configuration hardening, and closing unnecessary exposed ports or services.
  2. Layer compensating controls where a direct fix isn't immediately possible, such as segmentation, tightened access policies, or a web application firewall rule.
  3. Track KPIs over time: time-to-detect, time-to-fix, the trend in total exposed assets, and the percentage of critical assets covered by the latest review.
  4. Close the loop with a re-test and keep the ticket, report, and re-test result together as evidence for stakeholders and auditors.

NIST SP 800-53 offers a consolidated control catalog worth consulting when mapping remediation steps to specific findings.

How Earthshaker Security Runs an External Attack Surface Review

We run external attack surface reviews by combining automated discovery with manual validation, which reduces false positives that pure automation tends to produce. Our reports detail each validated finding alongside a concrete fix, written so both technical and non-technical audiences can act on it, and every engagement includes a re-test option once the fix is implemented. Internal tooling works well for continuous day-to-day monitoring; a specialist engagement earns its place when you need an outside, hand-verified view before a launch, an audit, or a funding round, which is the gap our external attack surface review fills. Our penetration testing methodology follows the same automation-plus-verification pattern on the application layer.

Four-stage automated and human security review

Practitioner Perspective: Pitfalls and a Quick Checklist

The biggest failure mode isn't missing a tool, it's treating the review as a one-off. Inventories go stale within weeks, and third-party or OT assets get skipped because nobody owns them.

  • Check for new or expired certificates and DNS records across your domains.
  • Re-run a basic external scan and compare it against last quarter's inventory.
  • Confirm every critical asset still has a named owner in change control.

— caleb*

Get a Specialist External Attack Surface Review

Running discovery internally gets you a map. Getting that map validated by someone who hand-checks every finding is what turns it into a remediation plan you can actually act on. Our external attack surface review pairs automated scanning with manual verification, and every report ships with fixes written for both your engineering team and your board.

Earthshaker Security

Check our pricing page or reach out directly to scope a review for your environment.

FAQ

What Is the Difference Between Attack Surface Mapping and a Full Review?

Attack surface mapping is the discovery step: finding and listing every exposed asset. A full attack surface review adds validation, prioritization, and a remediation plan on top of that map.

How Often Should We Run an External Attack Surface Assessment?

Automated external discovery should run continuously or weekly, while a full validated review fits a quarterly cadence for high-criticality systems. Any major deployment, new API, or authentication change should trigger an immediate re-review rather than waiting for the next scheduled cycle, per CISA's visibility guidance.

What Tools Help With Attack Surface Discovery?

Teams typically combine internet-wide scanners, certificate transparency monitoring, DNS enumeration, and cloud or SaaS API connectors to cover external, cloud, and internal assets. No single tool covers every zone, so pairing automated discovery with manual verification produces the most reliable results.

How Do I Prioritize Which Vulnerabilities to Fix First?

Start with anything on known exploited vulnerability lists, since those represent confirmed attacker activity rather than theoretical risk. From there, map exposures to likely attacker techniques and weigh exploitability against business impact and remediation cost before building the fix queue.

Sources

No single discovery method sees the whole attack surface, so most programs combine several.

External scanning finds what's reachable but misses context like asset ownership. Cloud connectors give you ownership and configuration detail but only for assets inside your known accounts. Internal agents close that gap but require deployment effort. Combining all four, refreshed on different cadences, gets you close to continuous coverage without overwhelming any single tool.

A certificate inventory is one of the easier wins here. Tracking issuance and expiry across your domains closes a common blind spot; Otterwatch's certificate inventory playbook walks through building that process for small teams.

Pro Tip: Run external discovery before internal discovery so you know what an outside attacker sees before you start fixing what you can see internally.

Want this run against your app?
Book a scan

Rather have it in your inbox?

We send a note when there is something worth sending. That is a handful of times a year, not a Tuesday newsletter.