fix(cloud-security): make CloudWatch metric-filter auto-fix reliable

[tofikwest]

Summary

Customer (aymenrc) reported AWS auto-fix falling back to manual steps with "required parameters were not properly provided… metric transformations were not properly provided to the CloudWatch Logs API" on the CIS CloudWatch metric-filter checks (e.g. "CloudTrail config changes — metric filter missing").

That finding is meant to be auto-fixable — the fix is three standard API calls (logs:PutMetricFilter + sns:CreateTopic + cloudwatch:PutMetricAlarm, cloudwatch.adapter.ts:155), not [MANUAL]. So this is a bug, not an inherently-manual finding.

Root cause

PutMetricFilterCommand was not in the executor's REQUIRED_PARAMS, so a step with a missing or mis-shaped metricTransformations wasn't caught before execution — it went to AWS, got rejected, and the system fell back to manual steps. The model commonly emits metricTransformations as a single object instead of an array, or metricValue as the number 1 instead of "1" — both of which AWS rejects.

Fix

• aws-command-executor.ts
  • Add PutMetricFilterCommand to REQUIRED_PARAMS (logGroupName, filterName, filterPattern, metricTransformations) → a missing field now fails fast and triggers the existing AI repair pass instead of dumping to manual steps.
  • Add normalizeMetricFilterTransformations (Rule 5 in normaliseInputParams): wrap a single transformation object in an array, and coerce metricValue to a string. Deterministic guardrail before the SDK call (mirrors the Config-recorder guardrail).
• ai-remediation.prompt.ts: explicit PutMetricFilter shape guidance — metricTransformations as an array, string metricValue, real logGroupName from the read step.
• Tests: REQUIRED_PARAMS enforcement + normalizer cases (object→array, number→string, well-formed untouched, absent no-op).

Notes / caveats

• It's auto-fixable in principle; this makes it reliable instead of an intermittent coin-flip.
• Not yet verified against a live failing finding (no server-side failed-plan for the customer's org) — this addresses the whole failure class, which covers the reported symptom. The exact malformation would be confirmable from his remediation logs.
• Edge case worth knowing: if a trail has no CloudWatch Logs group at all, there's nothing to attach a metric filter to — that's a genuine setup prerequisite, separate from this bug.

Full cloud-security suite green (310 passing); changed files typecheck clean.

🤖 Generated with Claude Code

---

Summary by cubic

Fixes unreliable auto-fix for CloudWatch Logs metric filters by validating required params and normalizing metricTransformations, preventing fallbacks to manual steps on CIS checks.

• Bug Fixes
  • Add PutMetricFilterCommand to REQUIRED_PARAMS (logGroupName, filterName, filterPattern, metricTransformations) to fail early and trigger the repair pass.
  • Add normalizeMetricFilterTransformations to wrap a single object into an array and coerce metricValue to a string.
  • Update ai-remediation.prompt.ts with explicit PutMetricFilter shape guidance and using the real logGroupName from the read step.
  • Add tests for required params and normalization (object→array, number→string, pass-through, absent no-op).

^{Written for commit 837ecde. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
comp-framework-editor	Ready	Preview, Comment	Jun 5, 2026 9:46pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
app	Skipped		Jun 5, 2026 9:46pm
portal	Skipped		Jun 5, 2026 9:46pm

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[claudfuen]

🎉 This PR is included in version 3.73.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