Introduction: Moving to the Cloud Changed Everything (Even If the Cloud Didn’t)

In this article, we’ll break down the three most prevalent runtime threat vectors behind most modern cloud breaches – and why traditional cloud security tools fail to detect them.

Let’s get one thing clear: the cloud itself hasn’t become more dangerous – but cloud-native architectures fundamentally changed the threat landscape.

In the datacenter era, most threats targeted hosts, networks, and endpoints. In short, attackers were targeting the infrastructure layer as well as the application. Since cloud vendors are doing a reliable job in security in the infrastructure layer, in the cloud era, attackers go after something far more fluid they’re left with:

• Ephemeral workloads,
• API-driven infrastructure,
• Distributed identities,
• CI/CD-driven software supply chains.

These cloud-native characteristics introduce dynamic, high-velocity risk surfaces that traditional tools cannot continuously monitor.

And yet, most organizations are still trying to protect cloud environments with ineffective solutions or tools designed for a completely different world.

If you want to understand modern cloud risk, you don’t need a 200-page CNAPP whitepaper. you need to understand three core runtime cloud workload threat vectors. Ignore these three, and you’re exposed, no matter how many dashboards you have.

Let’s break them down.

Threat #1 — Application-Layer Attacks (Where Real Attacks Actually Start)

Why Application-Layer Attacks Evade Traditional Cloud Security

These attacks target the running application layer, not the infrastructure, making them invisible to most posture-based tools. This is not a theoretical “shift left” conversation. This is the part where things break in production.

Common real-world application-layer attack types include:

• Remote command injection
• Server-side request forgery
• Database injection attacks (SQLi)
• Open redirects
• Broken access control
• Malicious payloads sent to weak API endpoints

Everyone “knows” application security is important. But here’s the uncomfortable truth:

• Most organizations have no runtime visibility into application-layer attacks.
• Static vulnerability scanners can’t detect them.
• Posture tools can’t help you once an attack is underway.

Even mature AppSec teams with robust SAST/SCA/DAST pipelines… still can’t see what’s happening inside the running application.

This is why so many high-impact cloud incidents begin with a simple phrase:

“An attacker made a crafted HTTP request to an API endpoint…”

If you’re not monitoring runtime behavior at the application layer, you’re blind.

Real Example: CapitalOne cloud breaches 

Take the famous example of the CapitalOne attack in 2019, which is one of the most notable cloud breaches via an application-layer attack.

• The attacker exploited a Server-Side Request Forgery (SSRF) vulnerability in a web application 
• The AWS Web Application Firewall (WAF) forwarded requests to theinternal metadata service
• Through the AWS EC2 instance metadata URL, the attacker obtained temporary IAM credentials assigned to the server’s role
• Because the WAF was not configured to catch this request pattern, it failed to block the malicious requests (it is not clear if it could have been configured practically to prevent the attack)
• Using the stolen AWS keys, the attacker accessed sensitive data in Amazon S3 buckets, including over 100 million customer records with personal information
• Notably, traditional security tools did not catch this in time: the IDS/IPS didn’t flag the internal SSRF traffic, and no alert was raised for the mass data exfiltration. The breach was only discovered after an external researcher found evidence of the attack on GitHub, meaning the malicious activity went unnoticed by runtime defenses for months.

Key Takeaways from this attack:

• SSRF can allow external requests to reach internal cloud endpoints. Cloud runtime defenses should monitor outgoing requests from applications to unusual IPs (like 169.254.169.254) and block or alert on access to instance metadata services.
• Detecting Credential Misuse: Even if an attacker grabs cloud credentials, their usage can be flagged. In this case, the stolen IAM role was used to list and download S3 data
• Runtime cloud monitoring (e.g., CloudTrail with anomaly detection) should detect anomalies such as a web server instance suddenly reading massive amounts of S3 data or using IAM privileges it normally doesn’t have.
• Perimeter tools alone (like WAFs) are not foolproof. It’s crucial to have runtime application self-protection or host-based rules to detect SSRF patterns, and to enforce cloud security best practices (such as using IMDSv2 and least-privileged IAM roles) to minimize damage if an app is exploited

Threat #2 — Supply Chain Compromises (Where Attackers Hide in Plain Sight)

Why Supply Chain Attacks Are Increasing in Cloud Environments

Let’s be honest: supply chain attacks have become the cheapest zero-days in history.

Attackers no longer need to find a vulnerability in your code. They can:

• compromise a dependency,
• poison a library,
• inject malicious behavior in a version update,
• or hijack a maintainer account on NPM, PyPI, or GitHub.

And here’s the part everyone forgets:

Most supply chain attacks look completely innocent at the deployment time. The code compiles. The pipeline passes. Your SCA scanner sees “no known vulnerabilities.” Everything is green.

Because attackers intentionally insert malicious logic, no CVE will ever exist for the compromised version — making SCA tools effectively blind.

So most software supply chain security tools completely miss these attacks.

The only place to reliably catch supply chain attacks is in runtime. When the application starts doing something it has never done before (new processes starting, new external network connections are initiated, for example)

Runtime version profiling is the missing piece here. If version 1.3 used to make 5 external calls and version 1.4 suddenly makes 43 to untrusted destinations… you don’t need a CVE to understand something’s wrong.

Real Example: 2025 npm Maintainer Account Compromise

