Users appreciate when software can easily integrate into their existing IT environment. For vendors, this means supporting a cross-platform mix of operating systems and infrastructure. Greenbone is excited to expand our virtualization platform support, bringing Nutanix AHV into our family of supported hypervisors. This addition adds flexibility for deploying OPENVAS SCAN and extends Greenbone’s already diverse support for hypervisors that also includes Microsoft Hyper-V, Oracle VirtualBox, VMware vSphere (ESXi) and and Workstation Pro, Huawei FusionCompute, and Proxmox VE. Our wide range of hypervisor support ensures that defenders can run our solution in virtually any IT environment.

A free trial of Greenbone’s OPENVAS BASIC is available for Nutanix users and others to scan their IT infrastructure for vulnerabilities and stay ahead of cyber attacks. For a full breakdown of our product offerings, check out our solution comparison.

In the rest of this article, we will discuss how to integrate OPENVAS SCAN virtual appliances on the Nutanix AHV Type-1 hypervisor.

The OPENVAS SCAN Virtual Appliance Now Supports the Nutanix AHV Type-1 Hypervisor

Greenbone is excited to add support for Nutanix AHV virtualization. AHV (short for Acropolis Hypervisor) is the native hypervisor of the Nutanix Cloud Infrastructure platform. As a Type-1 hypervisor, AHV runs directly on the host’s hardware. This puts virtualized appliances closer to the underlying hardware and delivers high performance, low latency operation. The overall impact is a faster and more reliable virtualization environment. By contrast, Type-2 hypervisors run on top of a standard desktop operating system, which is not optimized for efficiency and reliability.

Nutanix is built on top of the Linux kernel’s KVM hypervisor and QEMU hardware emulator. The same open-source virtualization stack that underpins much of the modern data center and public cloud. Unlike traditional hypervisors, AHV is included at no additional licensing cost with the Nutanix Cloud Infrastructure platform and is managed through Nutanix Prism.

Whether you are an existing Greenbone enterprise customer looking for new virtualization options, or already running Nutanix AHV and seeking support, Greenbone now has you covered.

How to Set up OPENVAS SCAN on Nutanix AHV

Customers can request a Nutanix-ready instance of the OPENVAS SCAN virtual appliance from a member of the Greenbone sales team. This specialized image is delivered in the QEMU Copy-On-Write (QCOW) format, optimized for Nutanix AHV. Once you receive the .qcow file, complete the following steps in Nutanix Prism to install and configure the OPENVAS SCAN virtual appliance:

1. Log in to the Nutanix AHV web interface and open the settings menu in the upper right corner.
2. Select Image Configuration and click Upload Image. Give the image a name, set Image Type to DISK, choose Upload a file, select the QCOW file of the appliance, and click Save.
3. Switch to the VM view from the drop-down menu in the upper left corner and click Create VM.
4. Enter a name for the virtual machine, then set the number of virtual CPUs and cores, the amount of memory, and select UEFI as the boot configuration. The appliance requires the EFI/UEFI boot mode.
5. Click Add New Disk, select Clone from Image Service as the operation, choose SATA as the bus type, select the image you uploaded in step 1, and click Add.
6. Under Network Adapters (NIC), click Add New NIC and add at least one network interface, then click Save. The import can take up to 10 minutes.
7. Once imported, select the appliance from the Table tab, click Power on, and complete the OPENVAS SCAN setup process.

Full step-by-step instructions, including screenshots, are available in the Greenbone documentation.

Which Hypervisors Does the OPENVAS SCAN Virtual Appliance Support?

Here is an overview of the supported hypervisors and resource requirements for the OPENVAS SCAN virtual appliance.

The OPENVAS SCAN virtual appliance requires the following resources:

• 2 virtual CPUs
• 12 GB RAM
• 500 GB virtual hard disk (can be dynamically allocated)

Summary

Greenbone has added support for deploying our OPENVAS SCAN virtual appliance on the Nutanix AHV Type-1 hypervisor, giving adding to our industry leading flexibility. This new capability extends the virtualization options, ensuring users can confidently integrate OPENVAS SCAN into any IT environment — including the growing number of data centers built on Nutanix. A free trial of Greenbone’s OPENVAS BASIC is available for Nutanix users and others to scan their IT infrastructure for emerging threats and stay ahead of cyber attacks.

