Procurement contracts do not define enterprise software security boundaries

When an advisory announces critical PHP vulnerabilities, “Our main systems are not written in PHP” is not enough to rule out exposure.

An enterprise does not have to choose a technology directly for it to enter its systems. It may arrive inside a third-party product, or serve as the runtime behind functionality that business teams never see. The PHP2Shell repository maintained by the Netherlands' National Cyber Security Centre, NCSC-NL, includes information for investigating third-party products that depend on or embed PHP. [1]

Understanding the software an enterprise uses requires at least three perspectives: what it builds itself, what it buys or commissions from others, and what those applications depend on underneath.

That third layer is not a separate collection of software alongside the first two. It is inside them: operating systems, language runtimes, open-source components, base images, and the further components on which they depend.

Procurement records answer “What did we buy?” Dependency records answer “What does it need to run?” These are not the same inventory.

Contracts matter, of course. They can specify who supplies information, who delivers patches, and who provides support. But contracts alone cannot establish the scope of technical impact. When a component has a problem, the investigation needs to follow the dependency chain to the systems that use it, not stop at a supplier's name.

1. An inventory should not end at a component name

A software bill of materials, or SBOM, helps an enterprise understand which components make up its software. It is a record of the software's ingredients, not an inventory that automatically covers every business function, deployment location, and responsible owner across the enterprise. [2]

“We have collected SBOMs from our suppliers” is therefore only a starting point. Those records still need to be connected to asset and vulnerability management so that a vulnerability advisory can be traced to deployed products containing the relevant component. Guidance on SBOM consumption from CISA and other agencies describes precisely this kind of connection. [3]

For enterprise management, it is worth taking the question one step further: once a component has been identified, who can you turn to?

Suppose an inventory shows that a product contains PHP. The enterprise still needs to know where that product is deployed, whether it is still in use, which entry points are externally accessible, what business functions it supports, which team maintains it, and who can authorize temporary access restrictions.

Without those connections, the security team receives little more than a technical term, and the business team receives another email to forward.

Nor should the inventory appear only at handover and acceptance. As software versions, deployments, and maintenance responsibilities change, the associated records should change with them. Otherwise, the documentation may be comprehensive without being able to describe what is running in production now.

A useful inventory should ultimately connect a vulnerability to a system on which someone can act, not merely to a row containing a component name.

2. From “contains this component” to “this system is affected,” evidence is still needed

Finding a component does not justify either extreme conclusion: declaring every such system exploitable, or assuming there is no risk simply because no attack has yet been detected.

CISA's technical document on Vulnerability Exploitability eXchange, or VEX, distinguishes four statuses: affected, not affected, fixed, and under investigation. A “not affected” determination requires a corresponding justification or impact statement. This distinction is a reminder that a component inventory and an impact assessment are not the same thing. [4]

In the case of these PHP vulnerabilities, the official fixes released on October 21, 2026 were versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12. They addressed two critical vulnerabilities that could allow unauthenticated remote code execution. On October 23, 2026, PHP issued an additional risk advisory concerning a rare combination involving session configuration and switching at runtime. [5]

That means an investigation cannot end with copying down a set of version numbers. It also needs to check the vulnerabilities covered by the advisory, the actual product, how it is deployed, and the conditions under which the advisory applies.

Version numbers themselves also need interpretation. Some distributors apply security fixes to older versions they still maintain, a practice known as backporting. Red Hat explicitly documents this approach. A vendor package whose version appears to predate the upstream fix is therefore not necessarily unpatched. Conversely, “the vendor probably backported it” is no substitute for evidence. The specific package version needs to be checked against the vendor's security advisory. [6]

For a system whose status is not yet supported by evidence, the most honest designation is “under investigation.”

Not knowing whether a supplier uses PHP does not mean it does not. Receiving no vulnerability notification does not mean a system has been confirmed unaffected. And a supplier saying “we are assessing it” does not mean the enterprise can stop following up.

“Unknown” should come with an owner and a time for the next check, rather than quietly being counted as “safe” in a status report.

3. A fast response needs someone authorized to accept the trade-offs

