fix(cloud-security): AWS Config new recording model + GCP/Azure remediation robustness

[tofikwest]

Summary

Customer-reported (Ian Hunter): AWS auto-remediation for "AWS Config recorder not fully active" generated empty configs, the Retry button did nothing, and applying a generated fix failed and fell back to dated manual steps. Root cause: the Config check + auto-fix only understood AWS's legacy recordingGroup.allSupported model, but the customer's recorder uses AWS's current model ("Record all resource types with customizable overrides" = recordingStrategy / exclusionByResourceTypes).

While fixing AWS, an audit found the same robustness bugs (Retry no-op, empty-plan handling) living in the separate GCP and Azure remediation paths, so this PR brings all three to parity.

What changed

AWS-specific

• Config recorder check (config.adapter.ts) now treats recordingStrategy.useOnly === 'ALL_SUPPORTED_RESOURCE_TYPES' (and legacy allSupported) as "records all" → eliminates false positives on the new model. Genuine EXCLUSION/INCLUSION recorders stay flagged.
• Config remediation now produces an AWS-valid call: read the existing recorder, then PutConfigurationRecorder with a clean recordingGroup { allSupported: true, includeGlobalResourceTypes: true } and no recordingStrategy/exclusionByResourceTypes/resourceTypes (those are mutually exclusive with allSupported and trigger a ValidationException). Also records the global IAM resource types the customer was missing.
• Deterministic executor guardrail (aws-command-executor.ts → normalizeConfigRecordingGroup) collapses any all-supported-intent PutConfigurationRecorder to the single valid shape right before the SDK call, regardless of what the AI emits.

Cross-provider robustness (AWS + GCP + Azure)

• Retry no-op fixed: never cache an empty / non-auto-fixable plan, and drop the stale cache entry on execute. Previously execute reloaded the same dead plan, so Retry failed identically every time.
• Empty-plan retry: generateFixPlan / generateGcpFixPlan / generateAzureFixPlan retry once at a higher temperature when the first pass yields zero fix steps (temperature 0 just reproduced the same empty result).
• Azure: if the refined plan flips canAutoFix to false after reading real state, return guided steps instead of a misleading auto-fix preview; delete the cached plan in the execute catch block.

Frontend (shared, all providers)

• RemediationDialog.tsx: disable Apply Fix on an empty plan and explain why.

Prompts

• Discourage S3 ACL steps (a common cause of empty plans), reinforce the valid Config recorder call, and base manual steps on the current AWS Console.

Tests

• New config.adapter.spec.ts (recording-model awareness + AWS-valid remediation text).
• New normalizeConfigRecordingGroup cases, AWS + GCP + Azure empty-plan retry cases, and isUsablePlan cache-guard cases.
• Full cloud-security jest suite green (292 passing). All changed files typecheck clean.

Deploy / customer impact

• No DB migration, no env changes, no manifest change, no reconnection. Applies to existing connections.
• Takes effect after apps/api + apps/app deploy; the corrected check re-evaluates on the next scan.

⚠️ Not yet verified

• No live apply against a real AWS/GCP/Azure account yet — the only true proof for remediation that mutates infra. Recommend an impersonated end-to-end Auto-Remediate (start with Ian's AWS Config finding) before declaring the ticket resolved.
• Ian's finding won't auto-clear on the next scan (his recorder genuinely excludes IAM) — he must click Auto-Remediate, and may need a one-time config:* permission grant on CompAI-Remediator (surfaced in-product).

Flagged but intentionally NOT fixed here (separate scope / higher risk)

• GCP/Azure scanners swallow per-adapter/per-scope errors → a real API/permission failure can look like "0 findings."
• GCP Cloud SQL databaseFlags is a REPLACE op with no guard that existing flags are preserved; disabling public IP has no private-IP precondition check.

🤖 Generated with Claude Code

---

Summary by cubic

Supports AWS Config’s current recording model and fixes auto‑remediation so plans apply cleanly and Retry regenerates instead of doing nothing. Also hardens GCP and Azure remediation to avoid empty plans and no‑op retries, and aligns prompt command outputs with the executor.

• Bug Fixes
  • AWS Config: check recognizes recordingStrategy.useOnly === 'ALL_SUPPORTED_RESOURCE_TYPES' (and legacy allSupported) as “records all.” Remediation uses { recordingGroup: { allSupported: true, includeGlobalResourceTypes: true } } with no recordingStrategy/exclusionByResourceTypes/resourceTypes. The executor normalizes recorder payloads to this valid shape.
  • Caching/Retry (AWS/GCP/Azure): never cache empty or non‑auto‑fixable plans; on execute, only reuse fresh and usable cached plans, otherwise drop and regenerate. Generators retry once at a higher temperature when the first plan is empty, and prefer a retry that either has steps or correctly sets canAutoFix to false (routes to guided steps).
  • Azure/Frontend: Azure returns guided steps if canAutoFix flips to false and deletes failed cached plans so Retry regenerates. The UI disables Apply Fix on an empty plan and explains why.
  • Prompts: use bare AWS SDK command names (service named separately) to match output rules; add the missing GetBucketPolicyCommand; remove PutBucketAcl from the permissions chain and reinforce “never use ACLs”; reiterate the valid Config recorder call.

^{Written for commit 432fd39. Summary will update on new commits.}

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
app	Ready	Preview, Comment	Jun 4, 2026 10:38pm
comp-framework-editor	Ready	Preview, Comment	Jun 4, 2026 10:38pm
portal	Ready	Preview, Comment	Jun 4, 2026 10:38pm

[cubic-dev-ai]

4 issues found across 12 files

Confidence score: 3/5

• There is a concrete regression risk in apps/api/src/cloud-security/ai-remediation.prompt.ts: the new service-prefixed command naming can conflict with the command schema and produce invalid AWS SDK command values.
• The same prompt file also has inconsistent command formatting (GetBucketPolicy missing Command) and conflicting ACL guidance, which can lead to remediation output that fails validation or gives mixed instructions.
• apps/api/src/cloud-security/ai-remediation.service.ts has retry-handling logic that may discard valid non-auto-fix retry results and still return an unusable empty canAutoFix=true plan, which is user-impacting behavior.
• Pay close attention to apps/api/src/cloud-security/ai-remediation.prompt.ts, apps/api/src/cloud-security/ai-remediation.service.ts - command/schema consistency and empty-plan retry selection need verification.

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[claudfuen]

🎉 This PR is included in version 3.70.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