IT Visibility Is No Longer A “Nice To Have”

The PHP2Shell security event is rapidly becoming a board-level conversation. Two critical PHP vulnerabilities allow unauthenticated remote code execution, and security authorities are urging organizations to patch immediately. CISA has told organizations to “identify and inventory systems running any version of PHP” while warning that PHP is often a component of other software and “may not be directly observable.” Wait, what?

“Do you know what software you have?” sounds like a basic question. Enterprises have spent decades implementing configuration management databases (CMDBs), application portfolios, software asset management (SAM) systems, discovery tools, vulnerability scanners, endpoint management platforms and, more recently, software composition analysis (SCA) and software bills of material (SBOMs). Yet PHP2Shell demonstrates how difficult it can still be to answer a seemingly straightforward question such as “Where are we running PHP?” The challenge is proving where it exists, whether it is active, whether it is exposed, and whether the evidence is complete enough to support remediation decisions. It is not enough to simply “find PHP.”

PHP can be packaged with an operating system, embedded in another product, incorporated into a software artifact, installed but inactive, or running and exposed to the internet. Different management systems see different pieces of that reality. The real question, then, is larger than, “Where is a given piece of software running?” It is: “Do we have real-time, comprehensive, and reliable visibility into our technology estate?” PHP2Shell demonstrates why the answer requires connecting evidence across systems that were built for different use cases.

PHP Is Exactly The Kind Of Software That’s Hard To Find

PHP is an open-source programming language and runtime. Many organizations acquire it through simply downloading it. There may be no procurement record, contract, license reconciliation exercise, or other commercial event signaling its presence. Nor does it necessarily appear as a neatly installed, standalone software product. PHP may be installed as an operating-system package or exposed through PHP-FPM, Apache mod_php, CGI, or other web-serving configurations. It can also be embedded in appliances, network devices, management interfaces, and third-party products.

The operational guidance assembled by the Netherlands’ National Cyber Security Centre explicitly warns organizations to check these embedded and third-party instances separately. That complicates an already difficult inventory problem.

 

Build Visibility From Multiple Forms Of Evidence

Multiple IT management and security systems collect and report on different parts of reality. None of these systems necessarily provides an incorrect view. They answer different questions using different evidence. The problem occurs when enterprises expect one system to provide a complete view.

CMDBs and enterprise architecture (EA) tools provide base inventories and dependencies, including attestation-based information like application ownership and capability/value stream/business unit mappings. Software asset and infrastructure discovery provide asset presence and usage evidence via OS package information, files, discovered executables, configuration information, and other infrastructure observations. Normalization translates messy discovered evidence into consistent vendor and product naming. These can provide evidence that PHP is installed on a particular device.

Software composition analysis and SBOMs provide another. They document software components introduced through development and software supply chains, precisely the path through which an open-source component may enter an enterprise without ever triggering a traditional procurement or software-licensing process.

Runtime and configuration evidence answers yet another question. A PHP binary sitting unused on disk is not equivalent to a PHP runtime handling web requests. A running vulnerable component may have very different risk depending on whether an attacker can reach it. For PHP2Shell, that distinction matters; obviously, internet-facing systems are more at risk. External attack surface management (EASM) and exposure-management data is another evidence source for determining whether affected technology is externally exposed.

Vulnerability and technology lifecycle intelligence then adds further context. Organizations need to know not merely that PHP exists but which version exists, whether the appropriate fix has been applied, whether the version remains supported, and potentially whether a distribution or product vendor supplies an applicable fix. PHP2Shell guidance illustrates this complexity, including upstream fixes as well as vendor-supplied and backported packages.

Finally, there is the need to reconcile conflicting evidence when discovery, endpoint, vulnerability, configuration, and other tools report different versions or states for the same asset, and none of these evidence sources replaces the others. Effective IT visibility connects them to enable insights that can be acted upon.

The CMDB Should Provide Context, Not Pretend To Be Omniscient