Knowing that a system is affected does not automatically mean an enterprise is ready to act.

Suppose an externally facing service needs patching. The technical team can prepare an upgrade, but it may require a brief outage. The business team does not want orders disrupted, and the supplier has not finished validation. What is missing may not be another technical recommendation, but a clearly designated decision-maker.

Who can approve temporarily closing a high-risk entry point? Who can accept a brief reduction in service? If the upgrade is deferred, who acknowledges the residual risk, and when will it be reassessed?

These questions should have answers before an incident, rather than leaving an emergency meeting to search for someone with authority to decide.

For this PHP incident, CERT-EU recommends patching affected assets immediately. Where timely patching is not possible, it advises considering isolating internet-facing applications from public networks until the fixes have been applied and verified. [7]

The point is not to shut down every system indiscriminately. It is that “we cannot upgrade yet” should not be taken to mean “we do not need to do anything yet.” Feasible interim measures should be selected according to the specific exposure, business impact, and official guidance, with their limitations made explicit.

Temporary safeguards buy time for remediation; they should not become a reason for indefinite delay. Waiting for a patch should itself be a decision with an owner and a scheduled review.

4. “The patch is installed” still needs to pass an operational check

The supplier has released the patch, operations has installed it, and the ticket is closed: these describe different stages. None, on its own, can substitute for confirming the current state of the running system.

NIST's enterprise patch management guidance explicitly includes verification in the process: confirming not just that a patch has been installed, but that it has taken effect. Depending on the circumstances, that may require restarting software, redeploying it, or changing its configuration, followed by ongoing checks that the protection has not been undone. [8]

A credible remediation record should therefore show which running instances have the fix in effect and which remain outstanding; whether critical business functions are operating normally; whether temporary safeguards are still needed; and whether a rollback would reintroduce an unpatched version.

Acceptance should be based on the environment actually supporting the business, not on an installation command that exited successfully.

Another question needs to be addressed separately: had the system already been compromised before it was patched?

Microsoft's official response guidance for the 2021 Exchange incident made clear that installing security updates would not evict attackers already inside a system. This is a response principle drawn from a historical example, not a claim that any particular system in the current PHP incident has been attacked. When an intrusion is detected or suspected, vulnerability remediation and incident investigation need to proceed in parallel. Successful patching cannot replace investigation and removal of the intrusion. [9]

Patching closes the entry point. Investigation establishes what happened in the past. Recovery checks establish whether the environment can now be trusted. None can substitute for the others.

5. Connect supplier deliverables to the enterprise's own actions

In practice, responsibilities can be made more concrete.

Suppliers should explain whether their products are affected, the evidence behind that assessment, which versions contain fixes, and any constraints on deployment and rollback. Within the enterprise, someone needs to establish where the products are actually used, arrange changes, verify the results, and manage exceptions that cannot yet be remediated. The division of responsibilities can vary, but there should be no gap where nobody takes over. [10]

“This is an outsourced system” should help identify the right path to resolution, not bring the issue to a halt.

Likewise, a product that is no longer maintained deserves more than a note saying “no upgrade for now.” An enterprise can require each exception to document its current safeguards, a named owner, a review date, and a plan for replacement or retirement. This is a management choice, not a claim that every old system must be shut down immediately.

To test whether this process actually exists, there is no need to begin by checking how complete the flowchart looks. Choose a real vulnerability and follow it through:

• Can you identify the actual systems containing the relevant component?
• Can you produce evidence that they are affected or not affected?
• Can you identify someone with authority to decide how to respond?
• Can you demonstrate, with evidence from the running systems, that remediation is complete?

Wherever you have to start asking around again, there is a gap worth addressing first.

An enterprise cannot write, review, and maintain every line of code it uses. But it should at least know what its critical business functions depend on, who will act when something goes wrong, and what evidence will establish that the work is complete.

The chain that security management needs to connect is not “advisory → email → ticket,” but “dependency → impact → decision → operational result.”

When the next major vulnerability emerges, the enterprise should be using a path it has already established—not beginning, for the first time, to find out who is actually using the code.