What is Attack Surface Management?
Attack surface management (ASM) is the continuous process of discovering, inventorying, and reducing all assets and entry points that an attacker could exploit to gain access to an organisation's systems, data, or funds. It is not a one-time audit; it is an ongoing operational discipline that maintains a living map of an organisation's exposure and ensures that every new asset added to the environment is accounted for, assessed for risk, and managed appropriately.
The term reflects a fundamental security truth: you cannot protect what you do not know you have. An unknown internet-facing server with an unpatched service, a forgotten subdomain pointing to a decommissioned application, a developer's personal GitHub repository containing private keys, a smart contract proxy deployed six months ago and never registered in any inventory: all of these represent real attack surface that an adversary will find, even if the organisation's security team has not.
ASM programmes typically operate across three stages. Discovery is the process of finding all assets, both known and unknown, through automated scanning, passive reconnaissance, and on-chain enumeration. Inventory is the creation and maintenance of a structured asset register that captures ownership, criticality, and exposure. Reduction is the active process of eliminating unnecessary exposure: decommissioning unused services, patching vulnerabilities, revoking stale credentials, and applying security controls to previously ungoverned assets.
The discipline has grown rapidly as a formal practice because the traditional assumption that the perimeter is known and fixed has proven untenable. In Web3, where the attack surface extends onto public blockchains, open-source repositories, and community platforms, that assumption was never valid in the first place.
Why Web3 Attack Surfaces Are Uniquely Complex
A conventional enterprise attack surface is already complex: servers, workstations, cloud infrastructure, SaaS applications, remote access endpoints, and the employees who use them. A Web3 firm's attack surface includes all of that, plus a set of additional components that are structurally different from anything in a traditional IT environment.
Smart contracts are immutable once deployed. A vulnerability in a production smart contract cannot be patched by pushing a code update; it requires a migration to a new contract, with all the governance complexity, user communication, and liquidity migration that entails. This makes the pre-deployment audit critical, but it also means that every deployed contract in a protocol's history represents a permanent, publicly accessible piece of attack surface. Proxy patterns partially address upgradeability, but they introduce their own attack surface through the admin key that controls the upgrade function.
Bridges represent concentrated pools of value accessible through a relatively small number of privileged operations. The Ronin bridge, the Wormhole bridge, the Nomad bridge: each was compromised through different vectors, but in each case the bridge's privileged operations and the keys or contracts controlling them were the critical attack surface. Mapping and monitoring bridge-related contracts and signers is a non-negotiable component of Web3 ASM.
Oracles are the interface between on-chain logic and off-chain data. A compromised or manipulated oracle can cause smart contracts to execute on false data, leading to catastrophic outcomes. Oracle addresses, their update authority, and the data sources they pull from all form part of the attack surface.
RPC endpoints are the network interface through which users and applications interact with the blockchain. Public or insufficiently secured RPC endpoints can be exploited for denial-of-service attacks, used to harvest transaction data, or leveraged to submit malicious transactions in specific attack scenarios.
Hot wallets, multisig signers, and admin keys represent the human layer of the on-chain attack surface. The security of these assets is directly dependent on the security of the devices, credentials, and operational practices of the individuals who hold them. Hardware security modules (HSMs) and hardware wallets raise the bar, but the attack surface still includes the signer's workstation, their credentials, and their susceptibility to social engineering. Our guide to hardware security modules for crypto firms covers key custody controls in detail.
Community channels are a frequently overlooked component of the Web3 attack surface. Discord servers, Telegram groups, and social media accounts are integral to how crypto projects communicate with their users. Compromised Discord accounts have been used to post fraudulent announcements and phishing links that have led to significant user losses. These channels are part of the attack surface and must be governed accordingly.
External vs Internal Attack Surface
Security teams often focus ASM efforts on the external attack surface: the internet-facing assets that an unauthenticated attacker can reach from outside the organisation. This is the right starting point, but the internal attack surface, those assets and pathways accessible only after some form of authentication or insider access, is equally important and often more dangerous.
The external attack surface for a Web3 firm includes internet-facing web applications and APIs, public RPC endpoints, exposed blockchain nodes, domain infrastructure, public GitHub repositories, deployed smart contracts accessible on-chain, and the social media and community accounts the firm operates. All of these can be reached and probed by an attacker without any prior access. Tools such as Shodan, Censys, and SecurityTrails can map much of this automatically.
The internal attack surface includes corporate network infrastructure, internal developer tooling, cloud environments with network-level access controls, internal secret stores and key management systems, and privileged access systems. It also includes the home networks and personal devices of employees with access to sensitive systems.
The LastPass compromise of 2022 is the canonical example of why the internal attack surface boundary extends further than most organisations assume. An attacker compromised a LastPass DevOps engineer's home computer through a vulnerability in a third-party media player, gained access to shared internal credentials stored in that employee's personal LastPass vault, and used those credentials to exfiltrate LastPass's encrypted customer vault data. The organisation's corporate perimeter was never directly breached: the attack entered through an employee's home environment. The lesson is that the attack surface includes every person who can access sensitive systems, and every device and network through which they do so.
For crypto firms, where a single employee holding signing authority over a multisig wallet can represent control over hundreds of millions of dollars, the personal device and home network of every privileged user is in scope for attack surface management. This is not theoretical: the Lazarus Group's approach to targeting crypto firms, documented in our analysis of Lazarus Group's crypto targeting tactics, follows exactly this path.
The Discovery Problem in Crypto
One of the most consistent findings when security teams conduct an initial ASM exercise for a crypto firm is that the organisation does not have a complete picture of its own attack surface. This is not unique to Web3, but it is exacerbated by the pace of development and the distributed nature of how Web3 teams operate.
Crypto development teams move fast. New smart contracts deploy to testnet and mainnet. New third-party APIs integrate without a formal procurement process. Developers spin up cloud instances for testing and forget to decommission them. Multiple wallet addresses accumulate across different team members. GitHub repositories multiply, some private, some inadvertently public, some containing sensitive configuration files or key material.
The on-chain discovery challenge is particularly acute. A protocol that has been operating for two or more years may have dozens of deployed contracts across multiple chains: production contracts, deprecated versions, proxy implementations, governance contracts, fee distributor contracts, and testing artefacts. Not all of these will appear in internal documentation, especially if the team has turned over. An attacker performing reconnaissance will enumerate all of them; the security team should do so first.
Domain infrastructure expands similarly. Subdomains created for marketing campaigns, partner integrations, or internal tooling accumulate over time. Dangling DNS records, pointing to services that have since been decommissioned, are a well-known attack vector: an attacker can claim the decommissioned resource and use the legitimate subdomain to deliver phishing content or malware under the organisation's trusted domain name.
Key ASM Categories for Web3
A structured Web3 ASM programme organises assets into three primary categories, each requiring different discovery methods and management approaches.
On-Chain Assets
The on-chain asset inventory covers all deployed contracts, proxy implementations, admin addresses, multisig wallets, and governance contracts associated with the organisation. This inventory should record the address, chain, deployment date, the deployer address, the current admin or owner address, whether the contract is upgradeable, and the last audit date. It should be maintained as a living document updated with every deployment.
Admin addresses and upgrade keys are the most critical entries in the on-chain asset inventory. These addresses represent the highest-privilege access points in the protocol: compromise of the account controlling them can result in a complete takeover. The security controls applied to these addresses, hardware wallet custody, multisig governance, time-lock delays, should reflect that criticality. Our guide to zero trust security for Web3 covers the principle of least privilege as it applies to on-chain access control.
Off-Chain Infrastructure
The off-chain infrastructure inventory covers blockchain nodes and RPC endpoints, cloud infrastructure (compute instances, storage buckets, managed databases), domain names and DNS configuration, SSL certificate expiry tracking, GitHub and GitLab repositories, and CI/CD pipeline integrations. Each of these should be mapped, ownership should be assigned, and a review cycle should be established to identify and decommission unused or redundant assets.
SSL certificate expiry is a frequently overlooked component. An expired certificate on a production service does not only break user-facing functionality; it can create an opening for a man-in-the-middle attack during the window when users may override browser warnings. Our coverage of man-in-the-middle attacks in crypto explains how these vectors are exploited in practice.
Human Layer
The human layer of the attack surface is the hardest to map and the most frequently underestimated. It encompasses employee credential exposure (leaked credentials from third-party breaches), personal device security posture (particularly for employees with privileged access), social media account security, and the access rights of former employees.
Credential exposure monitoring is a specific, high-value control in this category. Services such as Have I Been Pwned and SpyCloud alert organisations when employee email addresses and associated credentials appear in breach data sets. A compromised credential that is reused on a corporate system, or even on a personal system used for work, represents a direct entry point into the organisation. Monitoring for this continuously, rather than checking periodically, is the correct approach given how quickly breached credentials are operationalised by threat actors.
"The attack surface extends to every person who can access sensitive systems, and every device and network through which they do so. For a crypto firm, that means a signer's home network is in scope."
Continuous Monitoring vs Point-in-Time Scanning
A point-in-time ASM exercise produces a snapshot of the attack surface at the moment of the assessment. It has genuine value: it reveals unknown assets, highlights critical exposures, and provides a baseline against which future states can be compared. But a snapshot becomes stale the day it is completed. A new contract deployed the following week, a new employee granted access to a privileged system the week after, a developer creating a test environment the week after that: none of these appear in the assessment.
Continuous attack surface management maintains an always-current inventory by monitoring for changes on an ongoing basis. This means automated discovery tools running regularly against the organisation's known seed assets (domains, IP ranges, GitHub organisations, deployer addresses) to identify new assets as they appear. It means alerts when a new subdomain resolves for the first time, when a new contract is deployed from a monitored address, when a new repository is created under the organisation's GitHub account, or when a previously private repository becomes public.
The case for continuous monitoring is strongest precisely where crypto firms are most exposed: the rate of change. A DeFi protocol in active development may deploy new contracts weekly. An exchange integrating new chains or assets creates new infrastructure regularly. A team growing from 20 to 60 staff within a year creates dozens of new attack surface entries through onboarding alone, each requiring provisioning, access assignment, and device enrolment.
Point-in-time scanning remains valuable as a periodic deep-dive that complements continuous monitoring. The right model is continuous automated monitoring providing ongoing coverage, with a formal periodic review (quarterly or bi-annually) that applies human judgement to the accumulated inventory to identify patterns, prioritise reduction efforts, and update risk ratings.
Tooling and Implementation
A practical Web3 ASM toolset draws from both established external discovery tools and blockchain-native monitoring capabilities.
Shodan is an internet-wide scanner that indexes internet-connected devices and services. It can be used to identify internet-facing servers, open ports, exposed services, and misconfigured infrastructure associated with an organisation's IP ranges and domains. Shodan's alerting functionality allows teams to be notified when new assets appear in monitored ranges.
Censys offers similar internet-wide asset discovery with stronger certificate transparency integration, making it particularly useful for discovering subdomains through SSL certificate logs. Certificate transparency logs are a reliable and often overlooked source of asset discovery intelligence, as they capture every certificate issued for a domain, including certificates issued for previously unknown subdomains.
SecurityTrails provides DNS history and subdomain enumeration, allowing teams to identify historical DNS records, subdomain relationships, and infrastructure associations that may not be visible through active scanning alone. DNS history is particularly useful for identifying dangling records and understanding the full scope of a domain's infrastructure over time.
Forta and on-chain monitoring platforms provide the equivalent capability for blockchain assets: continuous monitoring of deployed contract activity, admin function calls, and anomalous transaction patterns. Combined with a maintained on-chain asset inventory, these tools provide the detection layer for on-chain ASM.
GitHub security features, including secret scanning and dependency review, address the repository layer of the attack surface. Secret scanning automatically detects credentials, API keys, and other secrets committed to repositories. Dependency review identifies third-party libraries with known vulnerabilities before they are merged into production code.
These tools produce data. The value of that data depends on having a structured asset inventory to receive it, an analyst or automated triage process to review alerts, and a defined process for actioning findings. Tooling without process generates noise. The implementation of ASM tooling should be accompanied by the definition of the inventory schema, the alert routing process, and the remediation workflow.
Integration with the Broader Security Programme
Attack surface management does not operate in isolation. It is the discovery and inventory layer of a broader security programme, and its outputs feed directly into vulnerability management, incident response, and SOC operations.
The relationship with vulnerability management is the most direct. ASM produces the asset inventory that vulnerability management operates against: you cannot scan for vulnerabilities in assets you have not discovered. An ASM programme that continuously updates the asset inventory ensures that the vulnerability management programme covers the complete current attack surface, not just the assets that were known at the last inventory review. Our guide to vulnerability management for Web3 organisations covers the vulnerability management lifecycle in full, and assumes a complete asset inventory as its starting point.
The relationship with incident response is equally important. When an incident occurs, the speed and accuracy of the response depends on having a current and complete understanding of what assets exist, who owns them, and how they connect to one another. An ASM programme that maintains a live asset inventory with ownership assignments dramatically reduces the time spent in the initial triage phase of an incident, when every minute matters. For the broader incident response framework, see our guide to incident response planning for crypto firms.
The relationship with vendor and third-party risk is increasingly significant as Web3 protocols integrate with a growing number of external services: oracle providers, bridge operators, custodians, analytics tools, and infrastructure providers. Each integration creates a new entry point in the attack surface. The vendor risk management process should include an assessment of each integration's attack surface contribution, and the ASM programme should track third-party-adjacent assets. Our guide to vendor risk management for Web3 covers the governance framework for third-party security.
Finally, the connection to privileged access management deserves explicit attention. The highest-risk assets in the on-chain and off-chain inventory are those accessible through privileged credentials: admin keys, signing keys, and infrastructure access credentials. The access controls applied to these assets should reflect their ASM risk rating, and any change to who holds privileged access should trigger an update to both the ASM inventory and the privileged access management records. Our guide to privileged access management for crypto firms covers these controls in detail.
A mature ASM programme is not a product or a tool: it is a practice. It requires ongoing commitment to maintaining the asset inventory, acting on discovered exposures, and integrating ASM outputs into the organisation's broader security decision-making. For firms that have not yet formalised their security programme, ASM is one of the highest-leverage starting points, because knowing what you have is the prerequisite for protecting it.
Frequently Asked Questions
What is attack surface management?
Attack surface management (ASM) is the continuous process of discovering, inventorying, and reducing all assets and entry points that an attacker could exploit. It covers external-facing infrastructure, internal systems, on-chain assets, and the human layer, and must be ongoing rather than point-in-time because the attack surface changes constantly as new assets are deployed, new staff join, and new integrations go live.
Why is the Web3 attack surface uniquely complex?
Web3 firms have an attack surface that spans smart contracts (immutable once deployed), bridges, oracles, RPC endpoints, hot wallets, multisig signers' devices, admin keys, domain infrastructure, GitHub repositories, and community channels such as Discord and Telegram. Many of these assets are public and permanent, meaning a vulnerability in a deployed contract cannot be patched without a full migration process.
What is shadow IT and why is it a problem in Web3?
Shadow IT refers to services, tools, and infrastructure deployed or used by employees without the knowledge or oversight of the security team. In Web3, this commonly includes developer-created test environments, third-party API integrations, cloud storage buckets, and unofficial node deployments. These assets lack security controls and are invisible to the organisation's vulnerability management programme, creating unmonitored exposure.
What is the difference between continuous ASM and point-in-time scanning?
Point-in-time scanning produces a snapshot of the attack surface at the moment of the scan. Continuous attack surface management maintains an always-current inventory by monitoring for new assets, configuration changes, and emerging vulnerabilities on an ongoing basis. In Web3, where new contracts deploy, new employees join, and new third-party integrations go live regularly, continuous monitoring is the only approach that provides meaningful, actionable coverage.
What tools support attack surface management for a crypto firm?
External discovery tools such as Shodan, Censys, and SecurityTrails identify internet-facing assets and infrastructure. On-chain monitoring tools such as Forta and Etherscan alerting cover deployed contracts and admin addresses. Credential exposure monitoring via services such as Have I Been Pwned and SpyCloud covers the human layer. These should be integrated with a central asset inventory and connected to the vulnerability management and incident response programmes.