BeyondTrust advisory BT26-03, issued on July 6th, 2026, describes multiple new vulnerabilities in BeyondTrust Remote Support (RS) and BeyondTrust Privileged Remote Access (PRA). The vulnerabilities include two critical flaws exploitable without authentication and additional high-severity issues in network communication and web application components. All the flaws require specific configurations for exploitation, but BeyondTrust has not disclosed the configuration details.

According to BeyondTrust, the issues were found through internal AI-driven vulnerability research using publicly available AI models, and they were fixed before exploitation. The vendor also claims that the flaws were not exploited or known outside the company prior to remediation.

There is no evidence that any of the CVEs have been exploited in the wild, and no public proof-of-concept (PoC) exploits have been published. CISA has added three vulnerabilities affecting BeyondTrust RS and PRA to its KEV Catalog since late 2024, indicating that the products are popular targets for attackers. CVE-2026-1731 was added in early 2026 and is associated with ransomware attacks. Numerous national CERT agencies have issued alerts [1][2][3][4][5][6][7][8][9], indicating high global risk.

OPENVAS ENTERPRISE FEED includes a remote banner version check covering CVE-2026-40138, CVE-2026-40140, and CVE-2026-40141 in BeyondTrust PRA, and a separate remote banner version check for CVE-2026-40138, CVE-2026-40139, CVE-2026-40140, and CVE-2026-40141 in BeyondTrust RS. Grabbing a copy of OPENVAS SCAN with a free two-week trial of the OPENVAS ENTERPRISE FEED is a surefire way to gain the deepest insight into where software vulnerabilities exist in your organization’s IT infrastructure.

Vulnerabilities Disclosed in the BeyondTrust BT26-03 Advisory

The BeyondTrust BT26-03 advisory covers two critical and two high-severity CVEs across two products: BeyondTrust RS and PRA. There is no evidence of exploitation in the wild, and no publicly available PoC exploits exist for any of the CVEs disclosed in BT26-03. All of the flaws have been assigned moderate EPSS scores: 36th – 48th percentiles.

Affected Products and Versions

BeyondTrust states that all cloud-hosted RS and PRA instances were patched as of April 21st, 2026. For self-hosted deployments, the vendor directs customers to apply the April security rollup patch or upgrade to the fixed product versions. The supplied evidence identifies RS 25.3.2 and earlier and PRA 25.3.2 and earlier as affected. BeyondTrust provides no workarounds for the vulnerabilities.

BeyondTrust Remote Support (RS) is an enterprise-grade remote support tool used by IT service desks, help desks, and support teams to connect to and control remote systems and devices. In operational terms, that means the product often sits on a path used for remote troubleshooting, administrative support, and endpoint interaction.

BeyondTrust Privileged Remote Access (PRA) is used to manage remote access to critical systems for privileged users and third-party vendors. The product includes session monitoring, auditing, recording, and least-privilege controls. BeyondTrust also describes the B Series Appliance as the central communication point for secure remote access, handling session brokering, authentication, logging, auditing, and encryption.

Summary

BT26-03 consolidates four confirmed vulnerabilities across BeyondTrust Remote Support and BeyondTrust Privileged Remote Access. The most important issues are the two critical pre-authentication flaws, followed by the high-severity vulnerabilities in the network communication and web application components. Although none of the CVEs are known to have been exploited in the wild and no public PoC exploit exists, CISA has added three vulnerabilities affecting BeyondTrust RS and PRA to its KEV Catalog since late 2024. CVE-2026-1731 was added in early 2026 and is associated with ransomware attacks. Numerous national CERT agencies have issued alerts, indicating high global risk. Greenbone’s OPENVAS ENTERPRISE FEED provides remote banner version checks for the BT26-03 CVEs, helping defenders identify affected BeyondTrust RS and PRA appliances and prioritize remediation.

The true impact that cyber security aware AI will have on the global threat landscape remains to be seen. By some reports, the CVE output for software made by major vendors is on the rise. This June 2026 threat report only scratches the surface of the major cyber security threats from this month. The month brought a concentrated wave of actively exploited enterprise vulnerabilities, with CISA logging multiple new additions to its Known Exploited Vulnerabilities (KEV) catalog throughout the month. At least one new critical perimeter network exploit was tied to an active ransomware affiliate.

