The Math Got Worse, and It Happened Faster Than Expected
If you’ve been running infrastructure for more than five years, you’ve probably developed a certain skepticism about security vendor announcements. They tend to paint apocalyptic pictures to justify their next round of pricing increases. But when I read through the CrowdStrike 2025 Global Threat Report, something landed differently. The numbers weren’t just bad. They were directionally worse in ways that matter for teams like ours.
Last year, the average breakout time—that critical window between when an attacker gets initial access to your environment and when they start moving laterally through your systems—was 84 minutes. In 2024, it dropped to 62 minutes. Twenty-two minutes might not sound like much until you realize what it means: adversaries are shrinking the window in which your detection and response systems have to actually work. If your incident response process assumes you have 90 minutes to notice something weird on an internal server, you’re operating on assumptions that are now outdated.
What bothers me more is what this number actually represents. It’s not that attackers got faster at lateral movement in some absolute sense. It’s that our environments have become easier to navigate once someone’s inside. That usually points to one thing: we’ve built systems that are operationally convenient at the cost of security visibility. Most of us did this intentionally, because the alternative—security controls that actually slow things down—felt like it would break productivity.
The Cloud CI/CD Frontier Nobody Talks About Enough
Here’s a concrete example of where that convenience is biting us. The report documented a 150 percent year-over-year increase in adversary activity targeting cloud environments, with attackers specifically hunting for exposed CI/CD pipeline credentials. This isn’t theoretical. If your deployment pipeline can be accessed by someone who found an old AWS access key in a GitHub repository, or who compromised a junior developer’s laptop, they don’t need to break in through your front door. They can just build and deploy whatever they want directly.
Most mid-size engineering teams haven’t fully instrumented their CI/CD environments with the same scrutiny they’d apply to production systems. Your Kubernetes cluster probably has decent logging. Your CI/CD pipeline probably doesn’t. You’re scanning containers for vulnerabilities at deployment time, but you might not be tracking who accessed what build secrets, when, and from where. These gaps don’t feel dangerous until someone walks through them.
Building secure CI/CD visibility is fundamentally different from buying another endpoint detection tool. You need to understand the identity and access patterns in your pipeline. You need to know when a service account’s credentials are being used from an unusual location or at an unusual time. You need to see when someone modifies a build configuration that affects what gets shipped to production. These are detection problems, sure, but they’re also architecture problems. You can’t bolt security onto a system that was never designed to be observable in these ways.
Why the Platform Consolidation Story Should Make You Uncomfortable
According to Gartner’s analysis, enterprise security buyers are consolidating around single vendors at an accelerating rate. In 2022, 31 percent of large organizations were purchasing security as a platform, combining endpoint detection and response, cloud security posture management, and identity threat detection from one vendor. By 2025, that number had jumped to 58 percent. The logic is obvious: fewer integrations to manage, a unified data model, simpler licensing conversations.
But there’s a darker side to this shift, and it has a name: July 24, 2024. That’s when a faulty update to the CrowdStrike Falcon sensor caused approximately 8.5 million Windows devices worldwide to crash simultaneously. If you were one of the organizations that had consolidated your endpoint protection, your cloud security monitoring, and your threat detection into a single vendor stack, and that vendor released a bad update, you didn’t just lose endpoint visibility. You potentially lost visibility across multiple layers of your security architecture at the same moment. A lot of teams are still processing what that means for them.
This doesn’t mean you should reject platform consolidation entirely. It means that consolidation without carefully thought-through redundancy is a bet you should make consciously, not by accident. If you’re going to use one vendor for multiple critical functions, you need a plan for what happens when that vendor fails. Maybe you run dual agents in certain environments. Maybe you keep a secondary CSPM tool with limited scope just to verify critical configurations. Maybe you build internal tooling to validate your vendor platform’s output independently. The cost of that redundancy is real, but it’s less than the cost of being blind during an incident.
Patch Timelines Are Not What They Were, and You Need to Accept That
The CISA Known Exploited Vulnerabilities Catalog has grown to over 1,200 entries, and analysis from security teams shows that roughly 40 percent of these vulnerabilities are actively being exploited within 48 hours of public disclosure. That’s not a best-case scenario you’re planning for. That’s the new baseline.
Most mid-size organizations are still working with patch timelines that assume you have days or weeks between disclosure and active exploitation. You’re probably running something like: critical patches in 48 hours, high-severity patches in 7 days, medium-severity patches in 30 days. Those timelines were reasonable when exploitation took weeks. If 40 percent of disclosed vulnerabilities are being actively exploited within two days, your 7-day window for high-severity patches means you’re running unpatched, actively exploited code in production for seven days. That’s a real gap.
This doesn’t mean you need to patch everything in 24 hours—that’s not operationally feasible for most teams, and it introduces its own risks. What it means is that you need to know which vulnerabilities affecting you fall into that exploited-within-48-hours category, and for those, you need faster than seven days. You need asset visibility good enough to tell you, within hours of a CVE disclosure, whether you’re running vulnerable software. You need a patch process that can be accelerated when necessary. And you need monitoring in place so that if you miss the window, you at least know when someone tries to exploit the vulnerability.
Starting with What Actually Matters
If you’re sitting here feeling overwhelmed, that’s reasonable. The threat landscape has genuinely gotten more aggressive, and the operational overhead of staying ahead of it has increased. But you don’t need to solve everything at once, and you shouldn’t try to solve it by just buying a bigger platform from one vendor.
Start with the detection problem that would hurt you most if you missed it. For most teams, that’s either lateral movement in your cloud infrastructure or unauthorized changes to your deployment pipeline. Pick one. Instrument it properly. Get to the point where you can answer these questions with confidence: who accessed what, when, and from where? What changed, and who changed it? Can I reconstruct the sequence of events that led to this incident? Once you have clear answers to those questions, you can build detection logic on top of that visibility. The vendor tools will be more effective because you’ve already done the hard work of understanding your own systems.
The platformization trap is assuming that buying more tools from one vendor automatically makes you more secure. It doesn’t. What makes you secure is understanding your systems, knowing what normal looks like, and detecting when things deviate from that baseline. You can use vendor tools to help you do that, but the foundation has to be your own clarity about what you’re protecting and why.
What’s your biggest visibility gap right now? The thing that would terrify you most to discover during an incident? Let’s talk about how to start closing that gap. The conversation doesn’t need to start with vendor selection. It should start with what you actually need to see.
