Most crypto firms have had a smart contract audit. Relatively few have a vulnerability management programme. These are not the same thing, and conflating them is one of the most common and consequential gaps in Web3 security practice. An audit tells you what a specific codebase contained at a specific point in time. A VM programme tells you what weaknesses exist across your entire technology stack today, and what new ones have appeared since yesterday.
The attack surface of a modern Web3 organisation extends far beyond the smart contract layer. There are blockchain nodes running software with their own CVE histories, bridge relay components with network-accessible APIs, oracle integrations pulling external data, off-chain order books and matching engines, cloud-hosted APIs, frontend infrastructure, and a dependency graph of open-source libraries, each of which may have a newly disclosed vulnerability this week that was not present last week. A point-in-time audit, however thorough, cannot address any of this on an ongoing basis.
Vulnerability management is the continuous, systematic process of identifying security weaknesses across the full technology stack, assessing their severity and exploitability in context, prioritising remediation based on business risk, implementing fixes, and verifying that remediation was effective. It is a programme, not a project, and it requires ownership, tooling, process, and metrics to function.
1. What Is Vulnerability Management?
Vulnerability management is a formal security discipline with a defined lifecycle. It is distinct from penetration testing, which is a specific assessment activity, and from patch management, which is one part of the remediation stage. VM encompasses the full process of knowing what assets you have, understanding what weaknesses they contain, deciding what to fix and in what order, fixing them, and confirming that the fix worked.
The distinction that matters most for security leaders is between reactive and proactive. Reactive security responds to incidents after they occur. VM is proactive: it systematically identifies the weaknesses that could lead to an incident before an attacker finds and exploits them. In a domain where a single successful exploit can mean the loss of hundreds of millions of dollars in irreversible transactions, the business case for proactive VM is straightforward.
VM sits at the intersection of all three dimensions of the People, Process, Technology framework. The technology component covers the scanning tools, vulnerability databases, and monitoring platforms. The process component covers the cadence of scanning, the criteria for prioritisation, the SLAs for remediation, and the verification procedures. The people component covers who owns the programme, who is accountable for remediation in each team, and how findings are communicated across engineering and security.
A VM programme that has excellent technology but no process ownership will accumulate open findings. A programme that has clear process but inadequate tooling will miss entire categories of vulnerability. A programme that has both but no clear accountability in the engineering teams that must implement fixes will see SLAs consistently missed. All three dimensions must be addressed for the programme to function.
2. Why Crypto Firms Face a Unique VM Challenge
The properties of Web3 organisations create several VM challenges that do not exist in the same form in traditional financial services or software companies.
Smart contracts cannot be patched once deployed. In traditional software, a discovered vulnerability triggers a patch, a deployment, and a fix. A vulnerability discovered in an already-deployed smart contract with immutable logic has no equivalent remedy. The options are to accept the risk, to migrate users to a new contract version, or to trigger an emergency pause if the contract supports it. This means the pre-deployment review process, including audits, formal verification, and SAST scanning, must be substantially more rigorous than in patched-software environments. VM for deployed contracts is about monitoring for signs of exploitation rather than remediation of the code itself.
The dependency graph is broad and changes rapidly. A typical DeFi protocol depends on blockchain node software, oracle networks, multiple external contract integrations, bridge interfaces, keeper networks, and a wide range of off-chain infrastructure components. Each dependency has its own vulnerability history and release cycle. A critical CVE in a widely used smart contract library, an oracle protocol, or a node client can affect dozens of protocols simultaneously. Tracking this dependency graph and monitoring for new CVEs requires systematic tooling.
Multi-chain infrastructure multiplies the scope. Firms deploying on multiple chains, as most serious DeFi protocols do, must maintain a VM programme that covers each chain's native node software, bridge infrastructure, and chain-specific tooling. A vulnerability in an Ethereum execution client is a different CVE to one in a Solana validator client, but both are relevant to a multi-chain operator and both require monitoring and response processes.
Transactions are irreversible and immediate. In traditional finance, there are fraud detection systems, settlement delays, and reversal mechanisms that provide windows for intervention between a vulnerability being exploited and funds leaving the institution permanently. In crypto, a successful exploit that triggers a transaction is settled in seconds and cannot be reversed. This dramatically increases the value of prevention and early detection relative to post-incident response.
Speed culture deprioritises security process. The pressure on crypto development teams to ship and iterate quickly creates organisational resistance to the overhead of a formal VM programme. Security debt accumulates faster than in more regulated industries because the feedback loop, an audit or regulatory inspection, may come months or years later. By that time, the attack surface may have grown substantially.
3. Smart Contract Audit vs Continuous Vulnerability Management
The smart contract audit is the security control that most crypto firms have invested in. For many, it is the only structured security process in place. Understanding its limitations is the starting point for building a more complete programme.
A smart contract audit is a point-in-time review. A team of security researchers reviews a specific version of a specific codebase, identifies vulnerabilities according to their methodology, and produces a report. The report reflects the state of that code at that moment. It does not cover new code merged after the audit, updated dependencies introduced during or after the audit, the off-chain infrastructure that interacts with the contract, the operational procedures of the team deploying and operating the contract, or new vulnerability classes discovered in the research community after the audit date.
"The most dangerous assumption in Web3 security is that a clean audit report means a secure system. The audit was of the code. The attack surface is the organisation."
This is not an argument against audits. Audits are a necessary and valuable part of pre-deployment security. It is an argument for understanding that the audit addresses one layer of the attack surface for a limited time window, and that continuous VM is required to address everything else.
The practical gap this creates is significant. A protocol with a thorough audit report may be running on an Ethereum node client with a known critical CVE because nobody is monitoring for new node software vulnerabilities. Its backend API may be deployed on a cloud instance running an unpatched Linux kernel. Its admin multisig may be controlled via a browser extension wallet on a developer's laptop that last received a security update six months ago. None of these would appear in a smart contract audit. All of them are real attack vectors.
For context on what a comprehensive blockchain security audit covers, including the scope that goes beyond smart contracts, see our dedicated guide on the topic.
4. The Five-Stage VM Cycle for Web3
The VM lifecycle follows a consistent five-stage structure, adapted here for the specific characteristics of Web3 organisations.
Stage 1: Discovery
Discovery is the process of maintaining an accurate and complete inventory of all assets that need to be included in the VM programme. For a Web3 organisation, this includes smart contracts across all chains and all versions, blockchain node software and versions, bridge and oracle integration components, off-chain backend services and APIs, cloud infrastructure, developer workstations and CI/CD pipelines, and third-party dependencies in both on-chain and off-chain code.
Asset inventory is the foundation of VM and the stage most commonly neglected. An organisation cannot manage vulnerabilities in assets it does not know about. Many crypto breaches have involved vulnerabilities in forgotten or poorly documented infrastructure: a staging environment left exposed, a deprecated API endpoint still accepting production traffic, an old admin interface not included in the scope of any security review.
Asset discovery should be automated where possible. Cloud asset inventory tools, network scanning, and dependency graph analysis can surface assets that are not in any manually maintained register. The output should be a living inventory, updated continuously as new deployments are made.
Stage 2: Assessment
Assessment is the process of identifying vulnerabilities in the discovered assets. For infrastructure, this means running authenticated vulnerability scans using tools such as Nessus or Qualys against all servers, cloud instances, and network devices. For code, it means running SAST tools against smart contract and application source code. For dependencies, it means monitoring CVE databases and dependency scanning outputs for newly disclosed vulnerabilities in libraries and frameworks used by the organisation. For deployed contracts, it means monitoring on-chain activity and known vulnerability databases for issues affecting contracts in the same category.
Assessment should run on a defined schedule, with continuous monitoring for newly disclosed CVEs supplementing periodic deep scans. A critical CVE in a widely deployed library may be published on a Tuesday; an organisation that runs scans only monthly will be exposed for weeks before it is detected.
Stage 3: Prioritisation
Prioritisation is the process of determining which vulnerabilities to address first, given that there will always be more findings than can be remediated simultaneously. Raw CVSS scores provide a starting point but are insufficient for crypto environments without contextual adjustment. The relevant factors include the CVSS base score, the exploitability of the vulnerability in the current configuration, the value at risk on the affected system, whether public exploit code is available, whether the vulnerability is being actively exploited in the wild, and the difficulty of remediation for this specific system.
A medium-severity CVE affecting a signing node that controls a large hot wallet should be treated as a critical finding because of the value at risk. The same CVE on a read-only analytics service might be low priority. Context-aware prioritisation requires that the VM programme has accurate asset criticality classifications as an input.
Stage 4: Remediation
Remediation is the implementation of fixes, which may include patching software, updating dependencies, changing configuration, adding compensating controls, or decommissioning affected systems. For smart contracts, where patching is not possible, remediation may mean deploying a new contract version, updating upgradeability settings, or adjusting operational procedures to reduce exposure.
Remediation SLAs should be defined for each severity level. A widely adopted baseline: critical vulnerabilities within 24 to 72 hours, high severity within two weeks, medium severity within 30 days, low severity within 90 days. These timelines must be adjusted for the specific risk profile of the organisation and the systems involved. The SLAs should be agreed between the security function and the engineering and operations teams that will implement fixes, and tracked against consistently.
Stage 5: Verification
Verification confirms that the remediation was implemented correctly and that the vulnerability has been resolved. This is not optional. Incomplete patches, configuration changes that did not apply as expected, and dependency updates that introduced new vulnerabilities through transitive dependencies are all common. Verification should include a re-scan of the affected system after remediation, a manual check for complex or high-severity findings, and closure of the finding in the VM tracking system only once verification is complete.
5. Vulnerability Sources in Crypto Infrastructure
Understanding the specific sources of vulnerabilities in crypto infrastructure is essential for designing a scanning and monitoring programme that provides genuine coverage.
Node Software CVEs
Blockchain node clients have their own CVE histories and release cycles. Geth, the dominant Ethereum execution client, has had multiple high-severity vulnerabilities over its history, including consensus-critical bugs that could cause node operators to fork from the main chain. Besu, Nethermind, and other clients have similar histories. Solana's validator software has had vulnerabilities that required emergency patches with minimal public disclosure to avoid exploitation before the majority of validators could update.
Node software vulnerabilities are particularly significant for exchange and custody operators running their own nodes. A compromised node can be used to serve false balance information, delay transaction relay, or in extreme cases manipulate what transactions the operator broadcasts to the network. Monitoring for node client CVEs and having a rapid patching procedure for critical node software vulnerabilities is a core component of exchange VM.
Bridge and Relay Components
Cross-chain bridge infrastructure combines smart contract risk with off-chain relay risk. The relay components, the software that monitors events on one chain and triggers actions on another, are typically off-chain processes with network-accessible APIs, authentication systems, and key management requirements. These off-chain components have their own vulnerability surface distinct from the smart contracts they interact with, and they are rarely included in smart contract audits. The $625 million Ronin bridge exploit and the $325 million Wormhole exploit both illustrate the catastrophic consequences of bridge security failures.
Oracle Integrations
On-chain oracle integrations such as Chainlink feeds, Pyth price data, and custom oracle solutions represent a trust dependency in smart contract logic. Vulnerabilities in oracle update mechanisms, price manipulation through flash loans, and oracle data staleness during network congestion are all vulnerability categories that require specific monitoring. A protocol's smart contract may have zero vulnerabilities in isolation but still be exploitable through an oracle manipulation if the integration is not correctly hardened.
Off-Chain Infrastructure
The off-chain infrastructure of a Web3 organisation, including cloud-hosted APIs, order book engines, user authentication services, admin interfaces, and monitoring dashboards, is subject to the full range of web application and infrastructure vulnerabilities: SQL injection, SSRF, authentication bypass, privilege escalation, and misconfigurations. These systems frequently have privileged access to on-chain functions through signing keys and admin roles. A vulnerability in an off-chain admin API that grants access to a signing key is as serious as a smart contract vulnerability, and is far more likely to be present given the generally lower security standards applied to off-chain development in Web3 firms.
Third-Party Dependencies
Dependency risk applies to both smart contract libraries, such as OpenZeppelin contracts and Solmate, and off-chain dependencies, such as web frameworks, authentication libraries, and cryptographic implementations. Newly disclosed CVEs in widely used libraries can affect dozens of crypto protocols simultaneously. Dependency scanning tools such as Snyk, Dependabot, and OWASP Dependency-Check should be integrated into the CI/CD pipeline with automated alerts on newly disclosed CVEs in tracked dependencies.
For a broader view of how third-party risk connects to the overall security programme, see our guide on Vendor Risk Management in Web3: Managing Third-Party Security Risk.
6. CVSS Scoring in a Crypto Context
The Common Vulnerability Scoring System (CVSS) provides a standardised numerical score for vulnerabilities based on characteristics including attack vector, attack complexity, required privileges, user interaction, and impact on confidentiality, integrity, and availability. Scores range from 0 to 10, with categories: Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0).
CVSS base scores are a starting point for prioritisation, not a final answer. The CVSS scoring system does not account for the specific value at risk in the target environment, and this is nowhere more significant than in crypto. A CVSS 6.5 medium-severity vulnerability in a general enterprise context might affect a database holding sensitive but replaceable business data. The same vulnerability on a signing node with access to a hundred million dollar hot wallet demands a very different response.
A crypto-adapted prioritisation model should supplement the CVSS base score with three additional factors.
Asset criticality: What is the value at risk if this system is compromised? A signing node, a validator, or a bridge relay has high asset criticality. A development workstation with no access to production keys has lower criticality, though it may be a stepping stone in a lateral movement chain, as the Bybit compromise demonstrated. Asset criticality classifications should be maintained in the asset inventory and applied to all findings.
Exploit availability: Is public proof-of-concept exploit code available? Is the vulnerability already being actively exploited in the wild? CISA's Known Exploited Vulnerabilities catalogue is the definitive source for the latter. A medium-severity CVE with a public exploit that is being actively used by threat actors warrants faster response than a critical theoretical vulnerability with no known exploit.
Compensating controls: Do existing controls reduce the effective risk of this vulnerability? A vulnerability that requires network access to a system that is air-gapped or behind strict firewall rules has lower effective risk than the same vulnerability on an internet-facing service. Compensating controls should be documented and accounted for in prioritisation, but should not substitute for patching where patching is feasible.
7. Tooling and Scanning Approach
No single tool provides complete vulnerability coverage for a Web3 organisation. An effective VM programme requires a layered tooling approach across four categories.
Infrastructure Scanning
Infrastructure vulnerability scanners assess servers, cloud instances, network devices, and operating systems for known CVEs, misconfigurations, and weak settings. Tenable Nessus and Qualys VMDR are the market leaders, both providing comprehensive CVE coverage, authenticated scanning for accurate results on managed systems, and integration with ticketing systems for remediation workflow. Scanning should be configured to run on all cloud instances, physical servers, and network devices on a regular cadence, with continuous monitoring for newly disclosed critical CVEs triggering out-of-cycle scans of affected system classes.
SAST and Smart Contract Analysis
Static application security testing tools analyse source code without execution, identifying common vulnerability patterns. For Solidity smart contracts, Slither is the most widely used open-source static analyser, detecting reentrancy, integer overflow, access control issues, and dozens of other vulnerability classes. Mythril and Semgrep with blockchain-specific rule sets provide complementary coverage. These tools should be integrated into the CI/CD pipeline so that every code commit triggers automated analysis and blocking rules prevent deployment of code with unreviewed high-severity findings.
For off-chain application code, Semgrep, CodeQL, and Snyk Code provide SAST capabilities across common languages including Python, JavaScript, Go, and Rust. The off-chain code layer is frequently underscanned in crypto organisations because the focus is on smart contracts, but it carries equivalent risk given its access to signing keys and admin functions.
Dependency Scanning
Dependency scanners track the libraries and packages used by both smart contract and off-chain code, monitoring CVE databases for newly disclosed vulnerabilities. Snyk and Dependabot integrate directly with GitHub and other source control platforms, generating automated pull requests when vulnerable dependencies are updated. The OWASP Dependency-Check tool provides similar functionality for teams requiring a self-hosted solution. Dependency scanning is particularly valuable because it operates continuously: a new CVE published today in a library you have been using for two years will trigger an alert without requiring any human action.
On-Chain Monitoring
On-chain monitoring platforms such as Forta, Tenderly, and OpenZeppelin Defender provide real-time alerts on anomalous contract behaviour. This is the detection layer for vulnerabilities in deployed smart contracts that cannot be patched: if an attacker begins probing a reentrancy vulnerability or accumulates a position preparatory to a flash loan attack, on-chain monitoring can detect the pattern and trigger an alert before the full exploit completes. Forta's network of detection bots covers a wide range of attack patterns across multiple chains. Custom alert rules can be configured for protocol-specific behaviour thresholds.
8. Bug Bounty Programmes as a VM Layer
A bug bounty programme incentivises external security researchers to identify and responsibly disclose vulnerabilities in your systems in exchange for financial rewards. Well-managed programmes on platforms such as Immunefi, HackerOne, and Bugcrowd can surface vulnerabilities that internal scanning misses, particularly complex logic vulnerabilities in smart contracts that require creative adversarial thinking to identify.
Immunefi has become the dominant bug bounty platform for DeFi, with protocols such as Uniswap, Aave, and MakerDAO running multi-million dollar bounty programmes. The platform reported over $100 million in bounty payouts by 2024, covering vulnerabilities that, if exploited rather than disclosed, would likely have resulted in total losses many times that figure.
However, bug bounty programmes are not a substitute for internal VM. The key distinctions are scope, coverage, and proactivity. Bug bounty programmes cover what researchers choose to look at, not necessarily what your highest-risk systems are. They provide no systematic coverage of infrastructure CVEs, dependency vulnerabilities, or misconfigurations. They are reactive: a researcher must choose your programme, discover a vulnerability, and then choose to disclose it rather than exploit it or sell it. Internal VM runs proactively against all assets on a defined schedule.
The two approaches are complementary. A robust internal VM programme reduces the number of vulnerabilities that external researchers could find, raising the quality of findings in your bug bounty programme and reducing your exposure to undiscovered critical vulnerabilities. A bug bounty programme provides an additional research layer that systematically challenges your internal assumptions about where vulnerabilities might exist.
9. Metrics and Reporting
A VM programme without metrics is not a programme. Metrics create accountability, identify where the process is breaking down, and provide the evidence base for board and regulatory reporting. The following four metrics are the minimum required for a functional programme.
Mean Time to Detect (MTTD): The average time between a vulnerability being publicly disclosed or technically present and the VM programme identifying it. MTTD measures the effectiveness of the discovery and assessment stages. A high MTTD means the organisation is operating with a large window of exposure between when a vulnerability is known to exist and when the organisation is aware of it. Target MTTDs for critical vulnerabilities should be measured in hours, not days.
Mean Time to Remediate (MTTR): The average time between a vulnerability being identified and a verified fix being in production. MTTR measures the effectiveness of the remediation and verification stages. High MTTR relative to SLA targets indicates either that the engineering teams do not have capacity to address findings promptly, that the remediation process has unnecessary friction, or that the prioritisation model is not correctly identifying the most important findings. Track MTTR separately for each severity level.
Open Critical and High Vulnerability Count: The number of unresolved critical and high severity findings at any given point in time. This is the clearest snapshot of current exposure and the metric most useful for executive reporting. A rising count indicates that new findings are arriving faster than remediation is closing them. A target of zero open critical vulnerabilities, with defined SLA acceptance thresholds for high, should be the programme goal.
SLA Compliance Rate: The percentage of findings remediated within the defined SLA for each severity level. SLA compliance is the output metric that ties together all other VM programme activities. Consistent SLA breaches indicate a systemic problem in the programme: inadequate tooling, insufficient engineering resource, unclear ownership, or SLAs that are not realistic for the organisation. SLA compliance should be reported monthly to the security leadership team and quarterly to the board or its risk committee.
These metrics should feed into the security reporting that connects the VM programme to the incident response and crisis management framework. A finding that breaches SLA thresholds and remains unresolved should trigger an escalation process analogous to the early stages of an incident response.
10. Regulatory Requirements
The regulatory landscape for vulnerability management in financial services is becoming more prescriptive, and crypto firms under EU jurisdiction are now subject to specific and enforceable requirements.
DORA Article 25: ICT Vulnerability Management
The Digital Operational Resilience Act's Article 25 establishes explicit requirements for ICT vulnerability management. Financial entities must implement a process for the detection, identification, classification, and treatment of ICT vulnerabilities. This process must include vulnerability scanning, patch management, and verification of remediation effectiveness. The associated regulatory technical standards, adopted by the European Supervisory Authorities, specify requirements for the timeframes in which critical vulnerabilities must be addressed and the documentation that must be maintained as evidence of compliance.
DORA's requirements are not satisfied by an annual penetration test or a pre-deployment audit. They require an ongoing, systematic process with documented procedures, defined SLAs, and demonstrable execution. For crypto firms operating as CASPs, crypto exchanges, or DeFi infrastructure providers in scope of DORA, building and documenting a compliant VM programme is a regulatory necessity, not merely a best practice. See our comprehensive DORA Compliance guide for Web3 firms for the full obligations.
MiCA Technical Standards
MiCA's regulatory technical standards on operational resilience reference requirements for the management of ICT risks including vulnerability identification and treatment. CASPs seeking and maintaining MiCA authorisation will be expected to demonstrate VM programme capability as part of their supervisory examination. The MiCA Compliance requirements for crypto firms include operational resilience obligations that align with a structured VM programme.
ISO 27001 and SOC 2 Type II
ISO 27001 Annex A Control 8.8 (Management of Technical Vulnerabilities) requires organisations to obtain timely information about technical vulnerabilities, evaluate the organisation's exposure to such vulnerabilities, and take appropriate measures. SOC 2 Type II audits under the Common Criteria (CC7.1) require evidence of ongoing vulnerability identification and remediation processes. Both frameworks require documented VM procedures, evidence of scanning activity, and records of remediation actions. For firms pursuing either certification, a well-documented VM programme provides direct evidence for multiple controls.
The connection between VM findings and security incidents is direct. A VM programme that identifies and remediates critical vulnerabilities before they are exploited is indistinguishable from incident prevention. For the processes that must be in place once a vulnerability is being actively exploited, see our guide on security incident response and the human-layer controls that reduce the success rate of attacks against operational vulnerabilities.
Frequently Asked Questions
What is the difference between a smart contract audit and vulnerability management?
A smart contract audit is a point-in-time review of a specific codebase, designed to identify vulnerabilities before deployment. Vulnerability management is an ongoing, continuous process applied to the entire technology stack: smart contracts, node software, APIs, cloud infrastructure, and third-party dependencies. Audits are an important input to a VM programme but cannot substitute for it. New vulnerabilities emerge continuously, including in code that has previously been audited and deployed.
How should a crypto firm prioritise vulnerabilities when many are discovered at once?
Start from CVSS base scores but adjust for crypto-specific context. A medium-severity infrastructure CVE affecting a signing node may warrant critical-level response because of the value it could expose. Assess exploitability, the value at risk on the affected system, whether public exploit code is available, and whether the vulnerability is already being actively exploited in the wild. Signing infrastructure, validator nodes, and bridge relay components should be treated with elevated priority regardless of raw CVSS score.
What does DORA Article 25 require for vulnerability management?
DORA Article 25 requires financial entities to have an ICT vulnerability management process that covers the detection, identification, classification, and treatment of ICT vulnerabilities. The process must include vulnerability scanning and assessment, patch management, and verification that remediation has been effective. Firms must document their VM processes and demonstrate compliance through their ICT risk management framework. The associated regulatory technical standards specify requirements for the timeframes within which critical vulnerabilities must be remediated.
Can a bug bounty programme replace an internal vulnerability management process?
No. A bug bounty programme is a valuable additional layer that incentivises external researchers to identify vulnerabilities, but it does not substitute for an internal VM process. Bug bounties are reactive and depend on researchers choosing to target your systems; an internal VM programme proactively scans all assets on a defined schedule. Bug bounties also do not cover internal infrastructure, are not effective for newly disclosed CVEs in dependencies, and provide no coverage for the off-chain systems that represent the majority of crypto attack surface.
What scanning tools are most relevant for a Web3 organisation?
Infrastructure scanning with Nessus or Qualys should cover all servers, cloud instances, and network devices. Dependency scanning with Snyk or Dependabot should run on all code repositories and trigger alerts on newly disclosed CVEs. SAST tools such as Slither or Semgrep should be integrated into the CI/CD pipeline for smart contract and application code. On-chain monitoring with Forta or Tenderly can detect anomalous transaction patterns that may indicate an active exploit. No single tool provides complete coverage; a layered approach across all these categories is required.
What metrics should a Web3 CISO track for vulnerability management performance?
The four most important metrics are mean time to detect (MTTD), mean time to remediate (MTTR), the number of open critical and high vulnerabilities, and SLA compliance rate. MTTD measures how quickly new vulnerabilities are identified after disclosure. MTTR measures how quickly they are resolved after identification. Open critical counts provide a snapshot of current exposure. SLA compliance tracks whether remediation targets are being met consistently. These four metrics together provide a reliable view of VM programme health and are the basis for executive and board reporting.