Vulnerability Management as a Service: What to Buy and How to Vet a Provider

Consider a hypothetical scenario. A mid-sized online marketplace signs a vulnerability management as a service contract after a convincing demo: a tidy portal, severity charts, an integration with the ticket tracker. Three months later the picture looks different. Every week the developers receive an export running to hundreds of rows, and a noticeable share of it is duplicates of a single problem across different hosts. The CTO asks whether the company is any more secure, and nobody can answer, because the portal shows a count of findings rather than a change in risk. A staging subdomain spun up six months earlier for a partner never made it into monitoring, because nobody onboarded it. And one "closed" critical vulnerability was never actually fixed: an administrator simply blocked the scanner's IP addresses, and the rescan reported "not detected".

This is an invented story, not a description of a real client. But each episode in it follows from decisions that are made, or not made, before the contract is signed: what is in scope, who onboards new assets, how a confirmed finding is told apart from scanner noise, what counts as evidence of a fix, and who ultimately accepts the risk.

Vulnerability management as a service (VMaaS) covers different contract models. In the target model used here, an external provider is responsible for agreed parts of a recurring cycle: discovering and validating weaknesses, prioritizing them, supporting or performing remediation where the contract delegates it, and retesting fixes. Below we look at what that cycle consists of, how to describe it in the language of open standards, how to tell a process apart from a dashboard subscription, and how to build a pilot that will show the difference on your own systems.

What You Actually Buy Under the VMaaS Label

Very different things are sold under the same sign: from a subscription to a cloud scanner with a monthly PDF to a service in which the provider maintains the inventory, manually confirms findings and retests fixes. The name guarantees nothing, so it is more useful to define the service by its outcomes rather than its tools.

Platform Versus Process

Access to a platform is the ability to look at data. A process assigns owners and checks for validating the data, identifying coverage gaps and turning the results into action; it does not make the data automatically correct or complete. If new assets never reach the platform, nobody confirms findings, and the "fixed" status is set because a signal disappeared, the customer gets a beautiful visualization of an incomplete picture. In a demo, the question to ask is not "what can the portal do" but "who performs each operation the portal displays, and within what time".

The Loop That Has to Close

NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, aims to help organizations plan and conduct technical tests, analyze the results and develop risk mitigation strategies. Formally, the publication describes assessment in three phases: planning, execution and post-execution, the last of which covers analysis, reporting and mitigation recommendations. It also states that it is not a comprehensive testing program. A managed service turns this one-off sequence into a repeating loop; that is an editorial adaptation, not a requirement of the document. A service that only forwards raw scanner output covers one link out of several.

1. Asset onboardingThe asset is in the inventory, with an internal owner, written authorization and clear testing boundaries.
2. DiscoveryScanning provides breadth of coverage; manual testing provides depth where logic and access rights matter.
3. Triage and priorityThe finding is confirmed, duplicates removed, and priority reflects severity, exploitation data and the asset's role.
4. RemediationThe owner fixes the cause, and a recurring weakness class is fed back into the development process.
5. RetestThe same scenario is repeated under agreed conditions; the result and its limits are recorded.

The NIST Cybersecurity Framework 2.0 takes a wider view: its goal is to help organizations understand cyber risk and manage it better. From that angle, VMaaS is part of risk management, not a periodic report. A good service shows which assets are affected, which weaknesses matter, which fixes are overdue and whether exposure to attack has gone down.

Asset Onboarding and Scope: Where a Service Loses Touch With Reality

No provider will test what it does not know about. So the first thing to discuss is not the scanner but the asset onboarding procedure. Who adds a new service, domain or cloud account to the inventory? How does the provider learn that a team has shipped a new API or moved to another cloud region? What happens to assets the provider discovered itself that are not in the contract: does testing start, or are they first agreed with the customer? The answers determine whether the service's scope will still match the real attack surface six months in.

It helps to separate two kinds of scope. Contractual scope is what the provider is entitled to test. The actual surface is everything an attacker can reach, including forgotten subdomains, staging environments and contractors' services. Regular reconnaissance of the external perimeter can reduce this gap, but it does not guarantee a complete inventory; we covered how to run it and how to prioritize such findings in our piece on external attack surface assessment. But discovering an unknown asset is a reason for a decision, not an automatic permission to test it.

The customer has to confirm that it is entitled to authorize testing of each asset. This matters especially for components hosted by cloud and SaaS providers: many have their own testing rules, and some kinds of testing require their consent. Every onboarded asset needs an internal owner who will receive the finding, decide what to do with it and answer for the deadline.

Who Owns What: Roles and Service Level Agreements

Outsourcing transfers work, not accountability. CSF 2.0 starts from the premise that an organization manages its own cyber risk: the decision to accept a risk, postpone a fix or decommission a system stays with the customer, even when a contractor runs discovery and testing. That is worth writing into the contract explicitly; otherwise a convenient grey zone appears in which a finding has been "handed over" but nobody has accepted it.

The same logic applies to service level agreements (SLAs). There is no universal VMaaS remediation deadline: applicable contracts, regulations or program rules may set one, while an internal target also depends on asset exposure, exploitation data and team capacity. The SLA should describe the responsibilities the provider actually accepts: time from discovery to confirmation and prioritization, response to a retest request, urgent notification when there are signs of active exploitation, and remediation itself if the contract delegates that work. Other remediation actions and risk acceptance remain with the named customer owners.

Below is a comparison of the models buyers usually choose between. It is not a ranking: each model fits its own conditions, and they are often combined.

Standards as Scope Language, Not a Badge

In VMaaS, open standards are useful not as a quality mark but as a way to make scope and results comparable. Each source has its own role, and mixing them up is a common reason for vague contracts.

The OWASP Top 10 is an awareness document about the most critical web application security risks. In its 2025 edition it remains a convenient shared vocabulary for reports, but it is not a testing specification. The phrase "we cover the OWASP Top 10" names risk categories and says nothing about the depth of testing.

OWASP ASVS, the Application Security Verification Standard, fills that gap. The project explicitly aims to normalize the range of coverage and rigor that the market offers under the name of web application verification. In version 5.0.0 every requirement has a numeric identifier, and because identifiers can change between versions, the project recommends citing them with the version, for example v5.0.0-1.2.5. Requirement lists are published in machine-readable formats, including CSV and JSON. That means scope can be defined as a specific set of requirements, loaded into your own tracking system, and findings mapped to the same identifiers quarter after quarter.

OWASP WSTG (in version 4.2) describes how to test web applications in practice. SP 800-115 adds the program level: how to design and sustain a technical testing process. MITRE CWE classifies weaknesses, the root causes that group scattered findings into classes.

An important caveat: ASVS and WSTG cover web applications and APIs; they do not by themselves define the whole infrastructure scope. Mapping a finding to an ASVS requirement or a CWE class is a way of describing it, not proof of conformity. A penetration test can provide evidence for a specific applicable requirement under the recorded conditions, but identifiers on every row do not mean the requirement was tested in full or that the application conforms to the standard. Neither a penetration test nor a managed service is itself a certification, attestation or conformity opinion.

Prioritization: Several Different Questions Instead of One Score

The main operational problem is volume: neither the team nor the provider can give every record equal attention, and much of a service's value lies in how it narrows the list down to what matters in your environment. But different metrics answer different questions, and a service that collapses everything into a single number loses information.

CVSS, EPSS, KEV and Asset Exposure

A CVSS score describes a vulnerability's technical severity: how serious the consequences of exploitation could be. EPSS, the Exploit Prediction Scoring System from FIRST, estimates the probability that a vulnerability will be exploited in the next 30 days; it does not measure business impact for a particular organization. The CISA Known Exploited Vulnerabilities (KEV) catalog answers a third question: is there evidence of exploitation in real attacks. It is a valuable input signal, but a vulnerability's absence from KEV does not mean it is safe, and the remediation deadlines set for US federal agencies are not a universal legal requirement.

Only the customer knows the answer to the fourth question, and the provider only if it has been given the context: how reachable the asset is for an attacker and what is stored on it. A hypothetical example: a medium-severity vulnerability in an external login service that is listed in KEV may need a more urgent response than a "critical" one in an internal test environment with no sensitive data and no route from the internet. This illustrates the logic; it is not a rule. A mature service explains which factors produced a priority and lets the customer challenge the conclusion. There are no universal thresholds such as "everything above a certain EPSS value is urgent": the organization chooses its thresholds, and the provider should explain the assumptions behind its defaults. More on this in our breakdown of risk-based vulnerability prioritization.

From Individual Findings to Root Causes

The second level of prioritization is weakness classes. The 2025 edition of the MITRE CWE Top 25 highlights dangerous weaknesses that are often easy to find and exploit and can lead to system takeover, data theft or disruption of applications. Alongside it MITRE publishes the CWE Top 10 KEV Weaknesses, which ranks weaknesses using KEV catalog data, and the "On the Cusp" list of weaknesses that narrowly missed the main ranking.