This is also a useful corrective to how enterprises sometimes think about CMDBs (or IT management graphs) and their close adjacency to the EA repository. A CMDB doesn’t need to become a gigantic repository into which every SBOM component, process observation, vulnerability record, software entitlement, container, and configuration datum is copied.

Dynamic workloads such as containers, Kubernetes, AI agents, and other ephemeral cloud-native workloads require a different approach, relying less on persistent inventories and more on telemetry and runtime evidence. Individual container or pod instances generally should not become durable CMDB records simply because they existed. But evidence of their execution should be retained in observability or other telemetry infrastructure, with sufficient identity and metadata to connect them to image provenance, business purpose, ownership, support status, security exposure, and cost.

The more important requirement is that an organization can navigate the relationships among them. (Well-managed IT master data — e.g., consistent names and IDs for portfolio items — is required for this to work.) For PHP2Shell, the useful chain of evidence might look roughly like this: PHP vulnerability → affected software/version → SBOM or discovered instance → deployed artifact/runtime → infrastructure → application/service → owner/business impact → remediation status.

Some of those records may reside in the CMDB. Others belong in vulnerability management, SCA, container security, endpoint discovery, SAM, application portfolio management, architecture, and/or observability platforms. And tracking the actual work of remediation should be done in service management or collaborative work management tooling to support portfolio visibility into the demand and execution in context with other work. One concrete example showing the relationship: affected PHP instance → host/workload → exposed application → business service → owner → remediation action.

The Hardest Question Is Proving That Something Isn’t There

There is an even more uncomfortable version of the PHP question: “Can you prove that we have no unpatched PHP?” Running a query against the CMDB and returning zero results doesn’t prove it. Neither does an empty SAM query, nor an SCA search, nor an SBOM repository search, nor the absence of findings from a particular vulnerability scanner or EASM. Each establishes only that the software wasn’t found by that particular mechanism within the population visible to it. For example, multiple independent evidence sources agreeing on absence creates higher confidence than absence from a single discovery source.

This distinction matters whenever an executive asks technology management for assurance. Absence from inventory is not evidence of software absence unless you understand the coverage and limitations of the inventory mechanisms. To give a defensible answer, technology leaders need to know which systems were examined, how they were examined, which forms of software the discovery methods can recognize, how current the observations are, and where coverage gaps remain. That turns software inventory from a database problem into an evidence problem. Confidence comes from correlating independent evidence about presence, runtime state, configuration, exposure, ownership, vulnerability, and business context.

 

GenAI Makes The Visibility Gap More Urgent

The PHP2Shell story has another important dimension. AI-assisted vulnerability research contributed to discovering these vulnerabilities. Regardless of the particulars of this incident, generative AI is changing the economics of finding vulnerabilities. Defenders should assume that increasingly capable researchers, vendors, security teams, and attackers will all use AI to analyze software faster. This is already happening. Vulnerability discovery is accelerating faster than the enterprise’s ability to determine whether it runs the vulnerable technology.

IT visibility is difficult to build, and its value is often questioned between crises. But the economic choice is straightforward. An organization can maintain the necessary evidence proactively, or it can repeatedly redirect scarce staff to reconstruct that evidence under emergency conditions. As AI-assisted research increases the frequency and speed of vulnerability disclosure, relying on emergency inventory exercises (aka “fire drills”) becomes increasingly costly and risky.

The answer is to mature an IT visibility capability capable of connecting contextual evidence across the software lifecycle: what entered the organization, what was built, what was deployed, what is running, what depends upon it, who owns it, where it is exposed, and where it sits in its support lifecycle. That’s the capability that organizations will need, not only for PHP2Shell but for whatever comes next.

Security and technology leaders must be able to promptly communicate exposure, remediation, residual risk, and required decisions to executive leadership. But there is a prerequisite to that conversation: You can’t confidently communicate your exposure and inform the necessary decisions if you don’t know what you have.

Share