Skill Being Reviewed
Skill name: �ws-review
Skill path: skills/cloud/aws-review/
False Positive Analysis
Benign configuration that should not be over-flagged:
`hcl
resource "aws_ecr_repository" "dev" {
name = "dev-scratch"
image_tag_mutability = "IMMUTABLE_WITH_EXCLUSION"
image_tag_mutability_exclusion_filter {
filter_type = "WILDCARD"
filter = "latest-dev"
}
}
`
Why this is a false positive:
Modern ECR supports tag immutability with limited exclusions. A review should not fail every mutable-tag exception if the exception is documented, scoped to non-release tags, and production releases are immutable or digest-pinned.
Coverage Gaps
Missed variant 1: mutable production ECR tags
hcl resource "aws_ecr_repository" "api" { name = "prod-api" image_tag_mutability = "MUTABLE" }
Why it should be caught:
Mutable image tags allow a tag such as prod or �1.2.3 to be overwritten after deployment evidence is captured. That weakens rollback, provenance, and incident-response confidence.
Missed variant 2: repository has no scan-on-push or enhanced scanning evidence
hcl resource "aws_ecr_repository" "worker" { name = "prod-worker" }
Why it should be caught:
The current AWS review focuses on CIS Foundations controls and misses ECR scanning posture. Reviewers should ask whether repositories use scan-on-push, registry-level enhanced scanning, or Amazon Inspector continuous scanning.
Missed variant 3: broad ECR repository policy or no lifecycle/rollback evidence
json { "Effect": "Allow", "Principal": "*", "Action": ["ecr:BatchGetImage", "ecr:PutImage"] }
Why it should be caught:
Broad push/pull access can let untrusted principals publish or consume images, and lifecycle policies should preserve release tags or digests needed for rollback and investigations.
Edge Cases
- ECR checks are supplemental and should not be counted as CIS AWS Foundations recommendations.
- Repository-level scan-on-push may be absent when registry-level enhanced scanning is enabled; the review should accept registry-level evidence.
- Mutable tags may be acceptable in isolated development repositories with documented exclusions.
Remediation Quality
Sources Checked
Bounty Info
Skill Being Reviewed
Skill name: �ws-review
Skill path: skills/cloud/aws-review/
False Positive Analysis
Benign configuration that should not be over-flagged:
`hcl
resource "aws_ecr_repository" "dev" {
name = "dev-scratch"
image_tag_mutability = "IMMUTABLE_WITH_EXCLUSION"
image_tag_mutability_exclusion_filter {
filter_type = "WILDCARD"
filter = "latest-dev"
}
}
`
Why this is a false positive:
Modern ECR supports tag immutability with limited exclusions. A review should not fail every mutable-tag exception if the exception is documented, scoped to non-release tags, and production releases are immutable or digest-pinned.
Coverage Gaps
Missed variant 1: mutable production ECR tags
hcl resource "aws_ecr_repository" "api" { name = "prod-api" image_tag_mutability = "MUTABLE" }Why it should be caught:
Mutable image tags allow a tag such as prod or �1.2.3 to be overwritten after deployment evidence is captured. That weakens rollback, provenance, and incident-response confidence.
Missed variant 2: repository has no scan-on-push or enhanced scanning evidence
hcl resource "aws_ecr_repository" "worker" { name = "prod-worker" }Why it should be caught:
The current AWS review focuses on CIS Foundations controls and misses ECR scanning posture. Reviewers should ask whether repositories use scan-on-push, registry-level enhanced scanning, or Amazon Inspector continuous scanning.
Missed variant 3: broad ECR repository policy or no lifecycle/rollback evidence
json { "Effect": "Allow", "Principal": "*", "Action": ["ecr:BatchGetImage", "ecr:PutImage"] }Why it should be caught:
Broad push/pull access can let untrusted principals publish or consume images, and lifecycle policies should preserve release tags or digests needed for rollback and investigations.
Edge Cases
Remediation Quality
Sources Checked
Bounty Info