🚨 F5 BIG-IP Breach Exposes Supply Chain Risk: Lessons from Automating Incident Response in Hybrid Cloud Environments

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - Building Automated Incident Response for the Cloud Age (continue reading) 

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter

The past week has reinforced a sobering reality for enterprise cloud security teams: sophisticated nation-state actors are targeting critical infrastructure software, and our incident response capabilities must evolve to match the complexity of modern cloud architectures. From F5's disclosure of persistent access by nation-state actors to Harvard's confirmation as a victim in the Oracle EBS zero-day campaign, the stakes have never been higher.

This week, we're featuring insights from Damien Burks, a seasoned cloud security engineer with over six years of experience building incident response platforms in highly regulated financial services environments. Damien has hands-on experience automating containment for complex Kubernetes environments and brings practical wisdom on navigating the increasingly sophisticated cloud security landscape.

📰 TL;DR for Busy Readers

• F5 BIG-IP breach: Nation-state actors stole source code; treated as supply-chain exposure for all BIG-IP deployments including cloud VE instances. Treat F5 BIG-IP as software provenance risk; verify image digests and lock down management planes now.

• Oracle EBS zero-day @ Harvard: 1.3TB exfiltrated via CVE-2025-61882; check EBS integrations with cloud IAM and data warehouses

• GitHub Copilot CamoLeak: CamoLeak proves AI dev tools can exfiltrate secrets via hidden prompt injection; restrict scopes and disable risky render paths.

• AWS & Google updates: Guardrails for AI agents + Drive anti-ransomware AI align with your data-protection strategy.

• EKS containment: Use in-VPC automation (e.g., Lambda in cluster VPC/SG) to execute kubectl playbooks without bastions.

📰 THIS WEEK'S SECURITY HEADLINES

1. F5 BIG-IP Source Code Stolen in Nation-State Breach

What Happened: F5 disclosed that sophisticated nation-state actors maintained persistent access to its internal systems from an unknown date until discovery on August 9, 2025, successfully exfiltrating portions of BIG-IP source code and information about undisclosed vulnerabilities. The U.S. Department of Justice granted a one-month disclosure delay citing national security concerns marking one of the first public acknowledgments of DOJ intervention in SEC cybersecurity disclosures. CISA issued Emergency Directive ED 26-01 ordering all federal civilian agencies to immediately mitigate unauthorized access risks and report detailed F5 BIG-IP inventories by December 3, 2025.

Why This Matters to Cloud Security Leaders:

This incident represents a textbook supply-chain compromise affecting thousands of enterprises running BIG-IP appliances in cloud VPCs and on-premises data centers. For cloud security architects, the implications extend beyond traditional on-prem ADC deployments. Many organizations deploy F5 virtual editions (VE) from AWS Marketplace, Azure Marketplace, or as custom AMIs all potential attack surfaces if adversaries possess source code and vulnerability intelligence.

The multi-month detection gap is particularly concerning. As Damien Burks emphasizes in this week's featured interview: "Without automation, in a regulated environment, it's gonna take you hours" to respond to incidents in complex environments. The F5 breach underscores why detection alone is insufficient. Organizations need automated response capabilities that can contain threats within minutes, not hours.

From an architectural perspective, BIG-IP often sits at the network boundary between internet-facing services and application tiers, making compromised instances ideal pivot points for lateral movement. Cloud security teams should treat this as an opportunity to harden management plane access, implement zero-trust network segmentation, and deploy enhanced telemetry on ADC zones.

Sources: Bloomberg, SecurityWeek, The Record, Help Net Security

2. Harvard Confirms Breach in Oracle EBS Zero-Day Campaign

What Happened: Harvard University became the first confirmed victim of a widespread Oracle E-Business Suite exploitation campaign orchestrated by the Cl0p ransomware group. Attackers exploited CVE-2025-61882 (CVSS 9.8), a critical authentication bypass vulnerability allowing unauthenticated remote code execution, to exfiltrate 1.3 TB of data including financial records, HR information, and internal source code. Google Threat Intelligence and Mandiant report that dozens of organizations were targeted beginning as early as July 10, 2025, with the campaign accelerating through October.

