To show what this looks like in practice, we used MCP to connect Claude Code to both Infoblox and Tenable in a lab environment. We asked Claude the kinds of questions security analysts deal with every day. Claude turns each question into calls against both platforms, joins the results on IP and MAC address, and returns one answer. The following are three of those conversations.<\/p>\n
![](\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/tenable-image1.jpg\")
<\/p>\n
Figure 1. Architecture: Correlating Tenable vulnerability findings with Infoblox network identity<\/p>\n
Use Case 1: Risk-Ranked Asset Triage across the Engineering Subnet<\/h3>\n
The first question is a familiar one: Which devices should we fix first?<\/p>\n
Which devices in our engineering subnet have the highest asset criticality and active critical vulnerabilities? Rank using the findings index for active criticals rather than asset-level counters. For the top 5, look up each one\u2019s network identity in Infoblox \u2014 DNS record, DHCP reservation and MAC. One table: hostname, IP, MAC per Tenable, MAC per Infoblox, identity status, ACR and the most serious active critical finding \u2014 prefer a named CVE over a rollup KB where one exists. Where Tenable has no MAC or hostname, mark identity \u201cInfoblox-only\u201d.<\/pre>\nClaude started by resolving \u201cEngineering Subnet\u201d from Infoblox IPAM to 10.20.30.0\/24, which matched 57 Tenable assets. It then counted active critical findings per asset directly from Tenable\u2019s findings index instead of relying on asset-level counters, which can lag behind. It ranked assets by Asset Criticality Rating (ACR) first and used the active critical count to break ties. Counting from the findings index changed the result. Three assets with an ACR of 8 dropped out of the ranking because they had zero active critical findings. Tenable assigns ACR on a 1\u201310 scale based on what an asset is, such as its device type, business function and internet exposure, not on its vulnerabilities. A high-ACR asset with nothing critical to patch is important, but it isn\u2019t the first thing to fix. For the top five, Claude pulled each device\u2019s DNS A record, DHCP reservation and MAC address from Infoblox.<\/p>\n
Table 1. Claude Code output showing the risk-ranked table for the engineering subnet<\/strong><\/p>\n
\n\n
\n \n#<\/th>\n Hostname<\/th>\n IP<\/th>\n Identity Status<\/th>\n ACR<\/th>\n Active Criticals<\/th>\n Most Serious Active Critical<\/th>\n<\/tr>\n<\/thead>\n \n 1<\/td>\n srv-app02<\/td>\n 10.20.30.56<\/td>\n Confirmed in both systems<\/td>\n 9<\/td>\n 21<\/td>\n WinVerifyTrust signature validation (CVE-2013-3900)<\/td>\n<\/tr>\n \n 2<\/td>\n srv-lnx08<\/td>\n 10.20.30.17<\/td>\n Tenable-only<\/td>\n 8<\/td>\n 23<\/td>\n polkit pkexec local root, PwnKit (CVE-2021-4034)<\/td>\n<\/tr>\n \n 3<\/td>\n vc-mgmt01<\/td>\n 10.20.30.39<\/td>\n Infoblox-only<\/td>\n 8<\/td>\n 1<\/td>\n vCenter 8.0 directory traversal (VMSA-2026-0006)<\/td>\n<\/tr>\n \n 4<\/td>\n hv-host01<\/td>\n 10.20.30.54<\/td>\n Infoblox-only<\/td>\n 8<\/td>\n 1<\/td>\n ESXi 7.0\/8.0 multiple vulnerabilities (VMSA-2025-0004)<\/td>\n<\/tr>\n \n 5<\/td>\n ad-dc01<\/td>\n 10.20.30.10<\/td>\n Confirmed in both systems<\/td>\n 7<\/td>\n 65<\/td>\n Apache Log4j RCE, Log4Shell (CVE-2021-44228)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n A ranked list is useful on its own. With network identity attached, it also tells the analyst what each risk actually means:<\/p>\n
\n
- The domain controller ranks fifth, but it may be the sharpest exposure. Because the ranking puts ACR first, ad-dc01\u2019s ACR of 7, the lowest in the top five, places it last. Yet it has 65 active critical findings, nearly three times as many as any other asset in the table. They include Log4Shell, which allows unauthenticated remote code execution on the host that owns authentication for the whole engineering zone. A domain controller rated 7 is worth a second look. If its criticality is understated, it belongs at the top of the list.<\/li>\n
- Both VMware management interfaces are reachable and unpatched. vc-mgmt01 (10.20.30.39), the vCenter Server that manages the virtual infrastructure, and hv-host01 (10.20.30.54), an ESXi hypervisor host, each have an open critical VMware advisory. An attacker who lands anywhere in the subnet can reach vCenter, and from there every guest it manages, including ad-dc01.<\/li>\n
- srv-lnx08 is the identity gap to close. It has an ACR of 8, 23 active critical findings and unpatched PwnKit, but no Infoblox DNS record or DHCP reservation at all. Because it holds its address outside the IPAM system of record, it won\u2019t appear in any address-based inventory or policy scoped from Infoblox.<\/li>\n<\/ul>\n
The ranking is a starting point, not the final word. Infoblox tells you whether you can trust what you\u2019re looking at.<\/p>\n
Use Case 2: Identity Gap Analysis to Close Blind Spots with Infoblox<\/h3>\n
The second question flips the problem around. Instead of asking what is most vulnerable, it asks what the scanner can\u2019t fully identify.<\/p>\n
Which critical assets in the engineering subnet have no hostname or MAC address recorded in Tenable? For each, check whether Infoblox can supply that missing identity from DNS or DHCP. Show me a table of what each system knows.<\/pre>\nTwelve assets in the subnet had no MAC address in Tenable, and nine of those also had no hostname or FQDN. By checking Infoblox DNS and DHCP, Claude closed the gap on six of them.<\/p>\n
Table 2. Claude Code output comparing what Tenable and Infoblox each know about unidentified assets<\/strong><\/p>\n
\n\n
\n \nAsset Group<\/th>\n What Tenable Knew<\/th>\n What Infoblox Supplied<\/th>\n<\/tr>\n<\/thead>\n \n Hypervisor management interfaces (hv-host01, vc-mgmt01, vc-mgmt02)<\/td>\n OS fingerprint only<\/td>\n DNS name and DHCP reservation MAC<\/td>\n<\/tr>\n \n macOS endpoints (mac-host1, mac-host2, mac-host3)<\/td>\n NetBIOS name only<\/td>\n FQDN and DHCP reservation MAC<\/td>\n<\/tr>\n \n Six remaining hosts, including 10.20.30.1, 10.20.30.12 (SonicOS) and 10.20.30.26 (ESXi 9.0)<\/td>\n OS fingerprint or nothing<\/td>\n No record; unresolved in both systems<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The result goes past a data-quality report:<\/p>\n
\n
- All three of the highest-criticality unidentified assets are hypervisor management interfaces. Infoblox names two of them. The third, 10.20.30.26 (ESXi 9.0, ACR 8), doesn\u2019t exist in either system. It\u2019s a hypervisor with no owner, no name and no reservation, and it\u2019s the one to chase first.<\/li>\n
- 10.20.30.1 and 10.20.30.12 are almost certainly the subnet gateway and firewall. Those are the devices that define the blast radius, and neither system can attribute them.<\/li>\n
- The pattern points to credential coverage, not data quality. Every one of the twelve assets is an unauthenticated scan target. That explains why Tenable has an OS guess but no hostname or MAC. Adding scan credentials for the ESXi and vCenter hosts would let Tenable resolve identity and improve finding fidelity in the same pass.<\/li>\n<\/ul>\n
Use Case 3: MAC-to-Vulnerability Pivot from DHCP Reservation to Full Risk Posture<\/h3>\n
Investigations often start with a single identifier and nothing else. In this case, it was a MAC address.<\/p>\n
Infoblox has a DHCP reservation for MAC 00:50:56:b1:2d:9e. Work out which device that is, then pull its full vulnerability posture from Tenable.<\/pre>\nIn eight tool calls, Claude traced the device end to end. The MAC address matched a single DHCP fixed-address reservation in Infoblox: srv-app02, holding 10.20.30.56 in the Engineering Subnet. A forward DNS A record confirmed the mapping. The same IP then resolved to a Tenable asset running Windows Server 2019 Standard. With an ACR of 9, it\u2019s the highest-criticality asset in the subnet, and it has never had an authenticated scan.<\/p>\n
Table 3. Claude Code output tracing the MAC address through Infoblox to the device\u2019s Tenable posture<\/strong><\/p>\n