[tofikwest]

Customer report (Dustin)

"that does not tell me the instance info. It is also not at all clear how to add the same check for another instance. I have given 3 aws instances to the system."

On the "S3 — default encryption enabled" evidence check he sees 31 buckets passing but with no indication of which of his 3 AWS accounts each belongs to, and it's unclear how the other accounts are covered.

Root cause (verified)

• Integration-platform checks run per connection (1 AWS account = 1 connection), so all 3 accounts are already scanned — this part isn't broken.
• But the account is never put in the finding. s3.ts already derived the account id (accountIdFromCtx → roleArn) for its own logic, yet evidence was just {bucket, encrypted}. The UI groups by check and shows no account → a merged, unlabeled list. So "which instance?" and "how do I add it for another instance?" are really one gap: no per-account attribution.

Fix

All six AWS checks (s3, cloudtrail, ec2, iam, kms, rds) emit through the shared emitOutcomes(), so I stamp the account there in one place:

• awsAccountIdFromCtx() (moved to shared.ts, exported) derives the 12-digit account id from the connection's roleArn.
• Every finding now gets evidence.awsAccountId and the account appended to the visible description: … (AWS account 123456789012).

So each result shows its account regardless of how the UI groups them, which also makes it clear all connected accounts are covered. No schema/API/UI change or migration. Key-auth connections (no role ARN) are left unattributed gracefully.

Tests

aws-checks.test.ts (bun): awsAccountIdFromCtx extraction + malformed/missing → null; emitOutcomes stamps account into evidence + description on pass and fail, preserves original evidence, and leaves findings unattributed when there's no role ARN. 41 pass; package builds + typechecks clean.

Caveats / notes

• Covers the main pass/fail findings (which flow through emitOutcomes). The rare direct ctx.fail() error paths (e.g. "Could not assume AWS role", "Could not verify S3 encryption") are not stamped — edge cases, can follow up if needed.
• Not live-tested against the customer's accounts; needs a re-run after deploy so findings regenerate with the account.
• Bonus: once labeled, this also reveals whether all 3 of his accounts are actually producing results — if one account is missing, that's a separate connection/run issue we'd investigate then.

🤖 Generated with Claude Code

---

Summary by cubic

Fixes multi-account AWS check findings by attributing each result to its AWS account, and shows the customer's connection name when set. Adds the account ID (and connection name) to evidence and descriptions so users can see which account each resource belongs to, with no schema or UI changes.

• Bug Fixes
  • Centralized account ID extraction via awsAccountIdFromCtx() (from roleArn) and used across all AWS checks.
  • emitOutcomes() stamps awsAccountId and optional awsConnectionName into evidence and appends "(AWS account … — name)" to pass/fail descriptions.
  • Gracefully skips attribution for key-based connections without a roleArn.
  • Added unit tests for extraction, pass/fail attribution, missing-ARN cases, and connection name labeling.

^{Written for commit 69c84c8. 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 9, 2026 3:42pm
comp-framework-editor	Ready	Preview, Comment	Jun 9, 2026 3:42pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
portal	Skipped		Jun 9, 2026 3:42pm

[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.74.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