AntFleet

Disagreement · 4c349ef3-anthropic-2

DynamoDB table uses a hard-coded `table_name` which prevents multi-environment deploys and causes CFN failures on re-creation

mismatch
repo 703f69ec·PR #3·reviewed 5 days ago

Primary finding

DynamoDB table uses a hard-coded `table_name` which prevents multi-environment deploys and causes CFN failures on re-creation

mediummaintainabilityhigh
  • infra/stack.py:64-75
  • infra/stack.py:100-103
Hard-coding `table_name` makes it impossible to deploy this stack twice in the same account/region (e.g., dev + staging), and combined with `RemovalPolicy.RETAIN` any failed delete leaves the table orphaned, blocking re-deploy with the same name. Additionally `DDB_TABLE` env var is a duplicated literal rather than referencing `table.table_name`, so a future rename will silently break the Lambda.

Recommendation

Omit `table_name` (let CDK generate it) and pass `table.table_name` to the Lambda env. If a stable name is required, derive it from `self.stack_name`.

Counterpart finding

Lambda granted read access to entire bucket (over-privileged)

mediumsecurityhigh
  • infra/stack.py:99-101
  • infra/stack.py:131-133
The function appears to only need to read geo-signals/feedback.csv and write to dashboard/*, yet it is granted read on the whole bucket (and likely ListBucket). Over-broad permissions increase blast radius if the function is compromised.

Recommendation

Replace bucket.grant_read(fn) with bucket.grant_read(fn, "geo-signals/feedback.csv") (or a tighter prefix) and, if ListBucket is required, scope it with a condition on s3:prefix to the used keys. Keep bucket.grant_put(fn, "dashboard/*") as-is.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →