Vulnerability Management in the Age of AI | Corporater

When Infrastructure Outgrows Governance: Vulnerability Management in the Age of AI

How the collision of expanding infrastructure and unmanaged AI adoption is challenging traditional vulnerability management, and why the fix lives in the integration between operational tooling and the GRC layer.

The ground is shifting for the security team

Two numbers frame the problem better than any narrative.

The first: 48,185 CVEs were published in 2025, roughly 131 new vulnerabilities every single day, a record and a 20.6% jump over 2024, according to Jerry Gamblin’s widely cited year-end analysis of NVD and CVE List data. First-half 2026 volume is already running well ahead of that pace, and Gamblin’s updated forecast puts full-year 2026 at roughly 70,000 CVEs, a 45.6% increase over 2025. The disclosure pipeline is no longer a queue a team works through. It is a volume no manual process can realistically keep pace with.

The second: around 80% of employees are already using AI tools that their own IT function never sanctioned. Nearly all executives, 97% in one 2026 enterprise survey, report their company deployed AI agents in the past year, and Gartner expects 40% of enterprise applications to embed task-specific AI agents by the end of 2026, up from under 5% a year earlier.

Read together, these two trends describe the same crisis from opposite ends. Infrastructure and AI are both expanding the attack surface faster than the governance functions built to oversee it can keep pace. Vulnerability management sits precisely at the fault line, and for most organizations, many programs haven’t yet caught up to the pace of change.

This piece argues three things: that infrastructure growth and AI adoption are a single compounding risk, not two separate ones; that traditional, severity-driven vulnerability management can no longer scale to meet it; and that the decisive move is not another scanner but the integration of operational vulnerability data into the GRC layer, where it becomes governed, monitored, and board-visible.

One attack surface, two engines of growth

Infrastructure sprawl

Every organization’s estate has quietly become larger and more porous. Cloud services, APIs, third-party plugins, containerized workloads, and edge devices have each added their own exposure. The CVE data makes the shift concrete: in 2025, WordPress-plugin security firms out-published Microsoft and Google combined, a signal that vulnerability volume is now driven by the third-party ecosystem rather than a handful of OS vendors. Veracode’s 2025 data found that roughly 70% of critical security debt originates in third-party code.

The edge is where this hurts most. Network devices (VPNs, firewalls, routers) accounted for 18.3% of vulnerabilities first exploited in 2025, and a striking share of the ransomware-flagged additions to CISA’s Known Exploited Vulnerabilities catalog targeted the very appliances deployed to protect the perimeter. The boxes bought to reduce risk have become a primary way in.

AI adoption

Layered on top of that estate is a second engine that behaves nothing like the first. Where a human user represents one identity with predictable access patterns, an autonomous AI agent operates continuously, interacts with multiple systems at once, holds persistent credentials, and executes actions without a human reviewing each step. Cisco research, reported via Forbes, found that a single AI agent generates roughly 450% more network traffic than a human performing the same task. Multiply that across a fleet of agents, and the volume of activity security teams must monitor, and secure, grows accordingly.

Then there is what employees are doing off the books. IBM’s 2025 breach study found that shadow AI added roughly $670,000 to the cost of an average breach, a premium paid simply for having unknown AI in the environment when something went wrong, while 63% of organizations had no AI governance policy at all. New vulnerability classes are emerging alongside: an estimated 1,418 AI-specific CVEs were disclosed in 2025, and they skew sharply toward high and critical severity.

The two engines reinforce each other. AI workloads run on the expanding infrastructure, and the ungoverned adoption of AI creates exactly the blind spots (unmonitored OAuth connections, unsanctioned integrations, shadow APIs) where infrastructure vulnerabilities go unnoticed until they are exploited.

Why traditional vulnerability management needs to evolve

The classic operating model (scan, score by CVSS, patch the criticals, repeat) assumed three things that are no longer true.

It assumed volume was manageable. At 131 disclosures a day, manual triage alone can’t keep pace, and treating it as the whole strategy just builds a backlog. Teams cannot patch everything, and pretending otherwise guarantees the wrong things get patched.

It assumed severity equaled priority. Only about 28% of 2025 CVEs received full NVD enrichment, meaning a program that triages purely on NVD CVSS scores is now flying blind on a large fraction of the exploited-in-the-wild bugs. Meanwhile critical severity accounted for well under 10% of the total, so “patch the criticals” both misses genuinely dangerous flaws and drowns teams in ones that will never be reached in their environment. Modern prioritization has moved to a KEV-first, EPSS-weighted, exposure-aware discipline: what is actually exploitable, actually exploited, and actually reachable in your estate.

It assumed there was time. There is not. Verizon’s 2025 DBIR put vulnerability exploitation at 20% of all breaches, the second most common initial access vector, and the median time-to-exploit has collapsed to under five days, with a meaningful slice of vulnerabilities weaponized before or within 24 hours of public disclosure. When exploitation routinely beats the patch, remediation velocity becomes a governance metric, not just an ops one.

The clear conclusion: the bottleneck is no longer detecting vulnerabilities. Scanners are commoditized and effective. The bottleneck is deciding, governing, and proving: turning a flood of findings into prioritized action, tying that action to accountable owners and SLAs, and demonstrating to regulators and the board that the whole loop is under control.

That is not a scanning problem. It is a GRC problem.

The missing layer: from findings to governance

Here is the gap most security stacks still have. Operational tooling produces vulnerability findings by the thousand. The GRC function owns risk registers, control frameworks, and board reporting. In most organizations, a human being with a spreadsheet sits between them, manually translating scan output into risk language, mapping it to controls, chasing remediation, and reconstructing a status picture in time for the quarterly risk committee.

That manual bridge is exactly where the model reaches its limits under the volumes described above. It cannot keep a risk register current against 131 new CVEs a day. It cannot evidence continuous control monitoring. And it cannot give an executive a defensible, real-time answer to the only questions that matter to them: How exposed are we, is it getting better or worse, and are we meeting our obligations?

Closing that gap means treating vulnerability data as a live feed into the governance layer, not a periodic report out of the operational one. Concretely, it requires two tiers working as one system.

High-level design

The solution is a two-plane sensing tier feeding one governing layer. The infrastructure plane (cloud, endpoints, network) and the AI plane (models, agents, RAG pipelines) expose different classes of vulnerability, so each needs its own sensing, and, crucially, each is governed by a different family of controls. Both normalize into a single register on Corporater’s Business Management Platform for enterprise security governance that reports to the board.

Tier 1: Sensing (two planes)

The infrastructure plane runs on a ManageEngine stack:

  • Vulnerability Manager Plus for continuous vulnerability assessment, configuration and hardening checks, and misconfiguration detection across servers, endpoints, and network assets.
  • Endpoint Central / Patch Manager Plus for automated, cross-platform patch deployment, turning “we know about it” into “it’s remediated” without a manual handoff.
  • Log360 for correlating exploitation signals and anomalous behavior, including the unusual egress patterns that betray a compromised agent or an unmonitored integration.

The AI plane needs a separate toolchain, because ManageEngine does not scan for AI-specific flaws:

  • LLM guardrails and gateway (for example NeMo Guardrails, Llama Guard, Bedrock Guardrails) for prompt-injection defense and output filtering.
  • Adversarial red-teaming and evaluation (for example Giskard, Promptfoo) for model robustness.
  • AI-BOM and model/dependency scanning for supply-chain and poisoning exposure.
Both planes emit structured findings the governance tier consumes.

Tier 2: Governing with Corporater's Business Management Platform for Vulnerability Management

Corporater’s Business Management Platform makes that signal mean something in risk and compliance terms, on one model rather than in siloed registers:

  • Ingest findings and remediation status from both planes via API and webhook, so the register reflects the live state of the estate rather than a month-old snapshot.
  • Map each finding to the right control family: infrastructure findings to ISO 27001 (A.8.8, A.8.16) and NIST CSF; AI findings to ISO/IEC 42001, NIST AI RMF, the OWASP LLM and Agentic Top 10, and MITRE ATLAS, so exposure is expressed as measurable control effectiveness, not just a longer scan report.
  • Monitor through Key Risk Indicators tied to thresholds: mean time to remediate, percentage of KEV-listed vulnerabilities open past SLA, exposure on internet-facing assets. Breaches trigger escalation and workflow.
  • Report to the board through role-based dashboards that render technical exposure as governed risk, with trend, ownership, and compliance status attached.

