For two weeks in July, I kept having the same conversation with clients. An executive would ask what sounded like a simple question: Are we exposed, and how bad is it? Nobody in the room could answer it, and not because the people weren’t good. I want to explore that gap and what to do about it.
My career has run across networking, infrastructure, and security operations, not one of them in isolation but all three tangled together. That end-to-end vantage point trains you to see what a single-discipline view often misses. You stop looking at components and start looking at paths. When one thing fails, what else falls with it? Which dependency is missing from the diagram?
That’s the lens I want to hold over this summer: the panic, where it really came from, and why so many capable teams spent an entire month reacting to a wave everyone saw coming.
This summer’s urgency wasn’t about a specific flaw. It was about the distance between a fair question from leadership and a defensible answer. In most organizations, that distance is longer than people may want to concede.
Walk that distance with me. You start at an asset inventory that’s broadly right and specifically wrong. You pass a configuration database that describes last year’s environment. You hit edge firmware nobody owns, operational segments where even scanning requires a change request, hundreds of suppliers, and thousands of applications. Panic results when you stand at one end of that distance and your CEO waits at the other.
The complexity worsens with scale. Infrastructure has its inventory, security has its scanning tools, and operations has its change records. Although each is accurate about its own slice, nobody owns the combined picture until an incident forces someone to assemble it in the middle of the night.
The teams that stayed calm in July weren’t the ones with the best tools. They were the ones who could name the 20 systems that mattered most, tell me what each connected to, and then describe what would fall over if any of them were breached.
It didn’t come down to budget, headcount, or tooling. It came down to knowing your own environment well enough to draw it.
We’ve all watched the attack surface grow for years. What changed is where the pressure concentrated: firewalls, VPN concentrators, SD-WAN gear. These are appliances that face the Internet by design and can’t be rebooted in the middle of the afternoon.
National cyber agencies have spent this year saying the same thing, and the guidance has hardened from suggestion into schedule: Find your unsupported edge devices, inventory them, and get the oldest out on a defined timeline. If your board asks what good looks like for edge lifecycle, that’s the answer, and it doesn’t change based on where you operate.
The reason is simple. The edge is the part of the network we’re worst at seeing into. An attacker on a domain controller trips a dozen alarms; an attacker living quietly inside a VPN appliance often trips none. This isn’t a vendor problem, so please don’t read it as one. Attackers go where deployment is widest and visibility is thinnest, and right now that’s the boundary.
There’s a trap here that many capable teams have walked into: fixing the edge and considering the job done. The application and identity layer is under the same pressure. It just makes quieter headlines. Web applications and remote access sit at the top of what attackers reach for, and increasingly they walk through the front door rather than bother stealing a password. Your applications are the front door, and it’s being tried harder than it has been in years.
Underneath these applications sits an often-overlooked supply chain. Open-source components are now being audited at machine speed, and the audits are surfacing thousands of real bugs. Finding the bugs was never the bottleneck. It’s fixing them, given that so much critical infrastructure depends on a volunteer maintainer with a day job and a full inbox.
If your stack includes open source (and it does), part of your attack surface is queued behind someone doing this in their spare time.
If I could get every technology executive to absorb one idea from this summer, it would be this: Attackers got faster than we did, and it isn’t close.
For years, the industry ran on the comfortable assumption that turning a fresh vulnerability into a working exploit was slow, difficult work, and that delay bought defenders time. Our entire patch cadence was built on that gap. It’s gone. The moment a flaw is known, and increasingly the moment a fix ships, a working exploit is close behind. The same machine intelligence that finds the bug can build the attack, all while our side still measures serious remediation in weeks. If anything, we’re slowing down, not speeding up.
Exploitation in hours. Remediation in weeks. No amount of tuning closes a gap shaped like that, and telling an already-stretched team to patch faster is a wish, not a strategy. The assumption the entire program was built on — “we have time” — is what broke this summer, and most of us haven’t yet updated the plan to reflect that.
That doesn’t mean speed stopped mattering. It still does. But this summer showed that speed can’t carry the whole load on its own, and I’ll come back to what fills the gap.
One caution: More is not the same as worse. The raw count of new fixes is climbing, but volume isn’t risk. The slice being turned into working attacks is far smaller than the total. A team that treats every advisory as a five-alarm fire will be exhausted and sloppy by the time the one that matters lands. The discipline isn’t patching everything faster. It’s knowing which few things, if chained, reach something you can’t afford to lose.
I won’t pretend OnX floated above this. Most of the work I touched in July and August was reactive, including inside organizations with mature programs and good people.
Our processes were built for a calmer world, where a weekly change window was plenty. That cadence, sensible for years, quietly became the exposure itself. Yet the deeper problem was structural, the kind of thing you see clearly if you think in dependencies.
In most environments, nobody owned the whole path. Networking owned the segment, a platform team owned the box, security owned the finding, and an approver owned the change window. Each did their part correctly, and the route from exposed system to crown-jewel data sat unowned in the gaps between them. When the moment came, the failure was rarely one person dropping the ball. It was that no single person could see or act on the whole chain at once.
The organizations that came through better had all made the same shift, and it’s an end-to-end shift rather than a patching one. They stopped asking only how fast can we patch, and started asking a blast-radius question: When one thing is breached (and, eventually, one thing always is), how far does the damage travel?
That question has a different set of answers. They’re about how the environment is carved up, how much a single compromised box can reach, and how many doors quietly open once an attacker is inside one. The short version: Don’t just patch faster. Fail smaller.
I’ll explore this further in the next post. In the meantime, please get in touch if you would like help assessing your organization’s posture. If you’re attending the Banff Cyber Summit, November 3–5, come hear Ryan Hamrick, OnX Senior Director of Cybersecurity, speak about what it takes to build a security operating model for a world where critical vulnerabilities can be weaponized in hours, not days. Ryan will share how OnX translated the Cloud Security Alliance’s “AI Vulnerability Storm” into an operational response model spanning patching, SOC, compute and network, including what worked, where the model met resistance, and what organizations should be pressure-testing now.
And while you’re there, be sure to stop by the OnX booth to connect with our team.