AI is accelerating vulnerability discovery faster than most organizations can respond - and the gap is widening. Ashley Ward, Principal Solutions Architect at Minimus, reframes this not as a security problem but as an operational one, and offers a pragmatic framework for platform engineers to close that gap through automation, reduced attack surface, and resilience-first design.

Main insights

• AI is accelerating vulnerability discovery rates, but the core problem is operational - your throughput hasn't kept pace with the rising arrival rate of work
• The cheapest vulnerability to fix is the one you never ship - reducing your software footprint dramatically cuts your exposure
• Platform engineering changes the economics by making classes of problems cheap to handle through automation, containment, and rapid recovery
• Success isn't measured by CVE counts, but by resilience metrics like rebuild time, deploy time, and recovery rate

Ashley Ward brings extensive leadership experience from roles including Group CTO at a publicly listed company and Technical Director in the Office of the CTO at Palo Alto Networks. As a Non-Executive Director on the OpenUK board, he champions open software and standards while helping organizations strengthen trust and resilience across cloud-native environments.

You can watch the full discussion here if you missed it.

The economics problem, not a technology problem

Ashley opens with a thought experiment that reframes the entire conversation: "Imagine that people in Google's Project Zero or Trail of Bits or Microsoft Threat Intelligence Center - security researchers - they all now start examining your organization. They're not going to fix anything. They're simply going to tell you everything they find. Would you be more secure?"

The answer is clearly no. You'd simply have more work than you can handle.

This is Little's Law in action: when the arrival rate of work increases but throughput stays constant, queues grow indefinitely. AI-enhanced tools and modern fuzzers iterate faster and probe deeper than traditional scanners, increasing discovery velocity in ways that conventional triage and patching workflows were never built to absorb. The DARPA AI Cyber Challenge demonstrated this empirically - between semifinal and final rounds, team scores in identifying synthetic vulnerabilities jumped significantly, and while patching capability improved, discovery improved faster.

This isn't a one-time tsunami. It's a sustained structural shift in the economics of vulnerability discovery.

Why some teams will drown

Three factors determine whether your organization can cope with rising discovery rates:

• Signal vs. noise: Real vulnerabilities and high-impact misconfigurations are signal. False positives, duplicate scanner results, low-impact CVEs, and unreachable packages are noise. As discovery rates rise, your ability to separate the two becomes a competitive advantage.
• Capacity constraints: Capacity isn't just headcount - it includes platform maturity, automation depth, and your ability to rebuild and redeploy quickly. Scaling teams to match accelerating arrival rates is a losing strategy.
• Alert fatigue: Endless, unprioritized findings create systemic burnout. Platform engineering increases useful capacity by automating repeatable work and making remediation boring.

The platform engineer's vulnerability management framework

Platform engineering changes the economics by making classes of problems cheap to handle. Instead of treating each new CVE as a unique firefight, the goal is to make entire categories of problems inexpensive and routine to resolve. Ashley organizes this around four principles: reduce, automate, contain, and recover.

Reduce: Ship less, expose less

The cheapest vulnerability is the one you never ship. Start with minimal, standards-aligned container images to eliminate unnecessary packages from your attack surface. Produce Software Bills of Materials (SBOMs) for your images using tools like Syft, and sign images with Cosign so you can quickly map exposure when a new CVE appears. Every component you don't include is one fewer thing to scan, triage, or patch.

Automate: Make compliance the default path

Humans are unreliable for repetitive verification at scale. Enforce policy-as-code with admission controllers like OPA Gatekeeper or Kyverno, verify images in pipelines, and bake signing and scanning into CI/CD so non-compliant artifacts never reach runtime. When guardrails are built into the platform itself, developers follow secure paths by default - without additional cognitive load.

Contain: Limit blast radius by design

Assume compromise is possible and design accordingly. Use least-privilege principles - avoid running containers as root. Enforce network policies and service-level segmentation using tools like Cilium, Calico or a service mesh. Deploy runtime detection to observe actual behavior versus intended behavior. When a breach occurs, containment limits the damage to a single service rather than cascading across your environment.

Recover: Rebuild, don't patch in place

Immutable deployments and automated rebuild pipelines let you replace affected services quickly and cleanly. When recovery is routine, vulnerability discovery becomes far less disruptive - you reset an attacker's clock by redeploying a clean image rather than attempting fragile in-place patching. This is where platform maturity pays direct dividends.

Prioritization: Beyond CVSS scores

Not all CVEs are equal, and raw severity scores don't reflect your actual risk. Effective vulnerability management automation requires asking reachability and business-impact questions:

• Is the vulnerable code actually executed in your environment?
• Which business services are affected?
• Is there a known exploit in the wild?
• Do compensating controls already reduce the effective risk?

Automated prioritization that factors in reachability and business context dramatically reduces wasted effort and helps teams focus on what genuinely matters.

Translating risk for leadership

Technical dashboards don't move budgets. To secure investment in platform security capabilities, translate findings into service-level risk. If a payment service runs as root, explain the business consequences of that exposure - not just the CVE identifier. Frame trade-offs between accepted risk and mitigation cost in terms that leaders can act on.

The supply chain trade-off

Faster patching can paradoxically increase supply-chain exposure if updates are accepted automatically without validation. The right approach is context-dependent: for isolated, low-risk components, waiting for community validation is reasonable. For exposed critical services, prioritize faster remediation with appropriate vetting. Supplier assurance and trusted partner relationships matter here.

Measuring what actually matters

Track rebuild time, deploy time, recovery rate, and blast radius - not just CVE counts. These <a href="https://platformengineering.org/blog/how-to-measure-developer-productivity-and-platform-roi-a-complete-framework-for-platform-engineers">metrics</a> show genuine improvement in risk posture even as discovery rates continue to rise, and they map directly to business outcomes that leadership can understand.

AI-assisted remediation is promising, but discovery velocity has outpaced remediation capability to date. The pragmatic assumption for platform teams is that this lag will persist for the foreseeable future. Invest now in reducing attack surface, automating responses, containing damage, and making recovery routine.

​

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

​

Key takeaways

• Reframe the problem as operational: The vulnerability crisis is a throughput problem, not just a security one. Increase useful capacity through platform practices - automation, opinionated defaults, and immutable deployments - rather than scaling headcount alone.
• Make vulnerabilities boring by design: Ship less, automate compliance checks, enforce guardrails at the platform layer, and prioritize based on reachability and business impact rather than raw CVSS scores.
• Design for compromise, not just prevention: Segment services, enforce least-privilege, and invest in fast rebuild pipelines. When recovery is routine, individual vulnerabilities lose their power to cause major disruption.
• Measure resilience, not just counts: Rebuild time, deploy time, recovery rate, and blast radius are better indicators of your actual risk posture than the number of open CVEs - and they're the metrics that resonate with business leadership.