Implementing Container Signing in Your CI/CD Pipeline: A DevSecOps Approach with AWS

Introduction

This article is part of my ongoing series about DevOps and DevSecOps practices. If you've been following along, you may have read my previous articles on the evolution of DevSecOps and how NIST guidelines enhance software security.

In my NIST article, I discussed how security should be embedded into every stage of the Software Development Life Cycle (SDLC). I also mentioned tools like AWS CodeBuild, CodePipeline, and SecurityHub as part of a DevSecOps pipeline. Today, I want to add another critical piece to that puzzle: Container Signing.

As someone who has been working with CI/CD pipelines for several years, I've noticed that container signing is often the "forgotten step" in many pipelines. Teams invest heavily in SAST, DAST, and SCA scanning, but skip image signing because it used to be complex to implement. With AWS's new Managed Signing feature released in November 2025, that excuse no longer holds.

Let me walk you through why container signing matters in DevSecOps and how to integrate it into your CI/CD pipeline.

Why Container Signing Matters in DevSecOps

In my previous article about DevSecOps evolution, I explained the concept of "shifting security left" — integrating security practices early in the development process rather than treating it as an afterthought. Container signing is a perfect example of this principle in action.

What Problem Does It Solve?

Think about your current CI/CD pipeline. You probably have something like this:

But here's a question I often ask teams: How do you know the image you're deploying is the same image that passed your security scans?

Between your build stage and deployment stage, several things could go wrong:

• Someone could push a modified image to your registry
• A compromised CI/CD runner could inject malicious code
• An attacker could perform a man-in-the-middle attack

Without container signing, you're essentially trusting that nothing bad happened between your build and deploy stages. In DevSecOps, we call this a supply chain risk.

The DevSecOps Pipeline: Where Container Signing Fits

Let me show you where container signing fits in a proper DevSecOps pipeline. This builds on the pipeline I discussed in my NIST article:

Notice the SIGN and VERIFY stages. These are what most pipelines are missing. Let me explain each:

SIGN Stage: After your image passes all security scans (SAST, DAST, SCA, vulnerability scanning), it gets signed. This signature proves that the image has been vetted and approved for deployment.

VERIFY Stage: Before deployment, an admission controller checks the signature. If the signature is invalid or missing, the deployment is blocked. No exceptions.

This approach aligns with what NIST calls "verifying the integrity of software components" — one of the key recommendations I highlighted in my previous article.

The Old Way vs The New Way

Before we dive into implementation, let me share why container signing was often skipped in CI/CD pipelines.

The Old Way (Before November 2025)

To sign containers, you had to:

1. Install Notation CLI on your build server
2. Install AWS Signer plugin
3. Configure authentication between Notation and ECR
4. Manage signing keys and certificates
5. Add multiple commands to your buildspec.yml
6. Handle token refresh (tokens expire after 12 hours)
7. Troubleshoot cryptographic errors

For teams already juggling complex pipelines, this was too much overhead. I've seen many teams evaluate container signing and decide "we'll implement it later" — and later never comes.

The New Way (AWS Managed Signing)

With AWS Managed Signing, the process becomes:

1. Create a signing profile (one-time setup)
2. Create a signing rule in ECR (one-time setup)
3. Push your image — it's automatically signed

No changes to your buildspec.yml. No additional tools to install. No keys to manage.

This is the kind of simplification that makes DevSecOps adoption realistic for teams of all sizes.

Setting Up Container Signing in Your CI/CD Pipeline

Let me walk you through how to integrate container signing into your existing AWS CI/CD pipeline.

Prerequisites

Before we start, you should have:

• An existing CI/CD pipeline using CodePipeline and CodeBuild
• Container images stored in Amazon ECR
• Basic understanding of IAM permissions

Step 1: Create an AWS Signer Signing Profile

The signing profile defines how your images will be signed. Think of it as a template for your signatures.

Go to AWS Signer in the console:

1. Click Create signing profile
2. Select Notation for container registries as the platform
3. Enter a profile name (e.g., production-container-signing)
4. Set the signature validity period (I recommend starting with the default 135 months)
5. Click Create

Pro Tip: Create separate signing profiles for different environments. I typically use:

• dev-container-signing for development
• staging-container-signing for staging
• production-container-signing for production

This allows you to track which environment an image was approved for.

Step 2: Configure ECR Managed Signing

Now, tell ECR to automatically sign images when they're pushed.

In the ECR console:

1. Go to Private registry → Features & settings
2. Under Managed Signing, click Configure
3. Click Create rule
4. Select your signing profile from Step 1
5. Add a repository filter (e.g., prod-* to sign all production repositories)
6. Click Create

That's it for the signing setup. Your images will now be automatically signed when pushed to matching repositories.

Step 3: Update Your CI/CD Pipeline

Here's the beauty of AWS Managed Signing: you don't need to change your buildspec.yml.

