Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Healthcare |
| Cloud Environment | AWS |
| Workloads | EC2 instances (planning Kubernetes migration) |
| Code & CI/CD | GitHub, GitHub Actions |
| IAM Profile | 10–15 users with AWS console access |
| Team | CISO-led |
| Code Origin | Partner-developed applications + AI-generated code (Cursor/GPT) |
| Cloudanix Scope | Attack Surface Visibility, Code Remediation, Infra Remediation, Attack Path Closure, Coding Agent Firewall |
The Situation: Applications You Did Not Build, Running on Infrastructure You Must Secure
Healthcare organisations rarely start with a blank slate. This provider, one of the largest healthcare networks in the country, had built their digital infrastructure the way most healthcare companies do: by engaging external development partners to build and maintain their patient-facing and internal applications. The applications ran on EC2 instances in AWS, code was managed in GitHub with GitHub Actions handling CI/CD, and roughly 10 to 15 people had access to the AWS console.
The CISO’s concern was straightforward. The partner had delivered the applications, the contracts had concluded, and now the organisation needed to answer a question that nobody had definitively addressed during the engagement: are these applications actually secure, or are they carrying vulnerabilities that have simply never been found?
This is a common pattern in healthcare. Development is outsourced, the application works, it goes to production, and the security posture of the delivered code is assumed rather than verified. The provider had no static analysis, no secrets scanning, no dependency checks, and no systematic way to know whether the partner’s code had introduced risk that was now running in their production environment.
To compound the challenge, the organisation had recently started developing their own code using AI coding assistants, specifically Cursor and GPT-based tools. The speed was impressive; the confidence in the output was not. The CISO’s question was pointed: we are now shipping code that was written by a machine and reviewed by engineers who are not security specialists. How do we know this code is not vulnerable before it reaches production?
And beyond code, they wanted something most CNAPP buyers ask for but few platforms deliver cleanly: not just a list of findings across cloud and code, but a view of how those findings connect. Which misconfigurations, when combined with a vulnerable application and an over-permissioned IAM role, create an actual attack path to sensitive patient data? And which of those paths should be closed first?
The Four Priorities
The CISO articulated four requirements before agreeing to engage:
- Attack surface visibility: A complete picture of what is exposed, misconfigured, or over-permissioned across their AWS environment
- Code remediation: Ability to identify and fix vulnerabilities in both the partner-developed codebase and new AI-generated code
- Infra remediation: Actionable guidance for fixing cloud misconfigurations, not just detecting them
- Attack path closure: Ability to see how individual findings connect into exploitable chains, and to prioritise the one or two fixes that close the most paths simultaneously
The first three are table stakes for any modern CNAPP. The fourth, attack path closure with prioritised remediation, is where most platforms stop at visualisation and leave the prioritisation to the customer. The provider needed more than a graph; they needed to know where to start.
Where the Gaps Were?
1. Partner-Developed Code: Trust Without Verification
The applications had been in production for some time. They functioned correctly from a user perspective. But no security analysis had been performed at the code level, not during development, not at handoff, and not since. For a healthcare provider handling patient data, fertility treatment records, and personally identifiable information, this represented a compliance and patient-safety risk that was invisible but real.
The partner engagement model, common across healthcare, meant that the organisation had limited visibility into how the code was structured, whether secrets were hardcoded, whether dependencies carried known CVEs, or whether the application’s attack surface had expanded over time without anyone noticing.
2. AI-Generated Code: Speed Without Confidence
The decision to adopt AI coding assistants was driven by necessity. Without a full-time development team, the organisation needed a way to build and iterate on internal tooling and smaller applications quickly. Cursor and GPT-based tools delivered on speed. But they introduced a new category of risk that the team had no tooling to address.
AI coding agents do not inherently follow secure coding practices. They generate code that works, but that code may include hardcoded credentials, overly permissive API configurations, unvalidated inputs, or dependency choices with known vulnerabilities. Without a security layer between the AI-generated code and production, the organisation was effectively shipping unreviewed code from a non-human developer with no security training.
The deeper concern: AI coding agents often require cloud credentials to function. If those credentials are long-lived AWS keys stored in environment files, the agent itself becomes an identity surface. A compromised or misconfigured coding agent with production AWS access is not a theoretical risk; it is a credential incident waiting to happen.
3. Cloud Posture: Fifteen People With Console Access and No Posture Baseline
With 10 to 15 people having direct AWS console access and no dedicated cloud security tooling beyond what AWS provides natively, the organisation had no continuous posture baseline. Security Hub and GuardDuty provided some signal, but there was no consolidated view of misconfigurations across EC2, IAM, S3, networking, and the relationships between them. Findings existed in isolation; the team had no way to determine which findings were individually low-risk but collectively dangerous when chained together.
4. The GitHub Integration Challenge
During initial onboarding, the organisation connected their AWS environment successfully. However, the GitHub integration encountered a version compatibility limitation. The specific GitHub Enterprise Server version in use required a workaround for full repository scanning. Cloudanix’s engineering team resolved this through an alternative integration path, a dedicated Slack-channel engagement that is characteristic of how Cloudanix operates: the engineers who built the platform work directly with the customer’s team until the integration is fully functional, regardless of edge cases.
The Cloudanix Solution
Attack Surface Visibility: The Full Picture in 30 Minutes
Cloudanix connected to the provider’s AWS environment through a standard read-only IAM role. No agents at the posture layer, no changes to running infrastructure. Within 30 minutes, the platform surfaced the organisation’s complete attack surface:
- EC2 instances with their security group configurations.
- IAM roles and their effective permissions.
- S3 bucket policies.
- Networking topology, and the relationships between all of them.
For a CISO who had inherited a partner-built environment and needed to understand the security posture quickly, this first scan was the baseline that had never existed. Findings were mapped against relevant compliance frameworks, and each finding carried remediation guidance, not just a severity score and a CVE number.
Code Remediation: Scanning What the Partner Built and What AI Is Writing
Cloudanix integrated with the organisation’s GitHub repositories to perform static analysis, secrets detection, and dependency vulnerability scanning across the entire codebase. This covered both the partner-developed applications that had never been scanned and the new AI-generated code flowing through pull requests.
For the legacy partner code, the initial scan surfaced findings that had been present since the application was first deployed:
- Hardcoded configuration values.
- Dependencies with known CVEs that had accumulated patches over multiple release cycles.
- Code patterns that expanded the application’s attack surface unnecessarily.
Each finding was prioritised and delivered with specific, copy-paste-ready remediation guidance.
For the AI-generated code, Cloudanix’s Coding Agent Firewall provided an additional layer. This on-host capability sits between the AI coding agent and production, blocking secret and PII exfiltration before a token leaves the developer’s machine. For an organisation using Cursor and GPT to write code that interacts with patient data systems, this layer prevents the most dangerous class of AI-coding-agent risk: the inadvertent exposure of credentials or sensitive data through the agent’s own operations.
Pull request annotations now surface security findings at the point of code review, before code merges. Engineers who are not security specialists can see exactly what needs to change and why, with specific guidance rather than generic warnings.
Infra Remediation: Actionable, Not Just Informative
Cloud misconfigurations detected across the AWS environment were not simply listed with severity ratings. Cloudanix’s GenAI-powered remediation playbooks provided specific, contextual fix instructions for each finding:
- Exact CLI commands to run.
- IAM policy changes to make.
- Security group rules to modify.
For a team without deep cloud security expertise, the difference between “this security group is overly permissive” and “run this exact command to restrict ingress to the required CIDR range” is the difference between a finding that sits in a backlog and one that gets resolved the same day.
Remediation guidance was cross-referenced against the organisation’s compliance obligations, so the team could prioritise fixes that addressed both security risk and compliance gaps simultaneously rather than maintaining two separate remediation tracks.
Attack Path Closure: From Hundreds of Findings to Two or Three Fixes
This was the requirement that differentiated the engagement. The CISO did not want a list of 200 findings sorted by CVSS score. They wanted to understand which findings, when connected across code, cloud, IAM, and network, created actual exploitable paths to sensitive data, and which single fixes would close the most paths at once.
Cloudanix’s unified asset graph maps relationships across every resource type in the environment: EC2 instances, the IAM roles attached to them, the security groups governing their network access, the code running on them, the data stores they connect to, and the identities that can reach them. Attack path analysis traverses this graph to identify chains where a sequence of individually moderate-risk findings creates a high-severity exploitable path.
For this provider, the attack path view revealed patterns that isolated findings would never surface:
- An EC2 instance running a partner-developed application with a known dependency vulnerability, exposed to the internet through an overly permissive security group, running under an IAM role with broader permissions than required, with network connectivity to an RDS instance containing patient records.
Each element in that chain, taken individually, might score as medium severity. Together, they represent a direct path from the internet to patient data. The attack path view showed this, and more critically, showed that fixing the IAM role’s permissions (one change) would break the chain regardless of whether the application vulnerability or the security group were also remediated.
The Attack Path Principle: Customers can start from left to right along the path, fixing each misconfiguration sequentially. But the optimised approach, which Cloudanix surfaces, is to identify the one or two fixes that collapse the most paths simultaneously. For this provider, tightening two IAM roles closed seven distinct attack paths across their environment.
Preparing for the Kubernetes Migration
The organisation’s infrastructure roadmap included migrating from EC2 to Kubernetes within the near term. While the current engagement focused on the EC2-based environment, Cloudanix’s platform covers Kubernetes security with the same depth: KSPM for cluster configuration, workload protection for running containers, and the same attack-path analysis extended to include pod-level misconfigurations, RBAC bindings, and container-to-service relationships.
The security posture established on EC2 today carries forward as the organisation migrates. The asset graph simply expands to include Kubernetes resources alongside the existing cloud infrastructure, maintaining continuity of visibility, compliance evidence, and attack path analysis without requiring a separate tooling decision for the new environment.
Platform Impact: By the Numbers
30 min Agentless onboarding to first findings | 4 priorities All addressed from a single platform | Legacy + AI code Both scanned and remediated | Attack paths Reduced from open-ended risk to prioritised closure
The Bigger Picture: Security for Code You Didn’t Write
This provider’s situation maps to a pattern that is becoming more common, not less. Organisations that historically outsourced development are now also adopting AI coding assistants, creating a dual-origin codebase where neither source has been systematically secured. The code runs on cloud infrastructure that was configured for functionality, not for security. And the team responsible for all of it is a CISO and a handful of console users, not a dedicated security engineering function.
The answer is not to add four separate tools for the four priorities. That path leads to the same fragmentation that the provider was trying to avoid. The answer is a single platform that sees across code, cloud, identity, and data, maps the relationships between findings, and tells a small team exactly where to focus their limited time for maximum risk reduction.
Attack path closure is the practical expression of this principle. Not “fix everything” but “fix these two things, and you collapse seven paths to patient data.” For a healthcare organisation under compliance pressure and without a large security team, that prioritisation is not a nice-to-have. It is the only model that works.
The Outcome
The provider moved from zero visibility into their partner-developed and AI-generated codebase to continuous, automated security scanning with PR-level feedback. Their AWS environment, previously understood only through native tooling, was mapped into a unified asset graph that exposed attack paths invisible to any single-layer tool. And the CISO’s original four requirements, attack surface visibility, code remediation, infra remediation, and attack path closure, were addressed from a single platform with a single onboarding process.
Key Results
✅ 30-Minute Onboarding: Agentless AWS connection with immediate posture findings
✅ Legacy Code Secured: Partner-developed applications scanned for the first time
✅ AI Code Protected: Coding Agent Firewall blocking credential and PII exposure from Cursor/GPT
✅ Attack Paths Mapped: Exploitable chains identified across code, cloud, IAM, and network
✅ Prioritised Closure: Two IAM fixes collapsed seven attack paths to patient data
✅ Kubernetes-Ready: Platform prepared for the upcoming EC2-to-K8s migration
✅ GitHub Workaround Resolved: Version limitation addressed through direct engineering engagement
Running Healthcare Applications You Didn’t Build on Cloud Infrastructure You Must Secure?
Cloudanix connects to your AWS environment in 30 minutes, agentless and read-only. You will see your attack surface, your code vulnerabilities, your cloud misconfigurations, and critically, how they connect into exploitable paths. No more fixing findings in isolation. Start with the fixes that close the most paths.
Book a Free Assessment to see what your environment looks like through Cloudanix.