Greenbone’s vulnerability coverage extends far beyond major, headline-grabbing IT security events, such as the ones in this monthly threat report, and keeps pace with the onslaught of AI driven disclosures. Grabbing a copy of OPENVAS SCAN with a free two-week trial of the OPENVAS ENTERPRISE FEED is a surefire way to gain the deepest insight into where software vulnerabilities exist in your organization’s IT infrastructure.

Here are some of the top emerging threats to enterprise IT security from June 2026.

CVE-2026-20253: Unauthenticated RCE in Splunk Enterprise Actively Exploited

CVSS 9.8 · CriticalActively exploitedIn CISA KEVPublic PoC

CVE-2026-20253 (CVSS 9.8, EPSS ≥ 95th pctl) allows an unauthenticated remote attacker to create or truncate arbitrary files in Splunk Enterprise 10.2 before 10.2.4 and 10.0 before 10.0.7. The flaw is due to missing authentication [CWE-306] on a PostgreSQL sidecar service endpoint. Splunk confirmed limited in-the-wild exploitation, and CISA has added the flaw to KEV. A full technical description with PoC exploit code has been published by WatchTowr demonstrating unauthenticated RCE. Shadowserver tracked more than 1,400 internet-exposed Splunk instances.

CVE-2026-20253 is patched in Splunk Enterprise 10.2.4 and 10.0.7, and customers should upgrade immediately. If patching is not possible, exploitation can be prevented by disabling the PostgreSQL sidecar service. However, disabling the service may disrupt Edge Processor, OpAmp, or SPL2 data pipelines. The OPENVAS ENTERPRISE FEED includes a remote analysis check and a separate remote banner check to identify affected instances.

CVE-2026-28318: SolarWinds Serv-U Exploited in DoS Attacks

CVSS 7.5 · HighActively exploitedIn CISA KEVPublic PoC

CVE-2026-28318 (CVSS 7.5, EPSS ≥ 60th pctl) allows an unauthenticated remote attacker to cause a denial of service (DoS) in SolarWinds Serv-U Managed File Transfer and FTP Server. CISA added the flaw to its KEV catalog; however, no campaign attribution has been made. A technical description has been published. Exploitation is achieved by simply including the Content-Encoding: deflate request header and can crash the Serv-U service. The flaw is caused by uncontrolled resource consumption [CWE-400] in crafted HTTP POST request handling.

There is significant risk of operational disruption to exposed file transfer servers used in regulated sectors such as healthcare, finance, and government. Exposed Serv-U instances were originally reported to be more than 12,000 by Shodan and roughly 3,000 by Shadowserver. However, Shodan detection had since fallen to less than 10,000 by the end of June.

SolarWinds advises customers to install Serv-U 15.5.4 Hotfix 1 immediately. If patching cannot be done right away, users can block POST requests containing the Content-Encoding: deflate header without losing any functionality. The OPENVAS ENTERPRISE FEED includes a remote banner check to detect vulnerable instances.

Living on the Edge: Emerging Threats to Perimeter Security

Vulnerabilities in network perimeter devices are particularly high risk because they are exposed to attack by arbitrary remote attackers. According to the latest Verizon DBIR 2026 report, exploiting publicly exposed software vulnerabilities is now the most common vector for initial access globally. Here are some of the most critical emerging threats to perimeter devices in June 2026.

CVE-2026-50751: Check Point Security Gateway Exploited in Ransomware Attacks

CVSS 9.3 · CriticalActively exploitedIn CISA KEVPublic PoCRansomware-linked

CVE-2026-50751 (CVSS 9.3, EPSS ≥ 98th pctl) and CVE-2026-50752 (CVSS 7.4, EPSS ≥ 90th pctl) affect Check Point VPN Remote Access, Mobile Access, Security Gateways, and Spark Firewalls. CVE-2026-50751 is being actively exploited with at least one post-compromise case linked to a Qilin ransomware affiliate. CISA has added CVE-2026-50751 to its KEV catalog. The first attacks were observed on May 7, 2026. A few dozen organizations have been targeted globally. PoC exploit code and a full technical description are publicly available for CVE-2026-50751. CVE-2026-50752 is not reported as actively exploited.

The CVEs are described below:

• CVE-2026-50751 (CVSS 9.3, EPSS ≥ 98th pctl): Unauthenticated remote attackers can establish VPN access through a logic-flow and certificate-validation weakness in IKEv1 deployments.
• CVE-2026-50752 (CVSS 7.4, EPSS ≥ 90th pctl): Could allow unauthenticated attackers to conduct adversary-in-the-middle attacks against VPN site-to-site connections.

