Most container supply chain tooling is built for Kubernetes. Fargate and ECS run containers too, and they run a lot of them, but the security ecosystem around them is thinner and the shape of the problems is different. If your organization runs both Kubernetes and Fargate, you will notice that the supply chain controls you deployed on EKS do not port over cleanly.
I have spent enough time on Fargate workloads to have an opinion about what actually works and what the AWS documentation is quiet about. This is the set of pitfalls to plan around if you are committing to Fargate for production services.
Why does image signing verification not work the same way on Fargate?
Because there is no admission controller to run your signature verification, and ECS does not natively verify Cosign signatures or Sigstore attestations before launching a task. You have to build the verification into your deployment pipeline instead of at runtime entry.
On Kubernetes, an admission webhook can refuse to schedule a pod whose image is not signed. Fargate has no equivalent. An ECS task definition references an image, and Fargate pulls the image from the registry and starts it. There is no hook for you to intercept the pull and verify a signature. ECR image signing — the AWS-native version using AWS Signer — integrates with ECS, but only for AWS Signer–issued signatures, not for Cosign, and the ecosystem tooling does not interoperate cleanly.
The workable pattern is to shift verification left: your CI pipeline verifies signatures on the base images it pulls, your release pipeline verifies signatures on intermediate build artifacts, and the image that gets pushed to ECR is itself signed by your CI identity. The gap is that there is nothing enforcing that the task definition in production references only signed images — you trust your deployment pipeline to only produce task definitions pointing at verified images.
The mitigation for that gap is IAM. Lock down who can call ecs:RegisterTaskDefinition and ecs:UpdateService to a tight set of deployment roles, and audit the full chain. If the only path to updating production is your signed pipeline, the signature story holds transitively. If five humans have console access to register task definitions, it does not.
How do you run vulnerability scanning on Fargate workloads?
ECR scanning runs at push time, not at runtime, and there is no node-level scanning available because there is no node you control. This is a real operational gap and most teams do not notice it until an auditor asks them to prove they know what is running right now.
ECR's enhanced scanning uses Amazon Inspector and updates as new CVEs are disclosed against images already in the registry. This covers the "what vulnerabilities exist in my stored images" question reasonably well, with the caveat that scan results lag CVE publication by some hours to days. What it does not cover is "what is running in production right now." On Kubernetes you can run a DaemonSet that inventories running images on every node and correlates against your vulnerability database. On Fargate, you cannot run a DaemonSet.
The workable answer is to treat the running tasks as equivalent to the task definitions pointing at them, which is true as long as no :latest tags are in use and all image references are digest-pinned. Digest-pin everything. The moment you reference an image by mutable tag, your "what is running" answer and your "what is in the registry" answer drift, and you cannot close the gap.
Even with digest pinning, the scan-to-running correlation still requires a tool that reads your ECS service state, extracts the image digests, and checks them against the vulnerability database. This is work that has no standard solution on AWS. You either build it or you use a third-party platform that does.
Can you do runtime security on Fargate?
Barely. Fargate does not give you a node-level agent deployment option, so eBPF-based tooling like Tetragon or Falco is not available. The closest you get is the Fargate task-level GuardDuty Runtime Monitoring, which AWS operates, or a sidecar pattern that gets limited visibility into the main container.
GuardDuty Runtime Monitoring for Fargate launched in 2023 and provides some process-level visibility — it detects things like cryptominers, reverse shells, and suspicious process executions. It is not as flexible as Tetragon — you cannot write custom eBPF tracing policies, you cannot enforce, you can only consume the detections that AWS produces. For a certain class of threats it is useful. For supply chain–specific runtime behaviors, it is a blunt instrument.
The sidecar pattern is worse than it sounds. A sidecar container in a Fargate task shares a PID namespace with the main container only if you configure it to, and even then it only sees the processes in that task, not the underlying kernel events that eBPF tools depend on. You can detect some things — an outbound connection that shows up in the sidecar's view of /proc/net/tcp — but you cannot do the full-lineage process tracing that the Kubernetes eBPF ecosystem provides.
The honest answer for Fargate runtime security is to compensate with stronger build-time and deploy-time controls, to use GuardDuty Runtime Monitoring where available, and to accept that the runtime-visibility story is weaker than on EKS. If runtime visibility is a hard requirement, run the workload on EKS.
What are the SBOM and attestation pitfalls specific to ECR?
ECR supports OCI artifacts and referrers as of late 2024, so you can attach SBOMs and attestations to images. Until recently this was not true, and a lot of existing tooling and documentation assumes the old limitation. Check your ECR region — not all features roll out everywhere simultaneously.
When it works, the pattern is the same as any other registry: push the image, push the SBOM as an OCI artifact with a subject reference to the image, push the Cosign signature similarly. The referrers API then lets consumers fetch all related artifacts for a given image digest. The ECR-specific pitfalls are around IAM permissions — pushing a referrer artifact requires specific ECR permissions that are not included in the standard ecr:PutImage permission set, and the error messages are unhelpful.
The other ECR-specific issue is cross-account. If your images live in a central ECR registry and are consumed by accounts for different environments, signature and attestation references have to remain valid across accounts. They do, because they reference by digest, but the consumer account needs ecr:BatchGetImage permission on the artifact references, not just on the image itself. This trips up teams the first time they deploy cross-account.
How does task definition churn affect supply chain posture?
Task definitions in ECS are versioned and immutable once registered, which is good for auditing, but task definition families churn rapidly in most organizations. The implication is that an auditor asking "what images were running in production last Thursday" needs you to reconstruct the deployment state at that moment, not just the current state.
CloudTrail captures RegisterTaskDefinition and UpdateService events. With those you can reconstruct the image digest running in each service at any historical point. In practice, most teams do not exercise this capability until they need it for an incident, and the first time is painful. Build the tooling to reconstruct deployment state on demand before you need it.
The related issue is task definition sprawl. Teams produce hundreds of task definitions for the same service over months and never clean them up. This is operationally harmless but makes supply chain analysis harder. A quarterly task definition cleanup — deregister anything not referenced by a current service — keeps the audit surface manageable.
How Safeguard.sh Helps
Safeguard.sh fills the Fargate runtime-visibility gap by combining ECR-attached SBOMs with reachability analysis, so even without eBPF on the node you know which vulnerabilities in running tasks are reachable from the exposed code paths, driving the 60 to 80 percent reduction in noise that makes the weaker runtime signal on Fargate workable. Griffin AI verifies signatures and attestations in the deployment pipeline and generates task definition policies that refuse to register task definitions referencing unsigned images, working on SBOMs with 100-level dependency depth. TPRM tracks third-party image provenance through ECR and cross-account boundaries, and container self-healing rewrites task definitions and triggers UpdateService calls automatically when patched images are available upstream, closing the loop that Fargate's lack of admission control leaves open.