Why This Matters to Cloud Security Leaders:

Oracle EBS presents a critical attack surface that often flies under the radar of cloud security programs focused on native cloud services. EBS is deeply embedded in financial operations, human resources, supply chain management, and customer relationship systems across Fortune 500 companies. More importantly for cloud security teams, EBS instances frequently integrate with cloud IAM systems, data warehouses (Snowflake, Redshift, BigQuery), and SaaS platforms (Salesforce, Workday), making compromised instances potential bridges into broader cloud environments.

The FBI characterized CVE-2025-61882 as a "stop-what-you're-doing and patch immediately" vulnerability. The multi-month exploitation window before public disclosure highlights a detection gap that sophisticated threat actors exploit repeatedly. As Damien Burks notes when discussing incident response complexity: "You have to understand how your environment is configured to begin with" a principle that applies equally to understanding how legacy ERP systems like Oracle EBS connect to modern cloud infrastructure.

This incident also reinforces the importance of data classification and egress monitoring. Harvard lost 1.3 TB of sensitive data, suggesting inadequate data loss prevention controls between EBS and external networks. Cloud security teams should implement enhanced monitoring for unusual data exfiltration patterns from any system with access to sensitive data stores.

Sources: SecurityWeek, Security Affairs, Dark Reading, The Record

CamoLeak: GitHub Copilot Vulnerability Enables Silent Data Exfiltration

What Happened: Legit Security detailed CamoLeak, a critical vulnerability chaining remote prompt injection (hidden in pull request content) with an image-proxy CSP bypass to exfiltrate secrets and private repository code via GitHub's own infrastructure. The vulnerability received a CVSS score of 9.6. GitHub mitigated the issue by disabling image rendering in Copilot Chat.

Why This Matters to Cloud Security Leaders:

CamoLeak confirms what many security teams feared: AI assistants represent new data egress channels that can bridge from source control systems to external endpoints. For cloud security programs, this vulnerability is particularly concerning because private repositories often contain cloud access keys, API credentials, and information about undisclosed vulnerabilities exactly the type of data exfiltrated in the F5 breach.

The attack vector is sophisticated yet practical: adversaries can hide malicious instructions in pull request content that Copilot processes, bypassing traditional security controls. As organizations increasingly adopt AI-powered development tools, the attack surface expands beyond traditional application security boundaries into the toolchain itself.

This connects directly to Damien Burks' emphasis on understanding entry points and preventing incidents before they require response: "Secure coding is definitely recommended. I mean, like it's enforced in a heavily regulated environment." The same rigor applied to application code must now extend to AI assistant configurations and permissions.

Sources: Legit Security Research

4. LevelBlue to Acquire Cybereason in MDR/XDR Consolidation Move

What Happened: MSSP LevelBlue signed a definitive agreement to acquire Cybereason (XDR/DFIR platform). SoftBank Corp., SoftBank Vision Fund 2, and Liberty Strategic Capital will become investors in LevelBlue, with former U.S. Treasury Secretary Steven Mnuchin joining the board. The integration will fold Cybereason's XDR and digital forensics capabilities into LevelBlue's managed detection and response portfolio.

Why This Matters to Cloud Security Leaders:

This acquisition represents continued consolidation in the detection and response market, with implications for organizations running XDR agents in cloud workloads. The integration will likely result in bundled MDR/XDR/IR offerings with tighter sensor-to-SOC integration across cloud and endpoint environments.

For cloud security teams, M&A activity among security vendors creates operational risk around roadmap changes, SKU consolidation, and potential disruptions to existing telemetry pipelines. Organizations running Cybereason agents in containerized workloads (EKS, AKS, GKE) should proactively engage with vendor account teams to understand migration plans and ensure continuity of cloud-native detection capabilities.

Source:Business Wire press release; LevelBlue newsroom/blog

🎯 Cloud Security Topic of the Week:

The Kubernetes Incident Response Automation Gap: Why Manual Containment Fails in Regulated Environments

• One of the most pressing challenges in cloud incident response doesn't involve detection tools, threat intelligence, or even adversary tactics; it's the fundamental operational reality that containerized workloads, particularly Kubernetes clusters, remain extraordinarily difficult to contain during active incidents.

• This week's conversation with Damien Burks, who built an incident response platform from the ground up in financial services, reveals a sobering truth: despite billions spent on runtime security and CNAPP solutions, most organizations still manually respond to Kubernetes incidents, often taking hours to achieve containment that should happen in minutes.

Featured Experts This Week 🎤

• Damien Burks   Senior Cybersecurity Engineer (FinTech)

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

Before diving into our insights, let's clarify some key terms:

• EKS (Elastic Kubernetes Service): AWS-managed Kubernetes control plane service. While AWS manages the control plane, customers are responsible for worker nodes, networking, and security configurations.

• Private Cluster: A Kubernetes cluster configuration where the API endpoint is not accessible from the public internet, requiring requests to originate from within the same VPC or through VPN/VPC peering connections.

• CNAPP (Cloud-Native Application Protection Platform): Security platform category that combines multiple cloud security capabilities including CSPM, CWPP, and runtime protection for cloud-native applications.

• CSPM (Cloud Security Posture Management): Tools that continuously monitor cloud infrastructure for misconfigurations and compliance violations against security best practices and regulatory standards.

💡Our Insights from this Practitioner 🔍

Building Automated Incident Response for the Cloud Age (Full Episode here)

The conversation with Damien Burks reveals fundamental truths about incident response that every cloud security leader should internalize: detection is only half the battle, and in complex cloud environments, manual response processes guarantee unacceptable containment times.

1️⃣ From Hours to Minutes: The Case for Automation in Regulated Environments

Perhaps the most striking insight from Damien's experience comes from his work in financial services, where he built an incident response platform specifically designed for private EKS clusters. The contrast between manual and automated approaches is stark.

"Without the automation, in a regulated environment, it's gonna take you hours," Damien explains. "I was able to contain an EKS node within about 10 minutes."

This isn't merely about efficiency, it's about reducing blast radius during active incidents. In regulated industries, manual containment requires navigating multiple approval layers, establishing secure access to isolated environments, and coordinating across teams that may span different time zones. Meanwhile, adversaries continue to operate, exfiltrate data, establish persistence mechanisms, and pivot to additional targets.

The Lambda-based automation Damien developed addresses the core challenge of private clusters: "I had to create a Lambda function and basically automate the creation of the Lambda function to throw itself into the cluster's VPC, subnet, and then also the security group." This approach solves the networking isolation problem that defeats traditional security tools while maintaining security boundaries.

For security leaders, the lesson is clear: in 2025, incident response automation isn't optional it's a fundamental requirement for protecting cloud workloads, particularly in containerized environments where architectural complexity makes manual response impractical.

2️⃣ The Sophistication Gap: Why Commercial Tools Fall Short

Despite the proliferation of CNAPP and CSPM vendors promising comprehensive cloud security, Damien found a consistent gap when evaluating commercial platforms: "The majority of what I see is there isn't a sophisticated approach to automating incident response or containment activities and actions inside of those type of complex environments."

The problem stems from a fundamental misalignment between how security tools are architected and how modern cloud infrastructure actually works. Detection is relatively straightforward; runtime agents can identify suspicious processes, unauthorized network connections, or privilege escalation attempts. But responding to those detections in private, network-isolated clusters requires understanding Kubernetes networking, AWS VPC configurations, IAM-to-RBAC mappings, and the specific architectural choices each organization makes.

"Let's say for instance, you have a private cluster in EKS," Damien explains. "You cannot reach out. To, you have to be in the same networking configuration. Same VPC, subnet and Security Group in order for you to be able to interact with the Kubernetes cluster."

Commercial tools that work across multiple cloud platforms often sacrifice this level of deep integration for broader compatibility. As a result, they excel at telling you what's wrong but offer little help fixing it within the constraints of your specific architecture.

This creates an imperative for security teams: build custom automation for your specific environment, or accept that incident response will remain a manual, time-consuming process. Given the stakes particularly in the face of sophisticated nation-state actors as revealed in the F5 breach the choice should be obvious.

3️⃣ The Multi-Layer Authentication Challenge

One of the most technically complex aspects of Kubernetes incident response involves the intersection of cloud IAM and Kubernetes RBAC. Damien describes this challenge in detail:

"Whatever role that you're using, you gotta make sure that that role is mapped to the config map that's attached to an RBAC role within the Kubernetes cluster. If you don't have that there, then of course it's not going to give you the permissions or access that you need."

This represents a fundamental shift from traditional incident response. In conventional cloud environments, IAM permissions alone determine what actions you can perform. In Kubernetes, you need:

1. AWS IAM permissions to call EKS control plane APIs

2. Kubernetes RBAC roles defined within the cluster

3. aws-auth ConfigMap mappings linking your IAM identity to Kubernetes identities

4. Network connectivity to the API endpoint (either direct or through VPN/bastion)

5. Valid kubeconfig with authentication tokens

Each layer introduces complexity and potential failure points during incidents. Security teams must document these dependencies in advance and test incident response procedures regularly to ensure all pieces work together under pressure.

For organizations just beginning their Kubernetes security journey, Damien's experience offers a clear roadmap: "I need to understand Kubernetes first. I need to understand how it works internally." Without this foundational knowledge, incident response becomes guesswork and in regulated environments with strict compliance requirements, guesswork is unacceptable.

4️⃣ Prevention Through Developer Enablement

While much of the conversation focuses on response and containment, Damien emphasizes the critical role of prevention, particularly through secure development practices. His perspective reflects years of working across application security, cloud security, and DevSecOps:

"From an application security side, secure coding is definitely recommended. I mean, like it's enforced in a heavily regulated environment."

The layers of defense he describes represent a comprehensive approach:

1. Secure coding to prevent injection attacks and common vulnerabilities

2. Dependency scanning to identify vulnerable open-source components

3. Container hardening to limit the impact of application compromise

4. Kubernetes cluster configuration following best practices for network policies, service accounts, and pod security

This layered approach acknowledges a fundamental truth: no single security control will prevent all incidents. Instead, defense-in-depth reduces the attack surface at each layer and increases the work required for adversaries to achieve their objectives.

Notably, Damien emphasizes the importance of understanding the developer's perspective when implementing security controls: "Programming is something that a DevSecOps engineer can benefit from...you have to put yourself in a developer's shoes." This human-centered approach to security increases adoption of controls and improves the quality of security outcomes.

5️⃣ The Specialization Imperative: Why Multi-Cloud Is Chaos

Perhaps the most controversial insight from this week's conversation challenges the widespread push toward multi-cloud architectures and multi-platform expertise. Damien is blunt in his assessment:

"Multi-cloud to me just means chaos. I don't see that being, that's, to me, that's not realistic."

His reasoning stems from practical experience trying to maintain expertise across platforms: "How can you focus your time across multiple different cloud service providers and stay up to date with everything?"

AWS alone releases hundreds of service updates annually. Azure and Google Cloud maintain similar innovation velocities. For individual practitioners or even small security teams, attempting to master all three platforms simultaneously results in surface-level knowledge of everything and deep expertise in nothing.

"I think that you get good at one. You specialize in that one. And you lock into that one," Damien advises. "Growth is T-shaped. You specialize and then spread after the fact."

