Why Point-in-Time Security Assessments Are Not Enough

A penetration test or smart contract audit is valuable. It provides a structured, expert-led review of the security posture at a specific point in time. The problem is that it is only valid for that moment. The day after an audit is published, the protocol may deploy a new contract, onboard a new integration partner, or provision a new cloud environment. None of that is covered.

The gap between assessments is precisely where most successful attacks occur. Sophisticated threat actors do not wait for audit reports. They monitor targets continuously, watching for new deployments, configuration changes, and exposed credentials. A protocol that audits annually or even quarterly is conducting security reviews roughly four times per year. Attackers are conducting reconnaissance 365 days per year.

Continuous Attack Surface Management (CASM) is the ongoing process of discovering, classifying, and monitoring all assets that an attacker could use to gain access to an organisation or its funds. It is not a replacement for penetration testing or smart contract audits. It is the foundation that makes those assessments more effective, and the mechanism that maintains visibility between them.

The distinction matters: attack surface management assessment establishes a baseline; a CASM programme keeps that baseline current as the organisation evolves. For protocols managing real economic value, the period between formal assessments is not a security vacation. It is the period that most requires active monitoring.

The Web3 Attack Surface Is Unique

Web3 organisations have a materially different attack surface from traditional technology firms. Understanding its components is the starting point for any CASM programme.

On-Chain Attack Surface

The on-chain attack surface includes every deployed smart contract associated with the protocol: core logic contracts, governance contracts, treasury wallets, bridge endpoints, and oracle integrations. Each of these is permanently accessible on a public blockchain. Unlike a corporate web application that sits behind a firewall, any deployed contract can be called by any address at any time. There is no perimeter to breach. The code is the attack surface.

This creates a unique CASM challenge: the on-chain attack surface does not diminish over time. Old, deprecated contracts remain deployed and callable. A contract that was considered low-risk at deployment may become high-risk as the protocol's value grows or as new exploit techniques emerge. Every historical deployment must remain in scope.

Off-Chain Attack Surface

Off-chain infrastructure is often the actual point of compromise in high-profile Web3 attacks. This layer includes: APIs and backend services, admin interfaces, RPC nodes, CI/CD pipelines, developer workstations, and cloud infrastructure. These assets are managed and configured by humans, which means they are subject to all the misconfigurations and operational errors that affect traditional IT environments.

A CASM programme must extend beyond blockchain scanning to include the full cloud and network footprint. New subdomains, new open ports, new cloud storage buckets, new API endpoints: each represents an addition to the exposure that needs to be tracked.

Identity and Access Attack Surface

The identity layer is frequently under-inventoried. It includes employee accounts across all platforms (GitHub, cloud consoles, communication tools), API keys and service account credentials, OAuth connections between third-party services, multisig signer identities, and DAO governance participants with elevated permissions. A compromised employee credential has been the initial access vector in a significant proportion of major crypto thefts.

CASM in this layer means maintaining a current, complete record of every identity that has access to any asset of value, and monitoring for changes: new accounts created, permissions escalated, credentials exposed.

Supply Chain Attack Surface

Web3 protocols depend on a broad set of external dependencies: npm packages, Docker images, GitHub Actions workflows, Solidity libraries, third-party price feeds, and external service integrations. Each dependency is an entry point. The supply chain attack surface grows every time a new dependency is added, and changes every time an existing dependency is updated.

Monitoring the supply chain attack surface means tracking which dependencies are in use, watching for known vulnerabilities in those dependencies, and alerting when dependency updates introduce new code that has not been reviewed.

Social and Human Attack Surface

The human attack surface is the most difficult to inventory but among the most exploited. Employees who have public LinkedIn profiles, GitHub commit histories that reveal internal tooling, and participation in public Telegram or Discord servers all contribute to an attacker's reconnaissance capability. Key personnel, including signers, engineers, and executives, can be identified and targeted for social engineering or physical threat.

CASM in this layer focuses on understanding what information about the organisation and its personnel is publicly available, and ensuring that sensitive operational details (signer identities, infrastructure architecture, internal tooling) are not inadvertently disclosed.

