If you run production workloads on AWS, your software supply chain is a target. Every dependency you pull, every container image you deploy, and every build artifact that flows through your CI/CD pipeline represents a potential entry point for attackers. The SolarWinds and Codecov incidents proved that supply chain compromises are not theoretical -- they are active, well-funded, and devastatingly effective.
This post covers the practices that actually matter when securing your supply chain on AWS. Not the marketing fluff. The stuff that stops real attacks.
Understanding the AWS Supply Chain Attack Surface
Your AWS supply chain is broader than you think. It includes:
- Source code repositories and their integrations with CodeCommit or third-party SCMs
- Build environments in CodeBuild, including the base images those builds run on
- Package dependencies pulled during build time from npm, PyPI, Maven Central, and others
- Container base images pulled from Docker Hub, ECR Public, or other registries
- Infrastructure-as-Code templates that define your deployment topology
- Third-party Lambda layers and shared AMIs
Each of these represents a trust boundary. And most teams treat them as implicitly trusted, which is exactly the assumption attackers exploit.
Lock Down Your Container Image Supply Chain
ECR should be your single source of truth for container images. Pulling directly from Docker Hub in production is asking for trouble. Here is what a solid ECR strategy looks like:
Enable ECR image scanning. Turn on both basic scanning (powered by Clair) and enhanced scanning (powered by Amazon Inspector). Basic scanning catches known CVEs on push. Enhanced scanning provides continuous monitoring and richer vulnerability data.
Use immutable image tags. Configure your ECR repositories with immutable tags so that a v1.2.3 tag always points to the same image digest. This prevents tag mutation attacks where an attacker overwrites a tag with a compromised image.
Implement image signing. Use AWS Signer with Notation to sign your container images after they pass your security checks. Then enforce signature verification at deployment time. This creates a cryptographic chain of trust from build to deploy.
Restrict ECR access with resource policies. Your production ECR repositories should only accept pushes from your CI/CD pipeline roles. No developer should be able to push directly to production registries.
Harden CodePipeline and CodeBuild
Your CI/CD pipeline is the crown jewel of your supply chain. If an attacker compromises it, they can inject malicious code into every deployment.
Use dedicated build roles with minimal permissions. Your CodeBuild service role should have only the permissions it needs. Do not give it AdministratorAccess because it is "easier." Map out exactly what resources your build needs to touch and scope the IAM policy accordingly.
Pin your CodeBuild images. Do not use aws/codebuild/standard:latest. Pin to a specific image version and update deliberately. A compromised build image means every build is compromised.
Enable build logging and audit trails. Send CodeBuild logs to CloudWatch and enable CloudTrail for all CodePipeline API calls. You need to know who changed what in your pipeline and when.
Isolate build environments. Use VPC-configured CodeBuild projects with no internet access for sensitive builds. Pull dependencies from CodeArtifact or a private repository mirror instead of reaching out to the public internet during builds.
Manage Dependencies with CodeArtifact
AWS CodeArtifact is underused and underappreciated. It gives you a managed artifact repository that sits between your builds and the public package registries.
Mirror public packages. Configure CodeArtifact as an upstream proxy for npm, PyPI, and Maven Central. This caches packages locally and gives you a single chokepoint to monitor and control what enters your build environment.
Enable package origin controls. CodeArtifact lets you restrict whether a package can come from upstream (public) sources or must be published internally. Use this to prevent dependency confusion attacks where an attacker publishes a malicious package with the same name as your internal package but a higher version number.
Audit package consumption. CloudTrail logs every package download from CodeArtifact. Use these logs to detect unusual dependency patterns -- a build suddenly pulling a package it has never used before should trigger an alert.
Implement Software Bill of Materials
An SBOM is not just a compliance checkbox. It is an operational tool that tells you exactly what is inside your deployed artifacts.
Generate SBOMs at build time. Integrate tools like Syft or Trivy into your CodeBuild buildspec to produce CycloneDX or SPDX SBOMs for every build artifact. Store these SBOMs in S3 alongside the artifact they describe.
Track SBOMs across environments. When an artifact moves from staging to production, its SBOM should follow. You need to know what is running in production at any given moment, down to the transitive dependency level.
Automate SBOM analysis. An SBOM sitting in S3 is useless if nobody looks at it. Set up automated analysis that cross-references your SBOMs against vulnerability databases and alerts when a newly disclosed CVE affects something you have deployed.
Network-Level Controls
Supply chain attacks often involve exfiltrating data or pulling malicious payloads from attacker-controlled infrastructure. Network controls add a critical layer of defense.
Use VPC endpoints for AWS services. Configure VPC endpoints for ECR, S3, CodeArtifact, and other services your build environment touches. This keeps traffic on the AWS network and lets you enforce endpoint policies.
Restrict outbound access. Your build environments and production workloads should not have unrestricted internet access. Use security groups and NACLs to limit outbound connections to known-good destinations.
Monitor DNS queries. Route 53 Resolver query logging can reveal when your workloads are resolving suspicious domains -- a common indicator of supply chain compromise.
Secrets Management
Hardcoded secrets in source code or environment variables are a supply chain gift to attackers.
Use AWS Secrets Manager or Parameter Store. Reference secrets at runtime, never at build time. Your buildspec should pull secrets from Secrets Manager, not from environment variables baked into the CodeBuild project.
Rotate credentials automatically. Secrets Manager supports automatic rotation for RDS credentials and other secret types. Use it. A compromised credential that rotates every 24 hours is far less valuable than one that has been static for two years.
Audit secret access. Monitor CloudTrail for GetSecretValue API calls. Any unexpected access patterns should trigger an investigation.
Monitoring and Detection
Prevention is ideal but detection is essential. You need to know when something in your supply chain has been compromised.
Enable GuardDuty. GuardDuty monitors for malicious activity and unauthorized behavior across your AWS accounts. It can detect compromised credentials, unusual API calls, and cryptocurrency mining -- all potential indicators of a supply chain breach.
Set up Config Rules. AWS Config can continuously evaluate your resources against security baselines. Create rules that detect when ECR scanning is disabled, when build roles have excessive permissions, or when pipeline configurations change unexpectedly.
Implement anomaly detection. Use CloudWatch anomaly detection on your build metrics. A build that suddenly takes three times longer or produces an artifact twice the normal size could indicate tampering.
Incident Response Planning
When (not if) a supply chain incident happens, you need a plan.
Maintain an asset inventory. Know exactly what is deployed, where it came from, and what dependencies it includes. SBOMs are critical here.
Practice containment procedures. Can you quickly isolate a compromised service? Can you roll back to a known-good artifact? Test these procedures before you need them.
Establish communication channels. Supply chain incidents often span multiple teams. Have pre-established channels and escalation paths so you are not figuring out who to call during an active incident.
How Safeguard.sh Helps
Safeguard.sh integrates directly with your AWS environment to provide continuous supply chain security. It automatically generates and tracks SBOMs for every artifact in your ECR repositories, monitors your CodePipeline builds for dependency anomalies, and provides a single dashboard that shows your complete supply chain posture across all AWS accounts.
Instead of stitching together a dozen AWS-native tools and open-source scanners, Safeguard.sh gives you a unified platform that correlates vulnerability data with actual deployment context. You see not just that a CVE exists, but whether it affects something running in production, what the blast radius looks like, and what you should fix first.
Your AWS supply chain is only as strong as its weakest link. Start hardening it today.