The Software Under the Software

When a vulnerability becomes as widespread as PHP2Shell, the first question inside most organizations is predictable.

Are we vulnerable?

That’s the right question. Two critical vulnerabilities in PHP are being actively exploited, and CISA and the NSA are urging organizations to identify affected systems and patch them quickly. Because PHP sits underneath so many websites and applications, this isn’t a vulnerability affecting one product that can simply be handed to one application owner. There’s another question I find just as interesting.

Do we actually know where we’re running PHP?

Most of us think about architecture in terms of the systems we can see. There’s the application, the database, the API, the cloud environment and the infrastructure connecting everything together. We diagram those systems, assign owners to them and generally have some idea of what they do, but underneath all of that is another architecture.

Applications depend on runtimes and frameworks. Those depend on libraries and packages. Containers inherit components from base images. Operating systems bring their own dependencies. Applications trust certificates issued through infrastructure most of us will never directly manage, and eventually you reach pieces of technology that nobody inside the organization consciously decided to deploy because they arrived due to something else that needed them.

Most of the time, that’s fine. Modern software couldn’t function if every organization built and maintained every component itself. The problem appears when something several layers down suddenly matters.

PHP2Shell is a good example. The affected component may be sitting underneath an application everyone knows about, inside a third-party product, or running somewhere that hasn’t received much attention in years. Security guidance for the vulnerabilities specifically recommends looking for runtime evidence rather than relying only on asset records, including PHP bundled inside third-party products. That distinction matters.

Your inventory may tell you that you have a web server. Your application documentation may tell you what business service runs on it. Neither necessarily tells you everything that service depends on.

We got another reminder of that this week when a malicious version of LiteLLM was distributed through PyPI and Docker after its release infrastructure was compromised. Organizations didn’t need to intentionally install malware to inherit the risk. They needed to depend on software that had been compromised somewhere upstream.

The eMudhra certificate incident takes the same idea in a different direction. Eight intermediate certificate authority private keys could be recovered because of weaknesses in how they were generated. Browser and operating system vendors then had to respond by removing or blocking trust in affected certificate chains. An organization could have perfectly healthy applications and still discover that something those applications trusted had changed underneath them.

None of this means we need a perfect map of every dependency in the enterprise. I’m not sure such a map could stay perfect for very long. But we can get better at looking beneath the systems that matter most.

Start with a few important internet-facing applications and go one layer deeper than your normal inventory. Identify the runtime, framework, web server, major libraries or packages, operating system and external trust dependencies supporting them. You don’t have to map the entire organization to learn something useful. Then give the important dependencies an owner.

Someone should understand why a critical component is there, how it gets updated, what depends on it and what happens when it becomes vulnerable or unsupported. Discovering an old runtime is useful. Discovering an old runtime that nobody owns explains how it stayed old.

This is where tools organizations already have can help. Vulnerability scanners, endpoint platforms, cloud inventories, configuration management systems, software bills of materials and application documentation may each contain part of the answer. Before buying another discovery platform, it may be worth asking whether the information already exists and simply hasn’t been connected.

I like approaching this from the outside inward.

Start with the systems exposed to the internet because that’s where unknown dependencies can become urgent quickly. Move next to critical business applications. Then follow those systems downward into the platforms, runtimes and components supporting them.

Each pass reveals a little more of the architecture.

That’s valuable even after PHP2Shell disappears from the headlines, because there will always be another vulnerability in a framework, library, certificate authority, package repository or runtime that most people hadn’t thought about the week before.

When that happens, the organizations in the best position won’t necessarily be the ones with the most complete inventory.

They’ll be the ones that can answer the next question quickly.

Where do we depend on this?

Good architecture isn’t just knowing what you built. It’s knowing what your systems are built on.