Asset Discovery: Finding What You Have

You cannot monitor what you have not found. Asset discovery is the foundational step in any CASM programme, and it consistently reveals assets that the organisation did not know it had.

On-Chain Asset Discovery

Many Web3 teams do not have a complete inventory of their own deployed contracts, particularly protocols that have iterated rapidly through multiple versions. On-chain asset discovery involves monitoring deployer addresses to compile a full list of every contract deployment associated with the protocol, including proxy contracts, factory-deployed instances, and governance contracts. Tools such as Etherscan, Dune Analytics, and blockchain indexing platforms make this tractable at scale.

The output should be a registry of every contract address, its deployment date, the deployer account, the current upgrade state (if applicable), and the economic value it controls or can access. This registry must be updated every time a new deployment occurs.

Off-Chain Asset Discovery

Off-chain discovery covers the external-facing infrastructure: IP ranges, subdomains, cloud account resources, and any service exposed to the internet. Automated tools including Shodan and Censys can identify internet-facing assets associated with an organisation's known IP ranges and domain names. Cloud-native asset inventory tools (AWS Config, GCP Asset Inventory, Azure Resource Graph) provide visibility into cloud resources, including resources provisioned outside of formal change management processes.

Subdomain enumeration is particularly important: new subdomains are routinely provisioned for test environments, staging deployments, or third-party integrations, and are frequently misconfigured or forgotten.

Identity Asset Discovery

Identity asset discovery involves cataloguing all service accounts, API keys, OAuth connections, and privileged identities. This is typically the most poorly maintained inventory in a Web3 organisation. A complete identity asset register should record: every human account with access to production systems, every non-human identity (service account, CI token, API key) with system access, the permissions associated with each identity, and the date of last use.

Stale, over-privileged, or unrecognised identities represent attack surface that grows over time if not actively managed. Security logging and monitoring of identity activity is essential for detecting anomalous access once the inventory is in place.

The Asset Register

The output of asset discovery is an asset register: the Web3 equivalent of a Configuration Management Database (CMDB). It should capture every discovered asset, its classification (critical, high, medium, low based on value and exposure), ownership, and current security status. The asset register is not a one-time deliverable. It is a living document that is updated continuously as new assets are discovered and existing assets change.

Continuous Monitoring by Attack Surface Layer

Discovery establishes what exists. Monitoring tracks how it changes. A CASM programme requires monitoring across every layer of the attack surface.

On-Chain Monitoring

On-chain monitoring watches for unexpected or anomalous activity across all registered contracts and addresses. Key signals include: unexpected transactions to or from treasury addresses, contract upgrade events (particularly proxy upgrades), governance proposals that have not been flagged through normal governance channels, unusual oracle price deviations, and large token movements that may signal a pre-attack position.

Alert thresholds should be calibrated to the specific protocol: a large governance proposal is normal for a mature DAO, but may be anomalous for a protocol with limited governance activity. The goal is not to alert on every transaction but to identify activity that falls outside the expected operational pattern.

External Exposure Monitoring

External exposure monitoring watches the off-chain perimeter for changes: new subdomains going live, new ports opening on known IP ranges, new TLS certificates appearing in certificate transparency logs that may indicate new services, and existing services changing their configuration. Any change to the external-facing attack surface that occurs outside of a documented change management process should trigger an alert and an immediate review.

Credential and Secret Monitoring

Leaked credentials are a primary initial access vector across the industry. Credential monitoring covers three categories: GitHub secret scanning (GitHub's native tooling and third-party tools such as GitGuardian can detect API keys, private keys, and other secrets committed to code repositories), dark web monitoring (credentials from data breaches appearing on marketplaces that may grant access to employee accounts), and real-time alerting on the appearance of organisation-specific API keys or credentials in public locations.

A single leaked private key or API credential can be sufficient for a complete protocol compromise. This monitoring layer has among the highest return on investment of any CASM component.

Vulnerability Feed Monitoring

Tracking CVEs and exploit disclosures against the known technology stack is a fundamental CASM activity. This means monitoring: CVEs affecting the specific versions of software running in the infrastructure, new exploit disclosures for Solidity libraries or third-party protocols that the protocol integrates with, and security advisories from dependency maintainers. The time between a vulnerability disclosure and active exploitation has compressed significantly; rapid identification of relevant CVEs is necessary for timely vulnerability management.

Prioritisation: Not All Attack Surface Is Equal

A mature CASM programme will surface more findings than any team can remediate simultaneously. Effective prioritisation is the mechanism that directs effort towards the highest-risk exposure.

Risk scoring for each asset should combine three factors. First, asset value: does this asset control funds, hold administrative access to systems that control funds, or provide access to other high-value assets? Second, exposure: is this asset internet-facing, publicly callable, or accessible to a broad set of identities? Third, vulnerability likelihood: is there a known vulnerability present, or does the asset have characteristics that make exploitation likely (unpatched software, misconfigured access controls, no authentication)?

The most important analysis in prioritisation is the critical path: what sequence of asset compromises leads from a low-privilege external position to a treasury drain or governance takeover? Assets that appear on that critical path warrant immediate remediation regardless of their individual risk score. An asset that seems low-risk in isolation may be the first step in a multi-stage attack chain.

Prioritisation also means deprioritising. A deprecated test environment with no production access that scores low on all three dimensions can be scheduled for maintenance rather than emergency remediation. The goal is accurate risk ordering, not treating all findings as equally urgent.

Integrating CASM with Existing Security Processes

CASM is not a standalone programme. Its value is amplified when integrated with the security processes that act on its findings.

CASM feeds vulnerability management by providing a current, prioritised list of assets with known vulnerabilities and flagging when new vulnerabilities become relevant to the existing stack. It feeds patch management by identifying which systems are running software versions with known CVEs. It feeds incident response by providing the asset context necessary to understand the scope of a potential compromise: when an alert fires, the incident responder should be able to immediately identify which assets are at risk and which are likely not in scope.

CASM findings also improve the quality of penetration tests. The scope of a penetration test should be informed by the current asset register, not by a static list of systems that was accurate at the time of the last engagement. A CASM-informed penetration test will include newly deployed contracts, recently provisioned cloud assets, and newly created integrations that would otherwise be missed.

From a regulatory perspective, the DORA ICT asset management requirements effectively mandate a CASM-equivalent programme for in-scope financial entities. DORA requires the maintenance of an up-to-date register of all ICT assets and continuous monitoring of the security of those assets. Crypto-asset service providers operating under MiCA with DORA obligations should consider a CASM programme as a compliance requirement, not merely a security best practice.

The attack surface of a Web3 protocol does not pause between audits. Every contract deployment, every new integration, every new employee adds to the exposure. Continuous monitoring is not optional for any protocol that holds real value.

Tooling for Web3 CASM

No single tool covers the full Web3 attack surface. A practical CASM toolset combines traditional external attack surface management platforms with Web3-specific monitoring tools.

Traditional CASM platforms cover the off-chain attack surface. Cortex Xpanse (Palo Alto Networks), Tenable Attack Surface Management, CyCognito, and IONIX each provide automated discovery and monitoring of internet-facing infrastructure, subdomain enumeration, and vulnerability enrichment. These platforms are designed for enterprise IT environments and require configuration to align with a Web3 organisation's specific infrastructure profile.

Web3-specific monitoring tools cover the on-chain attack surface. Forta Network provides a decentralised network of detection bots that monitor on-chain activity for known attack patterns, anomalous transactions, and governance events. Tenderly offers contract monitoring, alerting, and simulation capabilities suited to development and operational teams. Etherscan alert APIs provide a lightweight mechanism for monitoring specific addresses and contract events without requiring custom infrastructure. OpenZeppelin Defender includes monitoring and alerting capabilities integrated with its access control and upgrade management tooling.

Custom monitoring pipelines are a practical necessity for protocols with specific requirements. RPC webhooks and blockchain indexers (The Graph, Subgraph Studio, Alchemy Webhooks) allow teams to build tailored alert logic that fires on protocol-specific conditions that general-purpose tools do not support. For example, monitoring a specific oracle price deviation threshold, or alerting when a governance contract's vote count crosses a threshold that could force-pass a proposal.

Cost and capability scale significantly with organisational maturity. Early-stage protocols can achieve meaningful CASM coverage with open-source tools and Etherscan alerts at minimal cost. Institutional operators or protocols managing significant TVL should invest in commercial CASM platforms combined with dedicated on-chain monitoring. The operational cost of a CASM programme is a small fraction of the potential cost of a successful attack against an unmonitored protocol.

Building a CASM Programme: Where to Start

Many security teams are deterred from CASM because it appears complex to implement. A phased approach makes it tractable regardless of starting point.

Phase 1: Asset Inventory. Before any monitoring is possible, the team must know what it has. This phase focuses entirely on building the asset register: all deployed contracts, all cloud infrastructure, all identity assets, all supply chain dependencies. This is a bounded exercise that can be completed within weeks. The output is a documented, reviewed asset register with initial risk classifications applied.

Phase 2: External Exposure Baselining. With the asset register in place, the team can establish what is visible from an external, attacker perspective. This involves running discovery tools against the known IP ranges, domains, and chain deployer addresses. The output is a baseline of external exposure: what an attacker can see and interact with today. Every asset in the baseline is reviewed for immediate misconfiguration or unintended exposure.

Phase 3: Continuous Monitoring Setup. Once the baseline is established, monitoring is configured to alert on deviations: new assets appearing, existing assets changing, credentials appearing in public locations, new CVEs affecting the known stack. Alerting thresholds are calibrated and response procedures are defined for each alert type. The team should know, before an alert fires, what the response procedure is.

Phase 4: Integration and Response. The final phase embeds CASM into the organisation's existing security processes. Findings from CASM feed the vulnerability management backlog. CASM data is used to scope and prioritise penetration tests. CASM alerts are integrated into the incident response workflow. At this stage, CASM is no longer a project but a programme: a continuous operational activity that keeps security visibility current as the organisation evolves.

For teams that lack the internal resource to operate a CASM programme independently, managed security service providers with Web3 expertise can operate the monitoring infrastructure and triage findings on an ongoing basis. The critical requirement is that the output feeds back into the organisation's own security decision-making, not into a report that sits unread until the next engagement.

Frequently Asked Questions

What is continuous attack surface management (CASM)?

CASM is the ongoing process of discovering, inventorying, and monitoring all assets that an attacker could target, including on-chain contracts, off-chain infrastructure, identity assets, and supply chain dependencies. Unlike periodic assessments, CASM provides continuous visibility as the attack surface changes. It does not replace formal audits or penetration tests but provides the operational foundation between them.

How is CASM different from a penetration test or security audit?

A penetration test or audit is a point-in-time assessment conducted by a specific team within a defined scope. CASM is continuous and automated, focused on maintaining visibility into what exists and how it changes over time. Both are necessary: CASM identifies what to test, and penetration tests validate that the defences are effective. A CASM programme also improves penetration test quality by ensuring that newly deployed assets are included in scope.

What does a Web3 on-chain attack surface include?

All deployed smart contracts associated with the protocol, governance contracts, treasury wallet addresses, bridge interfaces, oracle integrations, and any multisig signers. The on-chain attack surface is unique in that it is permanently accessible and publicly visible. Any attacker can interact with deployed contracts directly without needing to breach a perimeter, which means the on-chain attack surface can only grow over time as new contracts are deployed.

What tools support continuous attack surface management for crypto firms?

Traditional CASM tools (Cortex Xpanse, Tenable ASM) cover the off-chain surface. Web3-specific monitoring tools include Forta Network and Tenderly for on-chain events, Etherscan alert APIs, and custom monitoring pipelines built on blockchain indexers. Most mature protocols use a combination of commercial tools and custom monitoring logic tailored to their specific contract and governance structure.

Does DORA require continuous attack surface management?

DORA's ICT risk management requirements include maintaining an up-to-date register of all ICT assets and monitoring the security of those assets continuously. This effectively mandates a CASM-equivalent programme for in-scope financial entities, including crypto-asset service providers. Organisations subject to DORA should treat CASM as a compliance requirement in addition to a security best practice.