AWS Fargate launched in November 2017 and Google Cloud Run went GA in April 2019, both promising to remove the burden of patching, scaling, and hardening the underlying host. Nearly a decade later, security teams still hit the same wall: how do you scan, monitor, and lock down a container when you can't SSH into the node it runs on? Fargate isolates every task in its own Firecracker microVM; Cloud Run sandboxes every revision with gVisor. Neither platform lets you install a kernel-level agent, deploy a DaemonSet, or inspect a shared host's process tree the way you would on self-managed EKS or GKE nodes. That architectural shift breaks node-centric runtime security tooling built for the last decade of container adoption. Meanwhile, the vulnerabilities keep shipping: runc's file-descriptor leak (CVE-2024-21626), Log4Shell (CVE-2021-44228), and dozens of base-image CVEs published to the NVD every week still ride inside Fargate task images and Cloud Run container revisions. Here's what actually changes, what doesn't, and how to secure both platforms in practice.
What makes container security different on Fargate and Cloud Run?
The core difference is that you never get access to the underlying host, which eliminates an entire category of node-level security controls. On self-managed Kubernetes or EC2-backed ECS, you can run a host agent, tail the kernel audit log, or drop a privileged DaemonSet onto every node to watch process execution across containers. Fargate removes the node from your control plane entirely: AWS runs each task inside a dedicated Firecracker microVM, the same lightweight virtualization technology behind Lambda, so there is no shared kernel between your workloads and no node for a traditional agent to live on. Cloud Run takes a different but equally isolating approach, wrapping every container in gVisor, a user-space kernel that intercepts and re-implements Linux syscalls before they ever touch the real kernel. The practical effect is identical on both platforms: classic eBPF-based runtime sensors that expect direct kernel visibility either can't attach or only see a sandboxed subset of syscalls, and vulnerability scanners that assume they can crawl a live filesystem on a persistent host have nothing to crawl.
Can traditional runtime security agents protect Fargate tasks?
Not in their original form, because DaemonSet and host-agent architectures require a node you control, and Fargate gives you none. Tools like Falco or a classic Sysdig node agent are built to run once per node and observe every container scheduled onto it — a model that amortizes one agent's overhead across dozens of workloads. AWS's own answer, GuardDuty Runtime Monitoring for Fargate (generally available since February 2023), works around this by deploying a lightweight sidecar container into every single ECS task rather than one agent per node. That's functionally correct but economically different: instead of one agent watching 50 containers on a node, you now run one sidecar per task, so overhead and licensing cost scale with task count, not node count. Cloud Run has no equivalent first-party runtime sensor at all as of this writing — Google's guidance leans on Cloud Audit Logs, VPC Service Controls, and Binary Authorization instead of in-container behavioral monitoring, because gVisor's syscall interception makes injecting a conventional runtime agent into the sandbox impractical.
How do IAM misconfigurations create risk in serverless containers?
Overly broad task roles and public invoker bindings are the two most common ways attackers turn a compromised container into broader account access. On Fargate, ECS separates the task execution role (used to pull images from ECR and write to CloudWatch) from the task role (the permissions your application code actually assumes at runtime), and teams frequently attach one shared, overly permissive task role across dozens of services to save setup time — meaning a code injection in a single low-value service can inherit S3, DynamoDB, or Secrets Manager access meant for a completely unrelated workload. On Cloud Run, the equivalent failure mode is deploying with --allow-unauthenticated or granting roles/run.invoker to allUsers, which Google's own documentation flags as a common misconfiguration: the service becomes reachable by anyone on the internet with no IAM check at all, turning an app-layer bug into a fully unauthenticated remote entry point. Because both platforms auto-provision networking and DNS for you, a publicly invokable Cloud Run URL or an internet-facing ALB in front of a Fargate service is discoverable through routine internet-wide scanning within hours of deployment, not months.
What container vulnerabilities actually matter in ephemeral environments?
What matters is whether a vulnerable package is actually loaded and reachable at runtime, not every CVE that shows up in an SBOM scan. Fargate and Cloud Run containers are rebuilt from CI/CD and redeployed as immutable images or revisions, so "patching" never means patching a live host — it means rebuilding the image and rolling a new task or revision, which makes reachability analysis far more valuable than raw CVE counts. Two runc vulnerabilities illustrate why the runtime layer still matters even though you don't manage the host: CVE-2019-5736 allowed a malicious container to overwrite the host runc binary and gain host-level code execution, and CVE-2024-21626, disclosed in January 2024, let a leaked file descriptor inside a container grant access to the host filesystem — both are patched at the container-runtime version AWS and Google control, but any customer running old, cached base images can still be shipping vulnerable userland tooling that interacts with those runtimes. Log4Shell (CVE-2021-44228, disclosed December 2021) remains the cautionary example for the application layer: any Fargate task or Cloud Run revision bundling a vulnerable log4j-core JAR was remotely exploitable the moment it received a single crafted log line, regardless of how well the surrounding infrastructure was locked down, which is why identifying whether that class actually loads at runtime — not just whether it's present on disk — is the difference between a critical incident and a non-event.
How do you detect a compromised Cloud Run revision or Fargate task?
Detection has to come from control-plane logs and network telemetry rather than host-level instrumentation, since there's no host to instrument. Every Fargate task runs in awsvpc network mode, which assigns each task its own elastic network interface and security group, so VPC Flow Logs give you per-task egress visibility — a task suddenly connecting outbound to an unfamiliar IP on port 4444 is a strong signal even without a runtime agent. CloudTrail records every ecs:RunTask, ecs:StartTask, and iam:AssumeRole call, letting you catch a task role being assumed somewhere it's never been assumed before. On Cloud Run, Cloud Audit Logs capture every run.services.update and IAM policy change, and Cloud Run's built-in request logs record every invocation with the source and latency, which is often enough to spot a revision suddenly serving requests from unexpected geographies or at an anomalous rate. Because Cloud Run keeps old revisions addressable by default unless you explicitly migrate traffic, teams also need to check for stale, previously-vulnerable revisions still reachable at pinned URLs long after the "current" revision was patched.
How Safeguard Helps
Safeguard maps the CVEs in your Fargate task images and Cloud Run container revisions against what's actually loaded and executable at runtime, so reachability analysis tells you which findings need a same-day rebuild and which can wait — instead of treating every NVD entry with equal urgency. Griffin AI, Safeguard's detection engine, correlates that vulnerability data with the IAM roles, network egress paths, and public invoker bindings unique to serverless container platforms, surfacing risky patterns like an overbroad task role or an allUsers-invokable Cloud Run service before they're exploited. Safeguard generates SBOMs directly from your ECS task definitions and Cloud Run revisions, and ingests SBOMs from existing CI/CD pipelines, so you get a continuous inventory even for workloads that rebuild and redeploy dozens of times a day. When a fix is available, Safeguard opens an auto-fix pull request against the Dockerfile or base image reference rather than leaving remediation as an open ticket, closing the loop from detection to a merged patch without manual triage.