The point is not to check against a ranking but to create a feedback loop. MITRE suggests feeding root causes back into the development lifecycle and architecture so that entire classes of defects can be eliminated, for example those related to injection or memory safety, and notes that weaknesses such as command injection attract attackers' attention. If a service reports new instances of the same injection in different modules every month, one task on the shared input-handling mechanism is more useful than ten separate tickets. At the same time, CWE classifies the weakness rather than estimating the exploitation probability of a specific CVE, and it does not replace exploitation data and asset context.

Testing Depth: What Automation Delivers and Where a Human Is Needed

SP 800-115 walks through technical techniques together with their strengths and limitations. The takeaway for the customer: the service description should show which techniques are applied to which assets and what each of them cannot detect.

Automated scanning provides breadth and repeatability: known vulnerable component versions, configuration errors, missing security headers. Manual testing following WSTG adds depth where you need to understand the system's intended behavior: business logic, access separation between roles and tenants, chains of operations that look harmless one at a time. Tools help here, but the result usually needs human interpretation; we wrote about how to commission that kind of testing in our article on business logic security testing. The balance between automated and manual work should be written into the statement of work. ASVS is a handy instrument: ask the provider to mark which requirements are tested automatically, which manually and which are out of scope.

Another part of depth is confirmation: unvalidated scanner output shifts the work of weeding out false positives onto developers and undermines trust in the service. Ask how the provider confirms a finding, what it records in the finding card (reproduction conditions, the affected component, evidence without unnecessary sensitive data) and how it flags what could not be confirmed.

Authorization and Rules of Engagement

All testing must be explicitly authorized in writing by every party empowered to approve work on the affected assets and environments. The contract or an annex defines the scope, time windows, contact persons on both sides, the handling of data the tester may gain access to, and the conditions for stopping work immediately. Neither the provider's commercial proposal nor this article constitutes authorization, and there are deliberately no exploitation instructions here.

If you are preparing such a framework and want to discuss with Pentest.red which systems and what depth of testing to include in the first iteration, describe the task through the penetration test scoping form. That is enough to have a concrete conversation about assets, constraints and the evidence you expect.

Web Findings a Service Should Explain, Not Just List

A significant share of web findings stems from configuration rather than code. HTTP itself does not keep state between requests, so applications add it themselves, usually through a cookie carrying an identifier the server uses to look up a session on its side. That is a normal architecture, but responsibility for issuing, protecting and ending sessions lies with the application, and this is where findings frequently appear, as they do in response headers and cross-origin rules.

MDN describes mechanisms that regularly show up in reports. Content Security Policy defines which resources a page may load and helps mitigate attacks such as cross-site scripting and data injection. CORS tells the browser whether script from another origin may read a response; a dangerous configuration can expose a credentialed response in the user's browser, but it does not replace server-side authorization. For certain cross-origin no-cors requests, Cross-Origin Resource Policy can keep the response body from the requesting context; it does not necessarily stop the request itself. Permissions Policy restricts which browser features and APIs the site's code can use. For a preliminary configuration check, MDN offers its HTTP Observatory tool.

A good report explains each such finding in terms of the risk it reduces and, where applicable, links it to a versioned ASVS requirement. It distinguishes a missing header that adds a layer of defense from an exploitable injection, and it takes the resource's purpose into account. A permissive CORS policy on a response intended for public cross-origin reading is not the same as one that lets an attacker-controlled origin read an authenticated user's response. CORS governs browser access to the response and does not decide which resources the server should authorize; both questions must be checked separately.

CISA Secure by Design alerts on cross-site scripting, OS command injection and directory traversal set out the preferred approach: eliminate the defect class at the source rather than patching each symptom.

Retesting and Evidence That Fixes Work

Retesting can turn into a formality when the provider repeats a signal rather than the scenario that established the finding. Recall the invented example from the opening: the scanner stopped seeing the vulnerability because it was blocked, not because the issue was fixed. A "not detected" status means only that a specific check under specific conditions produced no signal.

So a retest conclusion has to be bounded by what was actually repeated. If the original finding was confirmed by a manual scenario performed as a user with a particular role, the retest should reproduce the same scenario under the agreed conditions rather than settle for an automated run from an external address. A confirmed fix shows that this scenario no longer works; it does not mean the risk is gone for good or that adjacent paths are closed. If the provider also tested bypass variants, that should be visible in the report. More on this in our piece on vulnerability remediation control.

The table below helps with accepting the service's results: what evidence to ask for behind each claim and what that evidence does not show.

Trade-offs of Outsourcing Vulnerability Management

VMaaS can deliver what internal teams often lack: specialist testing expertise, a steady working rhythm and an independent perspective. But outsourcing has costs that are easy to miss. They include loss of business context, dependence on the provider's tools and formats, a map of your weaknesses held by a third party, and the risk that the work drifts toward reports rather than risk reduction. These are professional judgments, not measured results, and they are worth testing in a pilot.

There are also things outsourcing does not change. In its Secure by Design program, CISA notes that the burden of cybersecurity has fallen disproportionately on customers and small organizations rather than on technology manufacturers, and insists that vendors should take ownership of their products' security at the executive level. The takeaway for the customer: a managed service helps manage risk, but it does not replace software vendors fixing their own flaws. Pressure on them through procurement and contracts is still needed.

If you are weighing VMaaS against developing an in-house program, it helps to first understand how such a process works from the inside and which parts are easiest to hand to a contractor; that is the subject of our guide to building a vulnerability management process. Often the sensible answer is a hybrid: an internal owner of the process and of risk decisions, and an external provider for discovery, confirmation and retests.

Questions for the Provider and the Security of Its Platform

The provider is itself a digital service that will hold a detailed map of your weaknesses, so the same expectations apply to it as to any software vendor. In its Secure by Design and Secure by Demand materials, CISA calls for products that are secure by default, with multi-factor authentication, logging and single sign-on available at no extra charge. For the provider's portal this becomes a concrete question: are MFA for users, SSO and an audit log included in the base offering, or sold as add-ons?

Integrations need a separate conversation. Exporting findings into a ticket tracker or SIEM should run through service credentials with minimal privileges and a limited lifetime, not through an employee's shared account. MFA is a control for people; for machine integrations, narrow permissions, key rotation and the ability to revoke keys quickly matter more. Platform logs should record the actions of users and integrations, but must not store secrets, tokens or excessive fragments of sensitive data from evidence. Access to the logs should be restricted, their integrity protected and their retention period defined in advance.

It is useful to ask every candidate the same process questions so that the answers can be compared. Which ASVS version and which requirements are in scope, and are references versioned? Which WSTG and SP 800-115 techniques are used, and what are their stated limitations? How are findings confirmed, and how do EPSS, KEV and asset context feed into prioritization? Are root causes reported in CWE terms? Is retesting included, and how is its result documented? Can all data be exported in machine-readable formats such as CSV or JSON, including when the contract ends? How long is vulnerability data retained, and how is its deletion confirmed?

If the provider uses AI for initial triage of findings or for drafting reports, ask how people review the results, how model errors are detected and corrected, and whether your data ends up training third-party systems.

How to Run a Pilot and Make the Decision

The referenced open standards do not rank providers or compare prices, and they do not supply one universal VMaaS remediation deadline; other obligations may set deadlines for a particular organization. The decision rests on your own verification, and the order of steps matters.

Start with goals: which risks you want to reduce and which systems matter most for that. CSF 2.0 resources, including its quick-start guides and profiles, help frame this in risk-management language. Then set a baseline for verification, a versioned set of ASVS requirements for typical applications, and ask providers to describe their methodology in WSTG and SP 800-115 terms along with its limitations, and to explain their prioritization model.

After that, run a time-boxed, authorized pilot on a representative application whose weaknesses your team already has its own view of. Compare confirmed findings, their quality and their usefulness to developers, not the number of rows. Only once the proposals have been brought to the same scope and the same rigor should you compare prices: that kind of normalization is exactly what ASVS was created for. From then on, measure not the number of findings but confirmed fixes and the decline of recurring weakness classes.

Warning signs are visible already at this stage: "OWASP Top 10 compliance" with no link to specific requirements, unvalidated scanner output presented as findings, no retesting and no written authorization procedure, references to standards without versions, and promises of universal deadlines that in practice the customer is responsible for meeting.

An independent penetration test of a representative system can serve as a baseline for such a pilot: it shows what manual testing finds and gives you a reference point to compare the service's results against. If you need that kind of test, or a retest of fixes after another contractor's work, see how our penetration testing is organized and describe the system through the scoping form.

Conclusion: How to Choose Vulnerability Management as a Service

Vulnerability management as a service is worth buying if it closes the whole loop: from asset onboarding and planned testing, through confirmation and prioritization, to a verified fix. Scope should be expressed in versioned ASVS requirements, methods in WSTG and SP 800-115 terms, and priorities through a combination of severity, exploitation data, CWE root causes and the context of your assets. Accountability for risk decisions stays with you, and the contract should reflect that.

Start with scope and verification requirements, then assess methodology, prioritization, retesting and platform security, and compare prices last. A well-planned, authorized pilot on your own systems will show what no demo can: whether the service reduces risk or simply produces reports.