The summer of 2025 saw a surge of software supply chain attacks targeting Node.js packages. In one case, the maintainer of the popular Prettier plugin eslint-config-prettier fell victim to a phishing email, allowing attackers to hijack his npm account. The attackers published new versions of the package (and a few related packages) containing malicious code, specifically, an install.js script that dropped a hidden node-gyp.dll Trojan on Windows systems. This malware (“Scavenger” malware) could harvest files and credentials. The malicious updates (over 78 million weekly downloads worth of packages) were live on npm for at least a day before being detected when users noticed suspicious post-install behavior. Standard supply-chain security tools (like source repository checks or signature verifications) failed to catch the intrusion in time, since the packages were trojanized at the source. Detection relied on user reports and security researchers’ quick action once unusual activity.

Key Takeaway is that supply-chain attacks involve malicious code running within trusted processes. Runtime defenses should watch for abnormal behaviors in package installation and execution. For example, an npm package installer spawning a DLL or making outbound network calls is a red flag that can be caught by an EDR or container security agent

This is exactly why runtime behavioral analysis is required — malicious logic reveals itself only when the package executes.

Threat #3 — Stolen Cloud Identities (The Most Common and Most Silent Breach Vector)

Why Identity Abuse Is the Most Common Cloud Breach Vector

Let’s talk about the elephant in every cloud breach report: identity.

Cloud environments run on identities:

• service accounts
• IAM roles
• access tokens
• API keys
• short-lived credentials

When an attacker steals a token, they inherit your workload’s exact permissions — no exploit required

And unless you have cloud identity threat detection, here’s what happens:

• You won’t see unusual read/write/API patterns
• You won’t notice lateral movement across services
• You won’t know a role is being misused
• You won’t stop the attacker until data is already gone

Identity compromise is the most frequent cause of cloud-native breaches for one reason: it’s the easiest way in, and the hardest thing to detect without runtime context.

You can’t fix this with posture. You can only fix it with detection that understands behavior over time.

Real Example:EleKtra-Leak & RubyGems.org

An example of the credential misuse or leak attacks (beyond the CapitalOne) is “EleKtra-Leak”. 

• Unit 42 researchers in 2023 detailed an active campaign (the “EleKtra-Leak”) where attackers monitored public code repositories for exposed AWS API keys.
• In one case, within five minutes of a developer accidentally committing AWS credentials to GitHub, attackers detected the key and began abusing it. 
• The stolen access key was used to spin up numerous Amazon EC2 instances, which the adversaries installed cryptominers, effectively using the victim’s cloud compute for illicit cryptocurrency mining. 

In another incident in 2025, a former maintainer of RubyGems.org who still possessed unrotated AWS root credentials was able to log in and take control of the organization’s AWS account, modifying IAM roles and attempting to lock out legitimate users (an insider threat scenario). 

In both scenarios, the core issue was credentials falling into the wrong hands , whether via external leak or internal oversight, and being used to perform unauthorized actions in the cloud. The initial leak often goes unnoticed; the malicious usage is what eventually raises suspicion (e.g. a sudden spike in AWS costs, strange console logins, or service abuse notices).

Leaked credential misuse often has a distinct fingerprint. Environments should leverage AWS CloudTrail, GuardDuty, and similar services to detect anomalies like an access key being used from an unusual geo-location or a decommissioned account suddenly performing actions. For instance, catching a flurry of EC2 instance creation or high-volume SES email sending from an account that normally doesn’t do that can tip off a compromise in progress.

Why These Three Threats Matter (And Why Most Tools Miss Them)

These three vectors have one thing in common:

They all operate at runtime, the exact layer where most organizations have the least visibility.

And here’s why they consistently slip through the cracks:

• CNAPPs and posture tools see only theoretical risk
• EDR/XDR tools cannot interpret cloud-native workloads
• WAFs lack application-layer context
• SIEMs do not correlate runtime behavior end-to-end
• SCA scanners miss malicious runtime behavior

Put simply:

Cloud teams are looking at the wrong problems with the wrong tools.

Meanwhile, attackers are exploiting the blind spots that everyone already knows exist.

So What Do Cloud Teams Actually Need?

A modern cloud security program must detect:

• behavioral anomalies at the application layer
• malicious version drift and supply chain actions
• suspicious IAM activity tied to workload behavior

And-critically-tie all three together into a single correlated attack story.

Because today’s attacks don’t stay in one lane. They chain:

Exploit → Identity → Lateral Movement → Data

If you don’t have runtime visibility, detection & response  across all three vectors, you’re always one step behind.

And this is exactly what ARMO Cloud Application Detection & Response (CADR) is all about.  

Final Thoughts – Focus on the Attacks That Actually Happen

Cloud risk is broad. Cloud security budgets are not.

If you prioritize everything, you secure nothing.

But if you focus on these three vectors: application behavior, supply chain integrity, and identity misuse, you cover the majority of high-impact, real-world cloud breaches.

Your workloads don’t need another dashboard. They need runtime awareness.

And whether you build it yourself or use a platform like ARMO CADR, one thing is clear:

The future of cloud security belongs to teams who can actually see what’s happening in their workloads and accounts, at runtime.

To summarize – 

• Application behavior must be monitored at runtime
  
• Supply chain anomalies must be detected behaviorally
  
• Cloud identities must be monitored continuously

If you want to see how runtime detection changes your cloud security posture, schedule a demo of ARMO CADR