This specialization philosophy has important implications for both individual career development and organizational security strategy. For practitioners, deep expertise in one platform makes you more valuable than shallow knowledge of multiple platforms. For organizations, hiring specialists for each cloud platform you use produces better security outcomes than expecting generalists to secure everything.

The comparison to programming languages illustrates the point: "It's like learning a programming language, right? While the concepts of parallelism and concurrency, recursion, object oriented programming may be the same, the implementation is very different."

AWS IAM, Azure AD/Entra, and Google Cloud IAM all implement identity and access management, but the specific mechanisms, best practices, and edge cases differ significantly. Security teams that specialize can navigate these nuances; generalists inevitably make mistakes that sophisticated adversaries exploit.

6️⃣ Practical Guidance for Incident Responders Transitioning to Cloud

For incident response professionals with deep data center or traditional security backgrounds, Damien offers specific guidance on transitioning to cloud security:

"Go get the cloud certifications and learn the theoretical aspects of it. And then some CSPs have incident response practices and guides to help you navigate those things."

The certification path he recommends provides structured learning: AWS Solutions Architect Associate for foundational knowledge, followed by the Security Specialty certification for deeper security focus. But certifications alone aren't sufficient:

"Start playing around in your own project. And then from there you keep moving forward."

Hands-on experience with cloud services, combined with coding/scripting skills, enables incident responders to build the automation that makes cloud incident response practical. The theoretical knowledge from certifications provides context; the practical experience builds competence.

Importantly, Damien emphasizes that incident responders already possess critical knowledge that translates directly to cloud: "You have the knowledge and you have the background...You just have to understand how the cloud services all work together and how they can be architected."

This perspective should encourage traditional security professionals concerned about cloud skills gaps. The fundamentals of incident response, understanding attack vectors, analyzing logs, containing threats, and preserving forensic evidence remain constant. The challenge lies in applying those fundamentals within cloud architectures that differ from traditional data center environments

🧭 What Security Leaders Should Do Now

1. Automated incident response is no longer optional for containerized workloads, particularly in regulated industries where manual processes take hours

2. Private Kubernetes clusters require purpose-built automation that can operate within network isolation constraints

3. Commercial security platforms excel at detection but often lack sophisticated automated response capabilities for complex cloud architectures

4. IAM-to-RBAC mapping complexity in Kubernetes creates authentication challenges that must be solved in advance of incidents

5. Specialization in one cloud platform produces better security outcomes than surface-level multi-cloud expertise

6. Prevention through secure development practices remains crucial, but detection and response must assume prevention will sometimes fail

7. The cloud security role has expanded dramatically to include application security, container security, AI/ML security, and data governance

8. Time-to-containment metrics should be measured and optimized, with targets in minutes rather than hours

9. Build custom automation for environment-specific response actions while leveraging commercial tools for detection and visibility

10. Test incident response procedures regularly in environments that mirror production complexity

RELATED RESOURCES

• Kubernetes Security & Incident Response:

  • AWS EKS Best Practices Guide for Security: https://aws.github.io/aws-eks-best-practices/security/docs/

  • Kubernetes Hardening Guide (NSA/CISA): https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF

  • Falco Open Source Runtime Security: https://falco.org/

  • Kubernetes Security Checklist and Requirements: https://kubernetes.io/docs/concepts/security/

  DevSecOps & Cloud Security Learning:

  • DevSecOps Blueprint (Damien Burks): https://devsecblueprint.com

  • Cloud Security Alliance (CSA) Security Guidance: https://cloudsecurityalliance.org/research/guidance/

  • OWASP Cloud-Native Application Security Top 10: https://owasp.org/www-project-cloud-native-application-security-top-10/

Related Podcast Episodes 🎧

Question for you? (Reply to this email)

⚙️ Have you tested your Kubernetes incident response procedures in a private cluster environment, what was your time-to-containment?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Shilpi Bhattacharjee

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast