Catalog
concept#Security#Architecture#Software Engineering

Attack Surface

Concept describing all exposed interfaces, components and processes of a system through which attacks may occur.

Attack surface denotes all exposed interfaces, components, and configurations of a system through which an attacker can gain access or cause harm.
Established
High

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

API gateways and service meshCI/CD pipelines for security scansInventory and CMDB systems

Principles & goals

Minimal attack surface: expose only necessary interfaces.Defense in depth: combine multiple protection layers.Least privilege: grant permissions restrictively.
Discovery
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Undiscovered exposures lead to unaddressed attack vectors.
  • Focusing only on technical interfaces neglects human or process vectors.
  • Wrong prioritisation can divert resources from more critical measures.
  • Apply least-privilege principles for all services.
  • Reduce attack surface via network segmentation.
  • Automate discovery and testing of exposed endpoints.

I/O & resources

  • System and network architecture diagrams
  • API and endpoint inventory
  • Configuration and permission lists
  • Attack surface register with priorities
  • Recommended hardening measures and responsibilities
  • Monitoring and alerting rules

Description

Attack surface denotes all exposed interfaces, components, and configurations of a system through which an attacker can gain access or cause harm. It includes code, APIs, network endpoints, user interfaces, and operational processes. The concept supports risk identification, prioritisation of hardening efforts, and targeted security planning.

  • Reduced attack surface lowers the likelihood of successful attacks.
  • Prioritisation of hardening by focusing on critical exposures.
  • Improved traceability and monitoring of sensitive interfaces.

  • Complete elimination of all attack surfaces is practically impossible.
  • Requires continuous maintenance with changes and deployments.
  • May increase development effort and complexity if implemented too restrictively.

  • Number of exposed endpoints

    Counts publicly or internally reachable interfaces per system.

  • Time to remediate critical exposures

    Average time between discovery and remediation of critical vulnerabilities.

  • Share of automated hardening checks

    Percentage of checks performed automatically.

Securing an API gateway

Reducing exposed endpoints via strict routing and authentication rules.

Isolating a legacy service

Place legacy component behind a reverse proxy and restrictive network rules.

Hardening cloud storage

Avoid public buckets; grant least-privilege permissions.

1

Take inventory: list all interfaces and components.

2

Categorise by exposure and criticality.

3

Define standard hardening measures for endpoint types.

4

Integrate automated scans into CI/CD pipelines.

5

Regular reviews and adjustments after changes.

⚠️ Technical debt & bottlenecks

  • Unclear or missing interface documentation.
  • Manual, non-automated scans and reviews.
  • Legacy components with insecure configuration.
missing inventoryunclear ownershipmanual reviews
  • Only checking externally visible endpoints and missing internal API calls.
  • Assessing attack surface only with blackbox scans.
  • Applying hardening without prioritisation and resource planning.
  • Outdated inventories lead to incorrect risk assessment.
  • Too narrow focus on technology, not on processes and people.
  • Automation without quality control creates blind spots.
Security and threat modellingNetwork and system architecture understandingPractical experience with hardening measures
Minimisation of exposed interfacesAutomatable security checksResilient network segmentation
  • Legacy components with limited modification options
  • Regulatory requirements for availability and logging
  • Resource and budget limits for security measures