Your existing buildspec probably looks something like this:

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $ECR_REGISTRY

  build:
    commands:
      - echo Building Docker image...
      - docker build -t $IMAGE_NAME:$IMAGE_TAG .
      - docker tag $IMAGE_NAME:$IMAGE_TAG $ECR_REGISTRY/$IMAGE_NAME:$IMAGE_TAG

  post_build:
    commands:
      - echo Pushing to ECR...
      - docker push $ECR_REGISTRY/$IMAGE_NAME:$IMAGE_TAG

With managed signing enabled, the signing happens automatically during docker push. No additional commands needed.

Step 4: Implement Signature Verification

Signing is only half of the equation. To complete the security chain, you need to verify signatures before deployment.

For Amazon EKS

If you're using EKS, you can implement verification using admission controllers like Kyverno or Ratify. These controllers intercept pod creation requests and verify the container image signature before allowing deployment.

Here's a simple example of what a Kyverno policy might look like:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-container-signatures
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-signature
      match:
        any:
        - resources:
            kinds:
              - Pod
      verifyImages:
      - imageReferences:
        - "*.dkr.ecr.*.amazonaws.com/*"
        required: true

This policy enforces that all images from ECR must have a valid signature. If an unsigned image is deployed, the pod creation will be rejected.

For Amazon ECS

For ECS, you can use service lifecycle hooks with Lambda to verify signatures before deployment. The Lambda function runs during the PRE_SCALE_UP phase, checking the signature before any containers are started.

Step 5: Enable Audit Logging

As I mentioned in my NIST article, traceability is crucial for compliance. AWS CloudTrail automatically logs all signing operations, giving you a complete audit trail.

Make sure CloudTrail is enabled in your account, and you'll have records of:

• Who pushed the image
• When it was signed
• Which signing profile was used
• The signature details

This information is invaluable for security audits and incident response.

Connecting to Your DevSecOps Toolchain

Container signing doesn't exist in isolation. It's part of a broader DevSecOps strategy. Here's how it connects to other AWS security services I've discussed in my previous articles:

Stage	AWS Service	Purpose
Code Quality	CodeGuru	Identify code issues early
Vulnerability Scan	Amazon Inspector	Find CVEs in your images
Image Signing	AWS Signer + ECR	Prove image authenticity
Secret Management	Secrets Manager	Secure credentials in pipeline
Deployment Verification	Admission Controller	Block unsigned images
Monitoring	SecurityHub	Aggregate security findings
Audit	CloudTrail	Track all security events

When all these pieces work together, you have a comprehensive DevSecOps pipeline that addresses security at every stage — exactly what NIST recommends.

Common Mistakes to Avoid

Based on my experience implementing DevSecOps pipelines, here are some mistakes I've seen teams make with container signing:

Mistake 1: Signing but not verifying

Some teams implement signing but forget to enforce verification. This gives you a false sense of security. Always implement admission controllers or lifecycle hooks to verify signatures before deployment.

Mistake 2: Using the same signing profile for all environments

If your dev and production images use the same signing profile, a dev image could theoretically be deployed to production. Use separate profiles for different environments.

Mistake 3: Not integrating with your security dashboard

Container signing generates valuable security data. Make sure it flows into SecurityHub so your security team has visibility into your signing operations.

Mistake 4: Skipping the audit trail

CloudTrail logs are essential for compliance. Don't disable them thinking it will save costs — the compliance risk is not worth it.

The Business Case for Container Signing

If you need to convince your team or management to implement container signing, here are the key points:

Compliance: NIST, SOC2, PCI-DSS, and ISO 27001 all have requirements around software integrity. Container signing helps meet these requirements.

Risk Reduction: Supply chain attacks like SolarWinds showed us what happens when software integrity is compromised. Container signing is a preventive control.

Operational Simplicity: With AWS Managed Signing, the implementation cost is minimal. It's essentially a few clicks to set up.

Audit Readiness: When auditors ask "how do you verify the integrity of your deployments?", you'll have a clear answer with evidence in CloudTrail.

Conclusion

Container signing is a critical component of a mature DevSecOps pipeline. It bridges the gap between your security scanning stages and your deployment stages, ensuring that only verified, approved images make it to production.

What I appreciate most about AWS Managed Signing is that it removes the barriers to adoption. In the past, teams had legitimate reasons to skip container signing — it was complex and time-consuming. Now, with just a few clicks, you can add this security layer to your CI/CD pipeline without modifying your build scripts.

If you've been following my DevSecOps series, you'll see how container signing fits into the bigger picture. It's a practical implementation of the NIST guidelines I discussed previously, and it strengthens the "shift left" approach I outlined in my DevSecOps evolution article.

My recommendation? Start small. Enable managed signing for one repository, verify it works, and then expand to your entire pipeline. Security is a journey, not a destination.

I think that's it for now for this article. Leave a comment below. So, I know about your thoughts! Thanks.