Check Point has published recommendations for removing support for legacy protocols, upgrading affected instances to fixed versions, and provides additional security hardening advice [1][2]. The OPENVAS ENTERPRISE FEED includes remote banner detection for Gaia, Check Point’s unified security OS for Security Gateways, Security Management products, Software Blades, Check Point appliances, and Open Servers. Check Point Gaia version R80.20, R80.40, R81, R81.10, R81.20, R82, and R82.10 are affected.

Three CVSS 10 Flaws in Ubiquiti UniFi OS Allow Unauthenticated RCE

CVSS 10 · CriticalExploited as zero-dayIn CISA KEV

Three new CVSS 10 flaws affecting UniFi OS systems have been published and added to CISA’s KEV list. The flaws collectively allow attackers to modify underlying operating-system files and accounts, and execute commands. User reports indicate the flaws were likely exploited as zero-days to create rogue administrator accounts. Risk is elevated because UniFi OS devices centrally manage network infrastructure, making successful compromise a potential path for lateral movement into enterprise environments.

The CVEs are described below:

• CVE-2026-34908 (CVSS 10): An attacker with network access can exploit an improper access control vulnerability [CWE-284] in UniFi OS devices to make unauthorized changes to the system.
• CVE-2026-34909 (CVSS 10): An attacker with network access can exploit a path traversal vulnerability [CWE-22] in UniFi OS devices to access and manipulate files on the underlying system and access underlying accounts.
• CVE-2026-34910 (CVSS 10): An attacker with network access can exploit an improper input validation vulnerability [CWE-20] in UniFi OS devices to execute command injection attacks.

Bishop Fox published a full technical analysis showing that CVE-2026-34908 and CVE-2026-34909 form an authentication gateway bypass caused by crafted NGINX request handling. Exploitation exposes internal routes and enables command injection via CVE-2026-34910.

Exploitation of all aforementioned CVEs has been validated against UniFi OS version 5.0.6. Ubiquiti fixed the vulnerabilities in UniFi OS Server version 5.0.8, released on May 21, 2026. No workarounds are available. The OPENVAS ENTERPRISE FEED includes a remote vulnerability check and remote banner check for Ubiquiti UniFi OS on various devices and an additional remote vulnerability check and remote banner check for Ubiquiti UniFi OS Server version 5.0.6 and prior.

Squidbleed (CVE-2026-47729) Memory Leak Has Public PoC

CVSS 6.5 · MediumPublic PoCNo ITW exploitation

CVE-2026-47729 (CVSS 6.5), also known as Squidbleed, allows an authorized Squid proxy user to leak another user’s cleartext HTTP request data. The flaw is caused by a heap over-read in the FTP directory-listing parser. Leaked data may include credentials, session tokens, API keys, and Authorization headers. Public proof-of-concept exploit code and a full technical description are available. However, in-the-wild exploitation has not been reported. Surprisingly, despite having a GitHub Security Advisory referencing the CVE by ID, CVE-2026-47729 has not been published to MITRE’s CVE.org or NIST NVD as of July 1st, 2026.

The flaw affects shared proxy environments where Squid can inspect cleartext HTTP or terminate TLS altogether, and all Squid versions dating back to a 1997 FTP parser change. Exploitation requires the Squid instance to be able to reach an attacker-controlled FTP server on TCP port 21. The flaw is fixed in the Squid 7.6 June 2026 release but can also be mitigated by disabling FTP support if not required. The OPENVAS ENTERPRISE FEED includes package-level detection for Linux distributions that have issued security advisories and a remote banner detection for affected versions of Squid proxy.

CVE-2026-10520 and CVE-2026-10523 in Ivanti Sentry

CVSS 10 · CriticalActively exploitedIn CISA KEVPublic PoC

CVE-2026-10520 (CVSS 10) and CVE-2026-10523 (CVSS 9.8) allow a remote, unauthenticated attacker to achieve root-level RCE and create arbitrary administrative accounts in Ivanti Sentry. CVE-2026-10520 has been added to CISA’s KEV catalog after reported exploitation attempts against honeypots. watchTowr published a full technical analysis including a public PoC exploit. Shadowserver reported large-scale exploitation of CVE-2026-10520, identifying 19 vulnerable instances in its scans with at least two identified as compromised.