Which frameworks, and are they competent for AI?

Not all of them, and not for the same layer. ISO 27001, NIST CSF, and CIS Benchmarks govern the infrastructure the AI runs on. They are competent for that plane and nothing more. They contain no control for prompt injection, model or data poisoning, model theft, excessive agency, or RAG poisoning. (PCI DSS is scoped strictly to the cardholder data environment; it belongs here only where AI touches payment card data.) The AI plane needs AI-native frameworks. What each prescribes:

Framework / control Governs What it prescribes
ISO 27001 A.8.8 Infrastructure Identify, assess, and patch technical vulnerabilities on a defined cadence
ISO 27001 A.8.16 Infrastructure Monitor systems and networks for anomalous behavior and events
ISO/IEC 42001 Annex A AI management AI impact assessment, data lineage, model evaluation, human oversight, monitoring
NIST AI RMF 1.0 AI risk process Govern, map, measure, and manage AI risk; test for security and resilience
OWASP LLM Top 10 (2025) AI application Guardrails, privilege separation, output validation against prompt injection
OWASP Agentic AI Top 10 AI agents Constrain tool scope, least-privilege agent identity, human-in-the-loop
MITRE ATLAS v5.4 Adversary TTPs Threat-model and red-team AI; deploy ATLAS mitigations in the SOC
EU AI Act Article 15 Regulatory (high-risk) Accuracy, robustness, and cybersecurity; high-risk (Annex III) obligations apply from 2 December 2027 following the EU's 2026 Digital Omnibus deferral

Low-level design: the integration is the product

Neither tier is novel alone. The value is the connective tissue. At the interface level, both sensing planes push normalized findings, a common JSON schema over REST and webhooks, into a connector that lands each one in Corporater as a risk-register record, resolves it against the control library, assigns an accountable owner and remediation SLA, and rolls it into a board-level KRI, automatically and with a full audit trail. An infrastructure CVE from Vulnerability Manager Plus maps to ISO 27001 A.8.8; a prompt-injection finding from the AI guardrail maps to OWASP LLM01 and ISO 42001. The spreadsheet-and-analyst bridge disappears, and with it the lag that makes continuous control monitoring difficult to achieve.

What this changes for the executive

For a board or an executive risk committee, this integration converts vulnerability management from a technical status update they cannot interrogate into a governed risk they can actually direct.

Continuous assurance replaces periodic reassurance

Instead of a quarterly slide asserting that patching is “on track,” leadership sees live control effectiveness, with degradation flagged the moment an SLA slips.

Risk becomes comparable and prioritizable

Exposure expressed as mapped, quantified risk can be weighed against every other entry in the register, and against risk appetite, rather than living in an isolated security dashboard no one outside the SOC reads.

Compliance becomes defensible by design

General-purpose AI obligations under the EU AI Act have applied since August 2025, and while the Act’s high-risk (Annex III) deadline was recently pushed to December 2027 under the EU’s Digital Omnibus, that shift buys time rather than removes the direction of travel: financial-services regulators are tightening operational-resilience expectations, and AI-specific obligations continue to advance across multiple jurisdictions. An auditable, always-current link between technical exposure and control status is fast becoming a regulatory expectation rather than a maturity nicety. Gartner’s projection that AI-governance platform spending will reach roughly $492 million in 2026 reflects where the pressure is already going.

The AI blind spot gets a governance home

The same architecture that governs infrastructure vulnerabilities extends naturally to AI exposure. Agent inventory, shadow-AI detection signals, and AI-specific CVEs become risk-register entries mapped to controls, closing the gap that currently sits, unowned, across five functions in most organizations.

The takeaway

Infrastructure is expanding. AI adoption is outpacing every governance framework built to contain it. Vulnerabilities are being disclosed faster than any team can triage them and exploited faster than any team can patch them. None of these trends is going to reverse.

The organizations that stay ahead will not be the ones with the most scanners. They will be the ones that treat vulnerability data as governed risk, wiring the operational sensing layer directly into the GRC layer so that exposure is discovered, quantified, owned, monitored, and evidenced as a single continuous loop. A ManageEngine-and-Corporater architecture is one concrete way to build that loop, but the principle outlives any single toolchain: in an age where infrastructure outgrows governance, the integration between them is the control that matters most.