Adam Moussa 59852eff34 fix(iam): restore four permissions the boundary would have denied at migration ... /sh-security-review (6 detectors + verifier) found four HIGH findings, all the same defect class: the template's permission-source comment block was used as the sanctioned scope source, but it is an incomplete and in places invented secondary record. Each was verified against the real stack template before fixing. None is live today (prod/dev boundary usage is 0); all four would have been AccessDenied at first migration, three of them SILENTLY. - SES configuration-set/seahaven-email-events restored. afterhours-shift-manager template.yaml:178-181 grants it with an in-repo comment stating the send is denied without it. An earlier revision dropped it after checking whether any config set exists in prod/dev today (none do) -- the wrong test. The right question is whether an enumerated stack's own IAM policy names it. - SES identity/seahavenind.com added. meal-order-manager's SenderEmail defaults to adam@seahavenind.com (template.yaml:20-22) and email_report sends with it. The prior 'unverified identity fails loudly anyway' argument holds only until the migration verifies the domain, which the migration procedure requires. - scheduler:Create/Delete/GetSchedule + iam:PassRole (scheduler.amazonaws.com only) added. afterhours template.yaml:110-120 needs both; the block omitted them entirely. Failure is silent -- app.py wraps create_schedule in a bare except, so the Slack command reports success and no schedule exists. - secret:afi-slack-webhook-* added. The block named 'afi-backup-monitor/slack-webhook-url', which does not exist; both afi secret ARNs are deploy parameters, so the real names live only in that repo's README:48-49 (afi-api-key, afi-slack-webhook). Also corrected, all comment-only: - The permission-source block itself, at each of the four points it was wrong, with the correction and its evidence recorded inline. - The false claim that SAM auto-names async DLQs (it does not -- all four payments queues are hand-written with explicit QueueNames). Replaced with the real invariant: any queue a boundary-carrying function sends to must be payments-* or the boundary widens in the same PR; a denied destination write is silent. - SIZE BUDGET: was 13 statements / 4,060 chars, actually 16 / 5,457 after these fixes. Headroom is 687 chars, roughly ONE more workload -- not the five the header claimed. Flagged per-workload boundaries as the realistic next move. Verified unchanged: logical id LambdaExecutionBoundary and ManagedPolicyName seahaven-lambda-execution-boundary, so all eight pinning conditions across both guardrail policies still resolve.		2026-07-30 18:17:16 -04:00
..
deploy-substrate.template.yaml	fix(iam): restore four permissions the boundary would have denied at migration	2026-07-30 18:17:16 -04:00