• CVE-2026-10520 (CVSS 10): An OS command injection vulnerability [CWE-78] allows a remote, unauthenticated user to achieve root-level remote code execution.
• CVE-2026-10523 (CVSS 9.8): An authentication bypass vulnerability [CWE-288] allows a remote, unauthenticated attacker to create arbitrary administrative accounts and obtain full administrative access.

Exploitation requires access to the management port 8443. Affected versions include Ivanti Sentry 10.5.1, 10.6.1, 10.7.0, and prior versions, with fixes available in 10.5.2, 10.6.2, and 10.7.1. Greenbone’s OPENVAS ENTERPRISE FEED includes an active check and a remote banner check that cover both CVEs.

The HTTP/2 Bomb: DoS against All Major Web Servers

CVSS 7.5 · HighPublic PoCMulti-vendor DoS

HTTP/2 Bomb is a remote, unauthenticated denial-of-service (DoS) technique against HTTP/2 server implementations. The flaw affects the default HTTP/2 configurations in Apache HTTP Server, NGINX, Microsoft IIS, Envoy Proxy, and Cloudflare Pingora, among other digital products that package them. A detailed technical write-up is available, and Calif’s HTTP/2 Bomb companion repository lists self-contained per-server PoCs and Docker labs for major affected web servers, increasing the risk. HTTP/3 is not reported as directly vulnerable to the current HTTP/2 Bomb technique.

The exploit uses legitimate HTTP/2 features in a way the HPACK header compression spec did not constrain. Affected web servers failed to enforce the extra limits needed to make those features safe. Exploitation has a reported memory amplification of between 70:1 and 5.7K:1 and allows consuming 32 GB to 64 GB of server memory within seconds. The root cause is flawed HTTP/2 request handling, where HPACK-driven cookie expansion triggers excessive memory allocation and data amplification. Calif.io also states that the deeper root cause is a protocol specification issue. The major products related to HTTP/2 Bomb are described below:

• CVE-2026-49975 (CVSS 7.5) — Apache HTTP Server mod_http2: Apache HTTP Server versions 2.4.17 through 2.4.67 are affected and the issue is fixed in Apache HTTP Server version 2.4.68.
• CVE-2026-47774 (CVSS 7.5) — Envoy Proxy: Envoy versions before 1.35.11, 1.36.7, 1.37.3, and 1.38.1 are affected.
• CVE-2026-49160 (CVSS 7.5) — Microsoft HTTP.sys / IIS: Affects Microsoft HTTP.sys, the Windows HTTP stack used by IIS and other Windows HTTP services. Microsoft addressed the issue in its June 9th, 2026 security updates.
• No CVE assigned — nginx: All nginx versions before 1.29.8 are affected and the issue is fixed in nginx 1.29.8. Red Hat states that upstream nginx did not assign a CVE for HTTP/2 Bomb.

Quang Luong of Calif.IO attributes the discovery of HTTP/2 Bomb to OpenAI Codex. Many additional CVEs are expected to emerge as hardware and software vendors patch their products. Greenbone includes numerous vulnerability tests to detect HTTP/2 Bomb across a wide range of Linux distributions and other affected products. This includes detection for affected Apache HTTP Server products (CVE-2026-49975), Envoy Proxy (CVE-2026-47774), Microsoft IIS (CVE-2026-49160), and nginx despite the lack of CVE coverage.

Multiple Critical Flaws in SAP SE and SAP NetWeaver AS ABAP, and ABAP Platform

CVSS 9.9 · CriticalNo known exploitationPatch available

Three new critical flaws affecting SAP products have been published. Collectively, the flaws impact NetWeaver AS ABAP and ABAP Platform, SAP NetWeaver Application Server Java Web Container, SAP Commerce Cloud, and SAP Data Hub. Risk is elevated because the flaws can allow unauthorized access, sensitive data exposure, file modification, application crashes, memory corruption, arbitrary code execution, and connection hijacking without user interaction in several cases. No active exploitation has been observed in the wild. Public PoC exploits or a full public exploit chain are not available. Mitigate by applying SAP’s June 2026 Security Patch Day updates immediately.

Details on the three CVEs are included below:

• CVE-2026-44748 (CVSS 9.9): An authenticated attacker with normal privileges can obtain a valid signed message and send modified signed XML documents to the verifier. This can result in acceptance of tampered identity information, leading to unauthorized access to sensitive user data and disruption of normal system usage. SAP NetWeaver AS ABAP version 7.02, 7.31, 7.40, 7.50, 7.51, 7.52, 7.53, 7.54, 7.55, 7.56, 7.57, 7.58, 8.16, 9.18, and 9.19 are affected. The OPENVAS ENTERPRISE FEED includes a remote banner check to identify affected instances.
• CVE-2026-27671 (CVSS 9.8): Due to improper RFC protocol validation in the SAP Kernel, an unauthenticated attacker can send a crafted RFC request that exploits logical errors in memory management, leading to memory corruption. SAP NetWeaver AS ABAP version 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 9.16, 9.18, and 9.19 are affected. The OPENVAS ENTERPRISE FEED includes a remote banner check to identify affected instances.
• CVE-2026-40128 (CVSS 9.0): An unauthenticated attacker can craft a malicious HTTP logon request that manipulates file inclusion parameters. Exploitation enables path traversal and processing of the included file and allows the attacker to view or modify sensitive information or render any part of the local system unavailable. SAP NetWeaver AS Java version 7.50 is affected. The OPENVAS ENTERPRISE FEED includes a remote banner check to identify affected instances.

Summary

June 2026 underscored accelerating enterprise risk from actively exploited flaws in Splunk, SolarWinds Serv-U, Check Point gateways, Ubiquiti UniFi OS, Ivanti Sentry, Squid, HTTP/2 implementations, and SAP platforms. Public PoCs, KEV listings, ransomware links, and exposed internet-facing assets reinforce the need for rapid patching, compensating controls, and continuous vulnerability detection across perimeter and core infrastructure.

Greenbone’s OPENVAS BASIC is available free of charge and includes a two-week trial of the OPENVAS ENTERPRISE FEED — giving your security team immediate access to automated vulnerability detection for the CVEs covered in this report and tens of thousands more. Start your free trial today.

For the first time, attackers are exploiting unpatched vulnerabilities more often than they’re stealing credentials. According to Verizon’s 2026 Data Breach Investigations Report, vulnerability exploitation now accounts for 31% of breaches, ahead of credential theft at 13%. And the gap is moving in the wrong direction for defenders: the median time to fully patch a vulnerability climbed to 43 days, up from 32 the year before, while organizations patched only 26% of the vulnerabilities on CISA’s Known Exploited Vulnerabilities list, down from 38% in 2024 (we broke down what’s driving this shift here).

Scanners aren’t the bottleneck here. Finding a vulnerability and actually fixing it have turned into two separate problems, and the second one is losing ground.

Detection was never the hard part

Greenbone’s OPENVAS has spent nearly two decades getting good at the first half: scanning a network, identifying what’s exposed, and scoring how dangerous it is. Elmar Geese, Greenbone’s CEO, likes to compare it to a swarm of robots checking every door and window in a house. They’re fast and thorough, and when they find a broken lock, they sound the alarm.

But an alarm only matters if someone acts on it. In most organizations, that’s where things stall. A scan result lands in a report, or an inbox, or a spreadsheet nobody opens until the next audit. Someone has to read it, work out what it actually means for their specific systems, decide who owns the fix, and turn that into a tracked piece of work with a deadline. That step requires security expertise that not every IT team has sitting around, and it’s exactly where things get lost: severity gets misjudged, tickets get duplicated or never created, ownership gets argued over after the fact instead of decided up front.

This is the part of vulnerability management that doesn’t show up in scanner marketing, but it’s where most of the real delay lives.

What the integration actually changes

KIX CEO Rico Barth puts it simply: the partnership closes the gap “between the detection and the resolution of vulnerabilities.” That gap is where a security finding used to need a translator. Now it doesn’t.

KIX, the open-source ITSM platform, and Greenbone have built a direct line between the two halves of the problem. When OPENVAS flags a vulnerability, it doesn’t generate a report and stop there. It opens a ticket in KIX automatically: classified as a security incident, tied to the specific device or software it affects, and sent to the team that owns that asset. The fix-it workflow, with deadlines, reminders, and escalations, starts the moment the vulnerability is confirmed, not whenever someone gets around to reading the scan output.

It also means an IT admin opening a ticket isn’t starting from zero. The asset, the affected system, who needs to be told, and how this fits into everything else currently open are all sitting right there. Nobody has to cross-reference three different tools to figure out what’s actually going on.

The bonus nobody asked for: finding the stuff you didn’t know you had

There’s a side effect that turns out to matter almost as much as the ticketing itself. OPENVAS scans more than the systems IT already knows about. It finds the laptop a department bought without asking IT, or the server someone spun up two years ago and forgot about. That inventory now flows straight into KIX’s asset database.

Shadow IT is usually framed as a policy problem. In practice, it’s a visibility problem that gets worse as networks grow. Greenbone customers are routinely surprised by what shows up the first time their environment gets properly scanned. Folding that discovery into the same system that already handles tickets and ownership means an unknown device gets absorbed into the normal IT process right away, instead of sitting in its own blind spot.

Why this matters more given who’s actually doing the work

IT and security teams are stretched thin almost everywhere, and the manual interpretation step in vulnerability management has always assumed there’s enough specialized staff to do it well. That assumption is getting shakier every year. Take away the step where a human has to manually triage, classify, and route every finding, and smaller or generalist IT teams no longer need to borrow security expertise they didn’t have in-house just to keep up.

It also helps with something that eats more time than it should: proving you did the work. Documentation, deadlines, and resolution history land automatically in KIX, which makes audits against frameworks like NIS-2, ISO 27001, or BSI-Grundschutz considerably less painful, since the evidence trail already exists instead of getting reconstructed after the fact.

Try it where it counts

If your team is running OPENVAS and KIX separately today, or evaluating either one, this integration is worth a closer look specifically because it removes a step rather than adding one. Get in touch with us to see how the handoff from scan to fix works in your own environment, and what it would take to set up. And if you’re not scanning with OPENVAS yet, OPENVAS BASIC is a reasonable place to start before connecting the rest.

Effective vulnerability management does not begin and end with scanning. To be effective, vulnerability management requires a solid understanding of both scanner technology and your IT infrastructure. Operationally, vulnerability management depends on having reliable and repeatable processes, well-defined ownership, integration with day-to-day IT operations, and strategic governance.

Every organization exists at a different stage of VM maturity. Some are just beginning to introduce vulnerability scanning. Others have established operational processes but lack structured prioritization, remediation tracking, or business alignment. The most mature organizations treat vulnerability management as an essential security control for mitigating exposure to emerging threats and reducing overall business risk.

A vulnerability management maturity model provides a structured way to assess the current state of your organization’s program. It helps security, IT, and business stakeholders understand where their security posture stands today, identifies “blockers” limiting progress, and defines next steps toward a more effective and sustainable vulnerability management process.

In this article, we will review a structured model for defining VM maturity. The model defines 5 levels of maturity and explains how to identify where your organization sits within the model. It also describes the limitations that each level imposes on resilient operational cyber security.

Understanding the 5 Stages of Vulnerability Management Maturity

Vulnerability management maturity can be divided into five levels. Each level reflects a different stage of discipline, operational capability, organizational involvement, and governance maturity. Organizations typically progress from basic technical scanning toward a risk-driven security program that is integrated into IT operations and continuously improved based on measurable KPI outcomes.

Stage 1 – Ad-hoc

At the Ad-hoc stage, vulnerability management is typically a brand new activity to an organization, or being performed inconsistently. Scanning is not formally scheduled, and there are no documented security processes. The organization may have a scanning tool installed, but scan coverage is unmeasured and results are not systematically used to drive remediation.

The informal mindset at this stage is often: “We’ll scan it somehow.” While this attitude and raw effort may provide some initial visibility, it does not constitute a reliable vulnerability management program.

The Limitations of an Ad-hoc / Initial Security Program

The main limitation at this stage is the absence of structure. Without a complete asset inventory, an organization doesn’t know if critical systems are being scanned. Without a defined scope or schedule, scanning activity remains an afterthought. Without clear ownership, discovered vulnerabilities may not be communicated to the correct teams for remediation.

Common limitations include:

• No complete asset inventory
• No defined scan scope or schedule
• No ownership or responsibilities
• No reporting or KPIs
• No structured remediation process

Stage 2 – Repeatable / Operational

At the Repeatable / Operational stage, vulnerability scanning is more consistent. Regular scans are performed, basic operational stability exists, and the organization has initial visibility into vulnerabilities across part of its environment. This level represents an important transition from informal activity to repeatable execution. An organization now reliably performs scans on a recurring basis, and some responsibilities for the vulnerability management program have been assigned, such as administrator or technical owner.

