[comp] Production Deploy

[github-actions]

This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app (staging)	Ready	Preview	Comment	Oct 30, 2025 3:15pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal (staging)	Skipped			Oct 30, 2025 3:15pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

No OSV CVEs detected. Scan shows client-side exposure of a scan access token, UI-only authorization for policy actions, and user-controlled searchParams passed into policy queries (injection risk).

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 5 file(s) with issues

🔴 apps/app/src/app/(app)/[orgId]/cloud-tests/components/ResultsView.tsx (HIGH Risk)

#	Issue	Risk Level
1	Exposes access token to client-side (scanAccessToken)	HIGH
2	Displays raw provider error messages, may leak secrets	HIGH

Recommendations:

1. Do NOT pass scanAccessToken to client components. Move all uses of the access token to server-side endpoints (API routes) and call those endpoints from the client. For example, create a server-side handler that calls useRealtimeRun or Trigger.dev with the token and returns only safe, necessary status data to the client.
2. If realtime/status needs to be streamed to the client, implement a server-side proxy or a short-lived ephemeral token exchange so the permanent token never reaches the browser.
3. Replace direct rendering of run?.error?.message with a sanitized/generic user-facing message (e.g., "Scan failed, please try again") and log the full provider error only server-side. Where logging is required, redact secrets (tokens, keys, credentials) before persisting or transmitting logs.
4. Implement explicit redaction/sanitization for provider error payloads. For example, remove/replace fields that match patterns for tokens, emails, URLs with query secrets, or JSON fields named access_token/secret/credentials before returning to the client.
5. Use short-lived tokens and least-privilege scopes for any tokens used by background scanning services; rotate tokens and revoke on compromise.
6. Audit other components for any other props that may carry secrets to client-side code (props passed into 'use client' components).

🟡 apps/app/src/app/(app)/[orgId]/policies/[policyId]/components/PolicyOverview.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Authorization enforced only in UI, can be bypassed	MEDIUM
2	Accept/deny actions include client-provided approverId	MEDIUM
3	Comments sent to actions without validation/sanitization	MEDIUM

Recommendations:

1. Enforce authorization on the server: never rely on UI checks (canCurrentUserApprove). Server actions (acceptRequestedPolicyChangesAction, denyRequestedPolicyChangesAction, regeneratePolicyAction) must verify the current authenticated user has permission to perform the action and is the approver for that policy.
2. Do not trust client-supplied approverId or other authority-related fields. Server should derive the approver/actor from the authenticated session (server-side identity) rather than using the approverId supplied in the request payload. If approverId must be accepted, verify it exactly matches the server-side session identity and the policy state.
3. Validate and sanitize free-text inputs (comments) server-side before persisting or rendering. Apply length limits, strip/escape HTML, and/or normalize input. Also ensure output encoding when comments are rendered to prevent stored XSS. Use well-tested libraries for sanitization/encoding rather than client-only fixes.
4. Server-side validate policy state transitions (e.g., ensure policy is actually pending approval and approver matches) before applying accept/deny/regenerate operations to avoid state manipulation or race conditions.
5. Log all approve/deny/regenerate actions (who, when, source IP, request body) and implement rate-limiting and/or anti-automation protections on these sensitive endpoints.
6. Ensure actions are idempotent and have appropriate checks (e.g., disallow approving an already-approved or archived policy). Return clear error codes for unauthorized or invalid state requests.
7. Add strong output encoding and CSP to mitigate any residual XSS risk if comments or other user-controlled strings are displayed in the UI.

🟡 apps/app/src/app/(app)/[orgId]/policies/all/actions/regenerate-full-policies.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Insufficient authorization: only checks session.activeOrganizationId	MEDIUM
2	Missing validation of organizationId before triggering task	MEDIUM
3	No rate limiting or abuse protection on task triggering	MEDIUM
4	No error handling around tasks.trigger (exceptions leak)	MEDIUM

Recommendations:

1. Enforce explicit permission/role checks: verify the session user has the required role/permission for the target organization (e.g., check membership and roles in DB) before triggering the task.
2. Validate and verify organizationId: validate format (e.g., with zod) and confirm the organization exists and the user is a member of it server-side, not just that session.activeOrganizationId is present.
3. Add rate limiting/anti-abuse controls: implement per-user and/or per-organization rate limits for triggering background tasks to prevent abuse or DoS.
4. Wrap tasks.trigger in try/catch: catch errors from tasks.trigger, log sanitized details for diagnostics/audit, and return a safe error message to the caller instead of allowing exceptions to propagate.
5. Add audit logging: log authorization decisions and task trigger events (who triggered, orgId, timestamp) to support incident response and monitoring.

🟡 apps/app/src/app/(app)/[orgId]/policies/all/page.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	User-controlled searchParams passed into getPolicies (potential SQL injection)	MEDIUM
2	Filters derived from user input may be insufficiently sanitized	MEDIUM
3	No error handling for searchParamsCache.parse exceptions	MEDIUM
4	If getPolicies uses raw queries, user input could cause injection	MEDIUM

Recommendations:

1. Validate and sanitize searchParams with a strict schema
2. Use parameterized queries or prepared statements in getPolicies
3. Whitelist filter fields and normalize filter values
4. Wrap searchParamsCache.parse in try/catch and handle invalid input
5. Ensure server-side output is escaped or sanitized before rendering

🟡 apps/app/src/jobs/tasks/onboarding/generate-full-policies.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing validation/authorization for payload.organizationId used in DB queries and triggers	MEDIUM
2	No explicit permission check before triggering policy updates for an organization	MEDIUM
3	Error logs may expose internal error details	MEDIUM

Recommendations:

1. Enforce runtime validation for the task payload. Convert to a schema-backed task (like the existing update-policy schemaTask) or validate payload.organizationId with zod/ajv before use to avoid malformed/attacker-supplied IDs.
2. Add an authorization check before performing organization-scoped actions. Verify the caller or task origin is allowed to operate on payload.organizationId (e.g., check a service identity, task metadata, or a signed/verified token). If tasks are enqueued from external sources, authenticate/whitelist sources.
3. Move any organization-level permission checks into the helper that performs sensitive work (e.g., getOrganizationContext or triggerPolicyUpdates) or perform them in this task before DB queries. Ensure a consistent, centralized authorization model.
4. Avoid logging raw error messages or sensitive internal details. Redact or normalize error output (e.g., log an error id and minimal context, store full details in a secure error store accessible to operators).
5. Continue to rely on ORM query parameterization (as currently used) and avoid raw SQL string concatenation. If any raw queries exist elsewhere, ensure they use parameterized inputs.
6. If tasks can be triggered externally, restrict who can enqueue them: whitelist callers, sign task payloads, or only allow internal systems to create these tasks. Consider rate limiting high-volume task queues.
7. As a defensive enhancement, validate the frameworks array returned/used in triggerPolicyUpdates (ensure each framework object has expected shape) and consider schema-validation for those inputs too.

---

💡 Recommendations

View 3 recommendation(s)

1. Remove scanAccessToken from client-side props and stop rendering raw provider error messages. Move any token-using calls to server-side endpoints (API routes) that perform the external calls and return only sanitized status/error codes to the client.
2. Enforce authorization on the server for approve/deny/regenerate policy actions: derive the actor from the authenticated session server-side (do not trust client-supplied approverId), validate the policy state before transitioning, and reject unauthorized requests.
3. Validate and sanitize all searchParams before calling getPolicies: use a strict schema (e.g., zod) and parse inside try/catch, whitelist acceptable filter fields/values, and ensure database queries use parameterized inputs to prevent injection.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Oct 30, 2025

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ Alex-Alaniz
❌ github-actions[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[claudfuen]

🎉 This PR is included in version 1.56.5 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