[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	Nov 13, 2025 9:26pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal (staging)	Skipped			Nov 13, 2025 9:26pm

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

One OSV CVE in ai@5.0.0 (GHSA-rwvc-j5jr-mgvh) plus multiple hardcoded client-side tokens and unsanitized org/task ID usage in DB-related code.

---

📦 Dependency Vulnerabilities

🟢 NPM Packages (LOW)

Risk Score: 2/10 | Summary: 1 low CVE found

Package	Version	CVE	Severity	CVSS	Summary	Fixed In
ai	5.0.0	GHSA-rwvc-j5jr-mgvh	LOW	N/A	Vercel’s AI SDK's filetype whitelists can be bypassed when uploading files	5.0.52

---

🛡️ Code Security Analysis

View 14 file(s) with issues

🟡 apps/api/src/tasks/tasks.service.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Direct use of organizationId/taskId in DB queries	MEDIUM
2	No input validation/sanitization for organizationId/taskId	MEDIUM
3	Insufficient authorization: relies on caller-supplied organizationId only	MEDIUM
4	Excessive data exposure: getTask returns raw task with relations	MEDIUM
5	Logging full error objects to console (may leak sensitive info)	MEDIUM

Recommendations:

1. Validate and sanitize organizationId and taskId at the boundary (controller layer) using DTOs and class-validator (e.g., @IsUUID(), @IsString(), length/format checks). Reject malformed IDs before they reach the DB layer.
2. Enforce authorization using the authenticated user's context: verify the caller is a member of the organization and has sufficient permissions for the requested operation. Do not rely solely on caller-supplied organizationId values.
3. Return mapped DTOs from getTask (similar to getTasks) and explicitly select only the columns required. Avoid returning raw ORM models or unfiltered relations; use select/include carefully to limit exposed fields (e.g., exclude internal flags, tokens, audit fields).
4. Avoid logging full error objects to console in production. Log minimal contextual identifiers (organizationId, taskId, request id) and send full error details to a secure logging system with access controls. Redact or omit sensitive fields from logs.
5. Ensure queries use ORM parameterization (Prisma/DB client does by default) and do not interpolate user input into raw SQL. If raw queries are necessary, use parameterized bindings and thoroughly validate inputs first.
6. Add unit/integration tests to verify access control (IDOR), and consider adding rate limiting and monitoring for anomalous access patterns.

🟡 apps/app/src/app/(app)/[orgId]/cloud-tests/components/EmptyState.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Hardcoded token in logoUrl query string exposed client-side	MEDIUM
2	Example AWS access key in placeholder may be mistaken as real secret	MEDIUM
3	Sensitive credentials stored in React component state	MEDIUM
4	No input sanitization before sending credentials to backend actions	MEDIUM
5	console.error may leak sensitive response data to browser logs	MEDIUM

Recommendations:

1. Remove any tokens/credentials from client-side source. If the image provider requires a token, serve the image through a server-side proxy or use time-limited, server-generated URLs so secrets are never baked into the client bundle.
2. Avoid including anything that resembles a real credential in UI placeholders. Use clearly-marked examples (e.g., "example: ") or documentation only. If a real key was accidentally committed, rotate it immediately.
3. Minimize keeping secrets in long-lived client-side state. Use controlled input fields and clear them immediately after use. Consider sending credentials directly to a secure server endpoint (over TLS) and avoid persisting them in component state or local storage.
4. Validate and sanitize all credential-related inputs on the server side before use. While client-side validation improves UX, do not rely on it for security. Implement strict server-side checks and parameterization where applicable.
5. Avoid logging raw errors or responses to the browser console, as they can include sensitive information. Sanitize error objects before logging, and prefer server-side logging with redaction for any sensitive fields. Remove console.error statements that may expose secrets in production code.

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

#	Issue	Risk Level
1	Trigger access token exposed to client (triggerToken prop)	HIGH
2	Server responses (findings/providers) used without validation	HIGH
3	Displaying server-provided messages via toast without sanitization	HIGH
4	Submitting orgId directly to trigger without validation	HIGH

Recommendations:

1. Do not send long-lived or secret trigger tokens to the client. Keep secrets on the server and perform actions that require secrets (e.g., starting scans) via a server-side endpoint that validates the caller and forwards a request to the trigger system.
2. If you must initiate runs from the client, use a short-lived, scoped token issued by the server or a server-side proxy endpoint that performs the submit call using server-side credentials.
3. Validate and sanitize API responses on the server before returning them to the client. Treat any server-returned strings as untrusted and avoid directly injecting them into the DOM as HTML.
4. Escape or sanitize any server-provided messages before passing them to UI toast functions. Prefer rendering plain text (React already escapes JSX) and ensure the toast library does not interpret HTML. If the toast library supports unsafe HTML, disable that behavior.
5. Enforce strict server-side authorization for API endpoints (/api/cloud-tests/*) and for any task trigger endpoints. Validate that the authenticated user is allowed to perform actions for the provided orgId.
6. Validate and canonicalize orgId on the server; do not rely on client-side validation. Ensure the backend checks that the calling user has rights to the organization before performing operations.
7. Log and monitor unexpected or malformed values returned from providers and run results; fail closed (show generic error messages) rather than echoing provider-supplied content to users.
8. If displaying provider-run errors is useful to users, whitelist/format expected error fields (e.g., code, short_message) and avoid reflecting raw, untrusted strings into UI components that may support HTML.

🟡 apps/app/src/app/(app)/[orgId]/components/OnboardingTracker.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Missing validation: run.metadata fields used directly (vendorsInfo risksInfo policiesInfo)	MEDIUM
2	Prototype pollution risk via untrusted metadata keys (e.g. proto)	MEDIUM
3	Potential exposure of triggerJobId in client bundle	MEDIUM
4	No limits on metadata sizes allowing DoS via large arrays	MEDIUM

Recommendations:

1. Validate and coerce run.metadata before use. Treat run.metadata as untrusted: verify types (arrays/objects/numbers/strings) and required fields. Use schema validation (e.g., zod, yup, io-ts) or explicit runtime checks before reading vendorsInfo/risksInfo/policiesInfo and their id/name fields.
2. Whitelist and validate IDs used as object keys. Only accept safe ID formats (e.g., /^[A-Za-z0-9_-]+$/) for vendor.id, risk.id, policy.id. Reject or sanitize any IDs that do not match the whitelist.
3. Avoid using plain objects with default prototypes for dynamic keys. Use Object.create(null) or a Map for vendorsStatus/risksStatus/policiesStatus to prevent prototype pollution side effects. Example: const vendorsStatus = Object.create(null) or const vendorsStatus = new Map(); then vendorsStatus.set(id, status).
4. When you must use dynamic keys on plain objects, explicitly check for dangerous keys like 'proto', 'constructor', 'prototype' and reject them before assignment.
5. Enforce size and length limits on arrays and strings from metadata. For example, cap vendorsInfo/risksInfo/policiesInfo to a reasonable max (e.g., 100 items) and truncate or paginate on the server. Limit individual string lengths (e.g., name <= 256 chars).
6. Avoid exposing long-lived sensitive identifiers client-side. If triggerJobId is sensitive, fetch run state server-side and stream/signal minimal data to the client, or use short-lived tokens/opaque IDs. If triggerJobId must be client-visible, document its sensitivity and ensure it cannot be used to escalate privileges.
7. Defend against large payload DoS in the UI by slicing large arrays before mapping (and showing a count/see-more link), and by using virtualization (windowed rendering) for large lists.
8. Sanitize string content used in any context that may bypass React escaping (e.g., dangerouslySetInnerHTML). Although JSX escapes by default, ensure no content is inserted as raw HTML.
9. Log and monitor unexpected metadata shapes. If invalid metadata is seen repeatedly from a particular source, treat it as an incident and consider throttling/blocking the source.

🟡 apps/app/src/app/(app)/[orgId]/integrations/actions/get-relevant-tasks.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated user inputs placed directly into LLM prompt	MEDIUM
2	Sensitive integration/task data sent to external API (data leak risk)	MEDIUM
3	Errors may log sensitive input or model response data	MEDIUM
4	No size limits or sanitization on taskTemplates array entries	MEDIUM

Recommendations:

1. Validate and sanitize all inputs server-side: enforce types, allowed characters/lengths for integrationName and integrationDescription, and validate taskTemplates entries (id, name, description).
2. Enforce limits: cap number of taskTemplates accepted and total characters/token budget; reject or paginate/trim overly large inputs before building the prompt.
3. Minimize data sent to the external API: remove or redact any sensitive fields (secrets, PII, internal IDs) before including them in the prompt; consider hashing IDs if the model only needs stable references.
4. Apply prompt-injection mitigations: use strict templating (never concatenate raw user strings into instruction sections), whitelist acceptable task fields or map inputs into safe enums, and escape or normalize input text.
5. Avoid logging raw inputs and responses: never write full prompt text or model outputs to logs. Implement redaction for any logged text (mask PII/secrets) and avoid logging error objects that may contain request/response payloads.
6. Consider using an enterprise or private LLM endpoint with Data Processing Agreements or an on-premise model for sensitive data to reduce leak risk.
7. Add structured input validation (e.g., zod schemas) for the function parameters and fail fast on invalid or oversized inputs.
8. Instrument monitoring for unexpected model outputs and create an approval/warning flow if model-suggested prompts contain flagged sensitive content.

🔴 apps/app/src/app/(app)/[orgId]/integrations/components/IntegrationsGrid.tsx (HIGH Risk)

#	Issue	Risk Level
1	Hardcoded API token (LOGO_TOKEN) committed in client code	HIGH
2	Sensitive prompts placed in URL query string (leaks via referer/history)	HIGH
3	Console logs output task IDs and template IDs (information leakage)	HIGH
4	orgId from useParams used without validation when calling API	HIGH

Recommendations:

1. Remove token from client; store secrets on server and use env vars
2. Avoid placing sensitive prompt in URL; send via POST or server-side session/state
3. Sanitize and validate orgId before using it in API calls
4. Remove or disable console logging of IDs in production builds
5. Rotate any exposed tokens immediately and audit their usage

🟡 apps/app/src/app/(app)/[orgId]/integrations/components/SearchInput.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	No input validation: raw user input forwarded via onChange	MEDIUM
2	Potential DOM XSS if value is rendered elsewhere unsanitized	MEDIUM

Recommendations:

1. Validate and sanitize input as early as possible (preferably in the consuming component or on the server). Enforce length and character constraints (e.g., maxLength, allowed character whitelist) where appropriate.
2. Treat all user input as untrusted. Never insert user-provided strings into the DOM as HTML. Avoid dangerouslySetInnerHTML; if you must use it, sanitize with a robust library (e.g., DOMPurify) and whitelist allowed markup.
3. Escape user content on output. When rendering text, use normal React rendering (which escapes by default) or explicitly set textContent instead of innerHTML.
4. Add input attributes to help mitigate accidental misuse: maxLength, input pattern, and type where applicable to enforce basic constraints on the client.
5. Enforce server-side validation and sanitization for any input that reaches the backend or is persisted/served to other users.
6. Add unit/integration tests that ensure untrusted input cannot lead to script execution (e.g., attempts to inject <script> or event handlers are escaped/sanitized).

🟡 apps/app/src/app/(app)/[orgId]/layout.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Unsanitized orgId used in DB queries (SQL injection risk)	MEDIUM
2	Trusting publicAccessToken cookie directly (client tampering)	MEDIUM
3	No validation of params.orgId format before DB use	MEDIUM
4	Detailed redirects reveal org existence (info disclosure)	MEDIUM

Recommendations:

1. Validate orgId format as early as possible (e.g., ensure it matches expected pattern such as a UUID: /^[0-9a-fA-F-]{36}$/) before using it in database queries or other logic.
2. Rely on parameterized queries/ORM prepared statements for DB access. If using Prisma (likely here), note Prisma parameterizes queries by default — still perform input validation to guard logic-level issues.
3. Do not trust client-provided cookies for sensitive tokens without server-side verification. Use signed/HttpOnly/secure cookies or store tokens server-side and verify any client-supplied token before use.
4. Avoid returning different responses that reveal resource existence. Use generic error pages/statuses (e.g., 404 for not found without indicating why, or a unified unauthorized page) to reduce information disclosure.
5. Add explicit server-side input validation and stricter type checks for route params (centralize validation middleware/utilities).
6. Log and monitor suspicious inputs and failed access attempts to detect abuse (rate-limit or block repeated attempts).

🟡 apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/chat/EmptyState.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Hardcoded image service token in URLs	MEDIUM
2	Vendor website/name used to build image URL without whitelist	MEDIUM
3	No validation/encoding of vendor input; may enable SSRF via image proxy	MEDIUM

Recommendations:

1. Remove the hardcoded token from the source. Treat this as a secret/config value and load it from environment/configuration on the server. Do not embed secrets in client-side code. If the token must be used client-side and is public-only, document and rotate it as needed; otherwise move image fetching behind a server-side proxy.
2. Whitelist allowed vendor domains and validate vendorWebsite/vendorName against that whitelist before composing the image URL. Only allow domains you trust (e.g., well-known CDNs or vendor hostnames). Reject or normalize anything outside the whitelist.
3. Use a robust URL parser (e.g., new URL()) on the server to normalize and validate vendorWebsite inputs, and URL-encode any path segments before inserting into the image service path. Trim and limit length of inputs.
4. Avoid having the client construct proxied fetch targets that an upstream image proxy will fetch on your behalf. Instead, either (a) have your server fetch/validate logos and serve them (server-side proxy with strict validation), or (b) request signed short-lived URLs from the image service on the server and send only the signed URL to the client.
5. Sanitize and validate the suggestions input source (where suggestions are generated/ingested). Treat suggestions as untrusted input and apply server-side validation before returning them to clients.
6. Add defense-in-depth: enforce Content Security Policy for images (img-src), rate-limit and logging on any server-side proxy, and consider rejecting vendor inputs containing unexpected characters (e.g., colon, '@', slashes other than expected) before using them.

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

#	Issue	Risk Level
1	No RBAC: any authenticated user can access org tasks, members, controls	MEDIUM
2	Members include user metadata, risking exposure of private user data	MEDIUM
3	Weak validation: status query uses JavaScript 'in' against TaskStatus enum	MEDIUM
4	Route orgId used in UI (breadcrumb) is unchecked; can mismatch session org	MEDIUM

Recommendations:

1. Enforce RBAC: check the caller's role/permissions in session before returning tasks/members/controls (e.g., verify that the session user has an admin/manager role for the activeOrganizationId). Return 403 or an empty result for unauthorized roles.
2. Limit member response fields: do not include the full user object unless required. Use explicit select/projection to return only necessary fields (e.g., id, name, email if permitted). Consider masking or omitting sensitive user attributes.
3. Validate status param robustly: explicitly compare the incoming status string against a whitelist of TaskStatus values (e.g., Object.values(TaskStatus).includes(statusParam)) and reject/ignore unknown values instead of relying on the JS 'in' operator.
4. Ensure route orgId consistency: either use the session.activeOrganizationId for all data and breadcrumb links, or validate that params.orgId === session.activeOrganizationId and block or redirect if they differ to avoid UI spoofing/confusion.
5. Add access logging and alerting for endpoints returning member/control lists or other sensitive data so anomalous access patterns can be detected.

🟡 apps/app/src/app/(app)/setup/hooks/useOnboardingForm.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Unvalidated user input sent to server action (organizationName, website, frameworkIds)	MEDIUM
2	Client-side zod validation only covers current step, not full payload	MEDIUM
3	Analytics/tracking send PII (organizationName, frameworks) to third parties	MEDIUM
4	buildUrlWithParams propagates URL search params into redirects without sanitization	MEDIUM
5	handlePrefillAll trusts /api/frameworks JSON without schema validation	MEDIUM
6	initialData merged into state without type/sanitization (Record<string, any>)	MEDIUM

Recommendations:

1. Enforce server-side validation and sanitization in the createOrganizationMinimal action (e.g., use zod/ajv on the server). Never assume client-side validation is sufficient.
2. Validate the full payload server-side (not just the current step). Ensure required fields, types, allowed lengths/characters, and whitelist values where applicable.
3. Avoid sending potentially sensitive or identifying fields to third-party analytics. If you must send metrics, anonymize or hash identifiers and avoid sending raw organization names or other PII.
4. When forwarding URL search params between pages, validate and whitelist expected param names/values. Do not forward or reflect arbitrary user-controlled HTML/JS into pages without escaping.
5. Validate responses from /api/frameworks with a schema (zod/ajv) before using; treat network data as untrusted. Check that framework objects contain the expected shape (id: string, visible: boolean, etc.) before using them.
6. Tighten typing and origin checks for initialData (avoid Record<string, any>). Validate/normalize any initial data coming from KV or other storage before merging into state and before sending to server actions.
7. Instrument logging/monitoring for malformed inputs or unexpected payload shapes so you can detect attempts to exploit unvalidated fields.

🟡 apps/app/src/jobs/tasks/onboarding/onboard-organization-helpers.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Stored XSS via LLM-generated comment content	MEDIUM
2	No validation of AI-extracted vendor data before DB insert	MEDIUM
3	Untrusted context used in LLM prompts (prompt injection risk)	MEDIUM
4	Logging external response data may leak sensitive secrets	MEDIUM
5	Using untyped vendor.id/entityId may allow incorrect associations	MEDIUM
6	Unvalidated organizationId used in revalidation path/URL	MEDIUM

Recommendations:

1. Sanitize and/or escape LLM output before storing or rendering. Treat model outputs as untrusted. Prefer storing raw output plus a sanitized/escaped version or sanitize at render time (HTML-escape fields or use a robust sanitizer like DOMPurify on the client).
2. Validate and strictly whitelist all AI-extracted fields prior to DB writes: enforce types/enums, validate URLs (e.g., using a URL parser), truncate/normalize strings, and enforce maximum lengths. Reject or flag outputs that don't match expected enums or patterns.
3. Treat context passed into LLM prompts as untrusted. Implement prompt-level content filters and pre-sanitize user-provided context (strip prompt-injection patterns, remove any LLM-style instruction markers, or normalize to a safe subset). Consider running a safety/structure validator on the LLM response (e.g., schema validation and semantic checks) before using it.
4. Avoid logging full external responses or raw error objects. Redact or summarize external response bodies and error stacks in logs; never log credentials, secrets, or full request/response payloads. Use structured logging with explicit allowed fields.
5. Ensure entity ids used for associations are from trusted sources and typed. Prefer using DB-returned vendor objects (with verified id fields) when creating related comments. Validate the presence and format of vendor.id before using it as entityId in comment creation.
6. Validate and authorize organizationId before using it in external requests and URLs. Ensure organizationId conforms to an expected pattern (UUID, numeric id, etc.) and perform authorization checks. When calling revalidation endpoints, build the path/server-side and avoid embedding unvalidated input directly into URLs.
7. Add provenance and validation metadata for any DB record created from AI output (e.g., record that the item was AI-generated, timestamp, model/version, and validation status). Use this for audits and to apply stricter UI handling.
8. Limit LLM model privileges: run risky generation in a sandboxed flow, do not allow automated actions with elevated rights based solely on LLM outputs without human review or automatic validation gates.

🔴 apps/app/src/jobs/tasks/onboarding/onboard-organization.ts (HIGH Risk)

#	Issue	Risk Level
1	No validation of payload.organizationId before DB queries	HIGH
2	No authorization check for task-triggered organizationId	HIGH
3	Unsanitized user input stored in metadata/DB (stored XSS risk)	HIGH
4	Revalidation secret sent to external URL without endpoint validation	HIGH
5	Potential exposure of secrets/PII in logs (error, revalidateResponse)	HIGH
6	Temporary IDs and metadata may leak vendor/org PII if shown publicly	HIGH

Recommendations:

1. Validate and canonicalize payload.organizationId at the start of the task: enforce expected format (e.g., UUID), reject or fail fast on invalid values.
2. Enforce authorization/ownership checks before performing sensitive operations. The task should verify that the actor who scheduled the task (or the service account) is allowed to modify the given organizationId, or record an immutable verified origin with the job and check it here.
3. Sanitize or escape any user-provided text before storing in metadata or DB fields that may be rendered in a UI (vendor names, organization.name, risk titles, answers from questionsAndAnswers). Use a proven sanitizer or escape on output when rendering in HTML to avoid stored XSS.
4. Avoid posting secrets to URLs derived from public/controllable environment variables without verification. Ensure NEXT_PUBLIC_BETTER_AUTH_URL is a trusted internal URL, validate that it uses HTTPS, and restrict revalidation requests to internal endpoints (or use a server-side internal-only endpoint). Do not treat NEXT_PUBLIC_* env vars as private; move secrets/URLs to server-only env vars where appropriate.
5. Redact secrets and sensitive PII from logs. Do not log full response bodies that may contain secrets. Use structured logging with a sanitizer/redaction layer and log only minimal status info (e.g., status code, revalidated: true/false).
6. Limit metadata exposure: avoid storing raw PII in metadata that could be shown to unauthenticated/less-privileged users. Replace temporary or public IDs with opaque tokens when appropriate, and ensure any metadata endpoints check permissions before returning details.
7. Where DB operations involve user input, rely on parameterized ORM usage (this code appears to use an ORM; continue to use its parameter binding) and validate inputs. Add defensive checks (length, character whitelist) before updates such as member.update or task.updateMany.
8. Consider adding audit logging for who/what triggered the onboarding task, and rate-limit or require additional verification for destructive or high-impact changes (role update, mass task assignment).

🔴 packages/docs/openapi.json (HIGH Risk)

#	Issue	Risk Level
1	X-Organization-Id header may allow IDOR/auth bypass	HIGH
2	API key scheme details missing; apikey enforcement unclear	HIGH
3	metadata accepts raw JSON string without validation	HIGH
4	logo and website fields lack URL validation	HIGH
5	No request size limits or rate limiting defined	HIGH

Recommendations:

1. Do not trust X-Organization-Id from the client. Derive organization context from server-side session state when using session auth; if header must be supported for API-key auth, strictly authorize every request server-side to ensure the API key is valid for the requested organization and that the caller has permission for the resource (principle of least privilege).
2. Ensure the apikey security scheme is enforced in implementation: validate the X-API-Key value for every request, map it to an organization and scopes/permissions, reject requests with missing/invalid keys, and log/monitor failed attempts. Document required scopes and expected behaviors in the code that validates the key.
3. Change metadata from a free-form JSON string to a structured JSON/object schema (or validate/parsestring on the server). Parse, validate and sanitize the metadata JSON server-side before storing or using it (reject or sanitize unexpected fields, enforce size/shape, and use a JSON schema validator).
4. Enforce URL validation for logo and website fields server-side: require a URI/URL format (e.g., RFC-compliant), restrict allowed schemes (https only unless there's a reason), and optionally apply a host allowlist or domain validation to prevent SSRF or injection of unexpected URLs.
5. Enforce request size limits and rate limits at multiple layers: set maximum request body sizes and field length limits in request validators, configure web server/reverse-proxy (nginx, cloud provider WAF) body size limits, and implement rate limiting per API key / per IP / per user to mitigate abuse. Add request throttling and global quotas for sensitive operations like bulk uploads.
6. Add explicit input validation for all HTTP parameters (headers, path params, query params, and bodies) using a schema validator consistent with your OpenAPI definitions. Make the OpenAPI schema stricter where possible (use format: uri for URLs, object for metadata, min/max lengths, enums, pattern for IDs).
7. Log and monitor authorization failures and anomalous use of X-Organization-Id (e.g., attempts to access other organizations), and add alerting for suspicious activity (mass failed auths, unusually large bulk requests).

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade the vulnerable dependency ai from 5.0.0 to >= 5.0.52 (update package.json and lockfile) to remediate GHSA-rwvc-j5jr-mgvh.
2. Remove hardcoded credentials found in client code (examples: apps/app/src/app/(app)/[orgId]/cloud-tests/components/EmptyState.tsx, apps/app/src/app/(app)/[orgId]/integrations/components/IntegrationsGrid.tsx — LOGO_TOKEN, apps/app/src/app/(app)/[orgId]/tasks/[taskId]/automation/[automationId]/components/chat/EmptyState.tsx, and TestsLayout triggerToken). Revoke/rotate any exposed tokens and ensure no secrets are bundled into client builds.
3. Harden ID handling: validate and sanitize organizationId and taskId at the request boundary (e.g., enforce UUID/format checks) and do not trust X-Organization-Id headers. Ensure all DB queries use parameterized ORM calls (avoid interpolating raw params into SQL) and reject malformed IDs before querying.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Nov 13, 2025

[claudfuen]

🎉 This PR is included in version 1.58.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