An organization may be scanning systems regularly, but it has not yet established a fully managed process for auditing, prioritizing, tracking, and remediating vulnerabilities.

The Limitations of a Repeatable / Operational Security Program

This Repeatable / Operational stage is still primarily technical. The main limitation at this stage is that vulnerability data is not yet effectively managed through a structured lifecycle. Organizations know where vulnerabilities exist, but lack a formal process for deciding which issues matter most, who should fix them, and by when. Governance is limited to basic reporting, without KPI-driven management or formal performance targets.

Common limitations include:

• No structured prioritization
• No defined remediation SLAs
• Limited tracking of remediation
• Weak cross-team collaboration

Stage 3 – Defined / Managed

At the Defined / Managed stage, vulnerability management becomes structured and measurable. An organization has established processes for identifying, prioritizing, remediating, and tracking vulnerabilities. Responsibilities are clearly assigned across relevant stakeholders, including IT and security teams. This level marks the point where vulnerability management becomes a managed operational process rather than a scanning activity.

An organization at this stage uses KPIs to measure performance, applies risk-based prioritization, and follows well-defined remediation workflows. Scan coverage is verified, and authenticated scanning is in place for defense in depth.

A Level 3 program can answer important management questions: Which vulnerabilities are most important? Who owns remediation? How long does remediation take? Are teams meeting defined targets? Where are recurring issues appearing?

The Limitations of a Defined / Managed Security Program

A program at this level is structured but not automated or deeply integrated. Processes are documented and measurable, but execution still depends largely on manual coordination. Integration of scanning infrastructure with IT operations, ticketing, patch management, or change management is non-existent or incomplete.

Common limitations include:

• Limited automation
• Weak integration into IT processes
• Limited business alignment

Stage 4 – Integrated / Controlled

At the Integrated / Controlled stage, vulnerability management is firmly integrated into IT operations. The program is no longer managed as a separate security activity; it is integrated into the operational systems and workflows that control infrastructure, applications, patching, change management, incident response, and service management.

Processes at this stage are automated and scalable. Vulnerability findings can be converted into tickets, assigned to the correct owners, tracked through remediation, and measured against defined targets. Integrations with ITSM, SIEM, patch management, and related operational systems enable end-to-end visibility and control. Overall, an organization can manage vulnerability remediation with more consistency, accountability, and operational efficiency.

The Limitations of an Integrated / Controlled Security Program

The main limitation at this stage is a lack of strategic optimization. An organization has strong processes and integrations, but isn’t using vulnerability management data for feedback into long-term strategic planning, investment planning, or continuous optimization.

Common limitations include:

• Limited strategic steering
• Optimization potential not fully leveraged

Stage 5 – Optimized / Strategic

At the Optimized / Strategic stage, vulnerability management is risk-driven, continuously improving, and strategically aligned with business objectives. An organization not only treats vulnerabilities as technical defects; it evaluates them in the context of business risk, asset criticality, threat exposure, operational impact, and security strategy.

Continuous improvement is embedded into programs at this level. Metrics, remediation data, recurring vulnerability patterns, exception handling, and risk decisions are used to refine the vulnerability management process over time. Vulnerability management becomes part of a broader security governance and risk management capability.

The Limitations of an Optimized / Strategic Security Program

There are typically no major structural gaps at this maturity level. The program is stable, integrated, governed, and strategically aligned. Remaining limitations are considered optimization opportunities rather than foundational weaknesses.

Common optimization areas may include:

• Refining risk models
• Improving automation accuracy
• Enhancing business context
• Reducing remediation friction
• Improving predictive and trend-based analysis

Summary

Vulnerability management maturity is about much more than whether an organization owns a scanning tool and how often scans are conducted. As organizations progress from Ad-hoc maturity to an Optimized / Strategic vulnerability management program, the process evolves from a technical one into a strategic security capability.

At its core, VM maturity is defined by how consistently an organization can identify vulnerabilities, prioritize them based on risk, assign ownership, track remediation, measure performance, and improve the process over time. An immature program provides occasional visibility, but cannot reliably guarantee that risk is reduced to an acceptable level. A highly mature program connects technology, process, organization, and governance into a controlled lifecycle.

Once an organization understands its existing maturity level, it can plan practical next steps. Asset coverage will improve, standards and process will be well understood by stakeholders, and well-defined ownership and SLAs will ensure reliable and effective results. The overall result is a strategic reduction in business risk.