fix(cloud-security): run task evidence checks against all connected accounts#3067
Conversation
…ccounts A task's evidence check (e.g. AWS S3 — default encryption) only ran against the customer's FIRST connected account: the run-check endpoint ran the single referenced connectionId, and the task card showed only the latest single run. Customers with multiple AWS accounts saw results for just one of them. Manual Run now runs the check against EVERY active account of the provider (one IntegrationCheckRun per account, preserving reconciliation's per-connection findingKey diffing) and aggregates task status across all of them. The scheduler already ran every account per-connection, so it needs no run-level change — the same display fix surfaces all accounts for scheduled runs too. Display: /runs now guarantees the latest run per (connection, check) via a groupBy + completeness query (a flat row limit could bury an account behind a busier one's re-runs) and returns connectionId + a connection label. The task card groups runs per account and aggregates the header across accounts; single-account layout is unchanged. Covers all AWS check services (s3, cloudtrail, ec2, iam, kms, rds) since the change is account-level, not per-service. Extracted CheckRunItem/GroupedCheckRuns into check-run-history.tsx (the source file was 1610 lines) and added pure grouping helpers. DS migration of the moved legacy imports is intentionally out of scope (verbatim move; parent tree still uses them). Tests: per-account run loop + aggregate status + bad-account resilience (controller), latest-per-account completeness under a re-run burst (repository), account label branches (util), and run grouping/summary (app). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
2 issues found across 12 files
Confidence score: 3/5
- There is some merge risk because both reported issues are medium severity (6/10) with high confidence, and each can affect runtime behavior in production paths.
- In
apps/api/src/integration-platform/repositories/check-run.repository.ts, unvalidatedhistoryPerGroupis used intake, which can cause 500 errors or unexpectedly heavy database reads from malformed/large query inputs. - In
apps/api/src/integration-platform/controllers/task-integrations.controller.ts, manual runs may execute checks for non-active connections due to fallback behavior, creating a concrete risk of incorrect check execution. - Pay close attention to
apps/api/src/integration-platform/repositories/check-run.repository.ts,apps/api/src/integration-platform/controllers/task-integrations.controller.ts- input bounds/status validation gaps can lead to expensive queries and invalid manual-run execution.
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
…onnections Addresses two cubic review findings on PR #3067: - check-run.repository.ts: clamp historyPerGroup (which flows from the user-supplied ?limit= query param via parseInt → possibly NaN/negative/huge) to [1, 50], defaulting to 5, so it can never produce an invalid Prisma take (500) or an unbounded, expensive read. - task-integrations.controller.ts: restore the active-status guard on the referenced connection (dropped during the run-all-accounts refactor) so a manual run rejects an inactive connection up front; the empty-active fallback can now only ever contain a verified-active connection. Tests: historyPerGroup clamp (oversized → cap, NaN/negative → default) and inactive-connection rejection. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@cubic-dev-ai review it |
@tofikwest I have started the AI code review. It will take a few minutes to complete. |
There was a problem hiding this comment.
1 issue found across 12 files
Confidence score: 2/5
- High merge risk: this is a concrete authorization gap (severity 8/10, confidence 8/10) with likely user-facing security impact, so this should be fixed before merging.
- In
apps/api/src/integration-platform/controllers/task-integrations.controller.ts, the runs endpoint queries bytaskIdwithout confirming the task belongs to the caller’s organization, which can expose cross-tenant run data. - Pay close attention to
apps/api/src/integration-platform/controllers/task-integrations.controller.ts- enforce tenant scoping/ownership checks ontaskIdlookups in the runs endpoint.
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
Addresses a cubic finding on PR #3067 (pre-existing on main): GET :taskId/runs read check runs by taskId with no organization check, so an arbitrary taskId from another org would leak cross-tenant run data (account ids, connection labels, logs). Add @organizationId and validate the task belongs to the caller's org (404 otherwise) before returning runs — mirroring runCheckForTask / getChecksForTask. Test: rejects a task outside the caller's org and never queries runs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@cubic-dev-ai review it |
@tofikwest I have started the AI code review. It will take a few minutes to complete. |
## [3.74.2](v3.74.1...v3.74.2) (2026-06-09) ### Bug Fixes * **cloud-security:** run task evidence checks against all connected accounts ([bdb6b3b](bdb6b3b)) * **cloud-security:** tenant-scope the task check-runs endpoint ([612d624](612d624)), closes [#3067](#3067) * **cloud-security:** validate run-history limit and reject inactive connections ([c82f9fc](c82f9fc)) * **people:** respect "Send portal invite email" opt-out when adding users ([18144fd](18144fd))
|
🎉 This PR is included in version 3.74.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Problem
A task's evidence check (e.g. AWS S3 — default encryption enabled) only ran against the customer's first connected account. The run-check endpoint ran the single referenced
connectionId, and the task card displayed only the latest single run. Customers with multiple AWS accounts (e.g. Dustin) saw results for just one account.Fix
Manual Run → all accounts.
runCheckForTasknow resolves the provider from the referenced connection, then runs the check against every active account of that provider (extracted into a resilient per-connection helperrunCheckForConnection). Each account keeps its ownIntegrationCheckRun— required because reconciliation diffsfindingKeys perconnectionId. Task status is aggregated across all accounts (any finding → failed; else any pass → done), removing the previous last-writer race. A bad account is recorded as a failed run and the batch continues.Scheduler → already runs every account (
run-integration-checks-schedule.tsloops all active connections, one run per account/task). No run-level change needed — the same display fix below surfaces all accounts for scheduled runs, identical to manual.Display → shows every account.
GET /runsnow returns viafindLatestPerConnectionAndCheckByTask, which guarantees the latest run of every(connection, check)group (a flat row limit could bury an account behind a busier one's re-runs) plus a bounded history tail, and addsconnectionId+ aconnectionLabel. The task card groups runs per account, labels each, and aggregates the header. Single-account layout is unchanged.All AWS services for free — the change is account-level, so
s3, cloudtrail, ec2, iam, kms, rdsall benefit; findings are already account-labelled via #3065.Notes
CheckRunItem/GroupedCheckRunsintocheck-run-history.tsx(source was 1610 lines) + pure grouping helpers. DS migration of the moved legacy imports is intentionally out of scope (verbatim move; the parent tree still uses@trycompai/ui/lucide-react, and DSBadge/ButtonomitclassNameso a naive swap would break the build — belongs in a dedicated PR).Tests
Verification (post-deploy, impersonated, 3 AWS accounts)
🤖 Generated with Claude Code
Summary by cubic
Run task evidence checks against all connected accounts for the provider and show per‑account results in the task UI. Hardens the runs API with org scoping, safe history limits, and rejection of inactive manual runs.
Bug Fixes
/runsguarantees the latest run per (connection, check) with a bounded history window; clamps?limit=to 1–50 (default 5); tenant‑scopes the request by verifying the task belongs to the caller’s org (404 otherwise); and returnsconnectionIdplus a human‑readable connection label.UI Improvements
Written for commit 612d624. Summary will update on new commits.