The Challenge
When AWS Inspector was deployed at the organisational level, across a set of GIS-related AWS accounts, it returned something no team wants to see: over 5,000 critical and high severity vulnerabilities across the infrastructure.
The scale of the finding created its own problem. With thousands of vulnerabilities across multiple accounts and platforms, the risk of paralysis was real - too many issues to triage manually, too much noise to know where to focus, and too little time to address everything through individual investigation. The question was not just how to fix the vulnerabilities. It was how to fix them at a rate that actually moved the security posture.
What I Found
Inspector's visibility across the organisation revealed a consistent pattern: the overwhelming majority of vulnerabilities were not novel or complex. They were known CVEs in outdated operating system packages, runtime components, and container base images - the kind of issues that accumulate steadily when infrastructure is not being patched systematically.
These were not hard problems. They were widespread ones. And that distinction mattered, because it pointed directly toward the right approach: automation rather than manual remediation, infrastructure as code rather than instance-by-instance intervention.
The remaining vulnerabilities - once the volume was reduced - were a different category entirely. These required genuine investigation: understanding the specific component, the nature of the exposure, and why standard patching had not resolved the issue.
How I Approached It
The first priority was reducing the volume rapidly by addressing what could be automated.
I designed and developed pipelines to update infrastructure components systematically across the affected accounts - patching OS-level packages, patching critical applications, updating runtime environments, and refreshing container base images at scale. This was not a one-time run; the pipelines were built to be repeatable and integrated into existing delivery workflows, so the infrastructure would stay current rather than accumulating debt again.
This approach resolved approximately 96% of the vulnerabilities. More importantly, it cleared the noise - what remained was a manageable set of issues that warranted focused attention.
For the remaining vulnerabilities, I conducted deep investigation into each category. This meant understanding the root cause: why had the standard patching process not resolved it, what was the actual exposure, and what was the correct remediation path? In many cases this required working closely with the technical custodians of each platform - the people who understood the specific context, constraints, and dependencies involved. Remediation was progressive and collaborative, prioritised by severity and the platform team's capacity to absorb change safely.
What Changed
The vulnerability count across the GIS accounts was reduced by approximately 96% through the automated pipeline work, with the remaining issues systematically tracked and resolved through the collaborative remediation process.
Beyond the numbers, the organisation gained something more durable: a repeatable patching model embedded in its delivery pipelines, which meant the infrastructure would not quietly accumulate the same exposure again. The security posture improved not just as a point-in-time outcome, but as an ongoing capability.
Lessons for Enterprise Cloud Platform Management
Automation is a triage strategy, not just an efficiency gain. When Inspector surfaces thousands of findings, the temptation is to start investigating everything. The better move is to ask: what portion of this can be resolved systematically, without human judgement? Automated patching pipelines do not just fix vulnerabilities faster - they remove the noise, so that the issues requiring real investigation actually get the attention they deserve.
Infrastructure as Code is how you avoid fighting the same battle twice. Patching instances manually is a short-term fix. Building the patching logic into pipelines and IaC means the fix persists through future deployments. Organisations that remediate without updating their delivery model will find themselves back in the same position within months.
Volume obscures complexity - remove the volume first. The most consequential shift in this engagement was the decision to treat the 96% as a pipeline problem and the 4% as an investigation problem. If we had tried to investigate all 5,000 vulnerabilities individually, the genuine root cause issues would have been buried. Reducing the volume revealed the signal.
Remediation at scale requires partnership. The automated work could be executed independently, but resolving the remaining vulnerabilities required the knowledge, context, and cooperation of the platform custodians. Security improvements that are imposed rather than collaborative tend to create friction and incomplete fixes. Working progressively with the teams who own the platforms produced better outcomes and built lasting capability.
Visibility is only valuable if it leads to action. Deploying Inspector was the right first step - but the value of that investment was only realised through a structured response. Organisations that deploy security tooling without a corresponding remediation model risk generating findings that erode confidence rather than improve posture.