Skip to main content
LOWECSOperational Excellence

ECS Task Definition Uses Mutable Image Tag

ecs-task-definition-mutable-image-tag

What this rule checks

Detects ECS task definition containers referencing an image by the mutable "latest" tag or no tag at all, so deployments are not reproducible and a changed upstream image can land without a code change.

How to fix it

  1. 1Reference container images by an immutable tag (release version or git SHA)
  2. 2Or pin the image by @sha256 digest so every deployment runs the exact tested image
FlaggedThe image reference ends in :latest, a mutable tag. Two deployments of the same task definition can pull different code, so releases are not reproducible and a changed upstream image can land with no code change.
import { App, Stack } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ecs from 'aws-cdk-lib/aws-ecs';

// FLAGGED: container image pinned to the mutable 'latest' tag.
new ecs.CfnTaskDefinition(this, 'Task', {
  cpu: '256',
  memory: '512',
  containerDefinitions: [
    {
      name: 'app',
      image: 'public.ecr.aws/nginx/nginx:latest',
      logConfiguration: {
        logDriver: 'awslogs',
        options: { 'awslogs-group': '/ecs/app', 'awslogs-region': 'us-east-1', 'awslogs-stream-prefix': 'app' },
      },
    },
  ],
});
FixedReferencing an immutable version tag (or a @sha256 digest) makes every deployment pull the exact image you tested. The check treats any non-latest, non-empty tag as pinned.
import { App, Stack } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ecs from 'aws-cdk-lib/aws-ecs';

// FIXED: image pinned to an immutable version tag.
new ecs.CfnTaskDefinition(this, 'Task', {
  cpu: '256',
  memory: '512',
  containerDefinitions: [
    {
      name: 'app',
      image: 'public.ecr.aws/nginx/nginx:1.27.3',
      logConfiguration: {
        logDriver: 'awslogs',
        options: { 'awslogs-group': '/ecs/app', 'awslogs-region': 'us-east-1', 'awslogs-stream-prefix': 'app' },
      },
    },
  ],
});

CDK Insights pinpoints the exact file and line in your CDK source for every finding, so you can jump straight to the fix.

Affected resource types

AWS::ECS::TaskDefinition

AWS documentation

Read the AWS guidance

Intentional? Suppress this finding

Sometimes a flag is deliberate โ€” a genuinely public endpoint, say. You can dismiss ecs-task-definition-mutable-image-tag and the reason is kept in the report, not silently hidden.

In .cdk-insights.json:

{
  "ignoreRules": [
    { "id": "ecs-task-definition-mutable-image-tag", "reason": "Why this is intentional" }
  ]
}

Or inline in your CDK code:

Validations.of(scope).acknowledge({
  id: 'cdk-insights::ecs-task-definition-mutable-image-tag',
  reason: 'Why this is intentional',
});

Use the rule ID ecs-task-definition-mutable-image-tag shown above โ€” not the CDK-* ID from SARIF / GitHub code scanning. To dismiss every finding on one construct instead, use ignorePaths. Suppression docs โ†’

Catch this in your stack

$ npx cdk-insights scan

CDK Insights runs this and 118+ other rules locally against your synthesised CDK app โ€” free, no account, your code never leaves your machine.

More ECS rules