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

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV: GHSA-rwvc-j5jr-mgvh in npm package 'ai' v5.0.0 (fix: 5.0.52). Code: external result fields are stored unsanitized (XSS risk); missing input validation, auth checks, and raw errors logged/saved.

---

📦 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 2 file(s) with issues

🟡 apps/app/src/jobs/tasks/integration/integration-results.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Missing validation of integration.user_settings before processing	MEDIUM
2	External result fields (title/description/resultDetails) stored without sanitization	MEDIUM
3	Potential XSS when storing or later displaying unescaped result content	MEDIUM
4	Sensitive error messages logged and saved to DB (may expose secrets)	MEDIUM
5	Inconsistent integration ID used in error record (integration.integration_id vs id)	MEDIUM
6	No authorization checks to ensure integration ownership before DB writes	MEDIUM
7	Race condition between findFirst and create/update may lead to duplicates	MEDIUM

Recommendations:

1. Validate and strictly type integration.user_settings with a Zod (or equivalent) schema before calling integrationHandler.processCredentials. Reject or sanitize unexpected fields.
2. Validate and sanitize all fields returned by integrationHandler.fetch (title, description, remediation, resultDetails, etc.). Enforce types, max lengths, allowed characters, and drop or escape HTML to prevent injection/XSS.
3. Treat stored result content as untrusted. Either sanitize before storage or ensure safe escaping/sanitization at render time in any UI that displays these fields. Use a whitelist HTML sanitizer if HTML is allowed.
4. Avoid logging raw error messages that may contain secrets. Redact sensitive tokens/credentials from error messages before logging. When recording error records to the DB, store a sanitized summary and keep full error details in a secured audit store with restricted access.
5. Use integration.id consistently for DB relations. In the error handling path, integration.integration_id (likely an external type ID) is incorrectly used for integrationId — replace with integration.id or otherwise ensure the correct DB key is used.
6. Perform authorization/ownership checks before updating or creating DB records. Confirm existingIntegration.organizationId matches payload.organization.id and that the caller has rights to modify this integration.
7. Prevent races and duplicates by using DB-side unique constraints and atomic operations (upsert/transaction). Use a unique index on (integrationId, title) if title is intended unique, and prefer upsert or transactionally check-and-create to avoid duplicates.

🔴 apps/app/src/jobs/tasks/integration/run-integration-tests.ts (HIGH Risk)

#	Issue	Risk Level
1	No authorization check for organizationId — any caller can trigger tests	HIGH
2	No input validation on organizationId before DB query	HIGH
3	Possible sensitive data exposure: settings and userSettings sent to batch	HIGH
4	Returns raw error messages and integration details in responses	HIGH
5	Unsanitized logging of organizationId and error messages (log injection/leak)	HIGH

Recommendations:

1. Enforce authorization: verify the caller is permitted to trigger tests for the given organizationId (RBAC/ACL, token-scoped checks) before performing the DB query or launching the batch.
2. Validate and sanitize organizationId: enforce type, format/length, allowed characters (e.g., UUID regex) and reject malformed values before using them in queries or logs.
3. Redact or remove secrets from integration.settings and integration.userSettings before sending them to sendIntegrationResults; use a sanitizer that strips credential fields (API keys, secrets, tokens) or send only non-sensitive metadata.
4. Avoid returning internal errors and full integration details to callers. Return opaque status codes or minimal error identifiers and log full errors to a secure audit/log store with restricted access.
5. Sanitize and/or redact any user-controlled fields written to logs (organizationId, error messages). Encode or remove control characters and sensitive fields to prevent log injection and information leakage.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade the npm package 'ai' to >=5.0.52 to remediate GHSA-rwvc-j5jr-mgvh.
2. Validate and sanitize all fields returned by integrationHandler.fetch (title, description, remediation, resultDetails) before persisting or logging — enforce a strict schema (e.g., Zod), types/lengths, and strip/escape HTML to prevent injection/XSS.
3. Before any DB write: enforce authorization/ownership checks for the integration, redact sensitive data from error messages/logs, use integration.id consistently for relations, and use DB-side unique constraints or atomic upsert to prevent race-induced duplicates.

---

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

[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 11, 2025 6:46pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
portal (staging)	Skipped			Nov 11, 2025 6:46pm

[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.}

[claudfuen]

🎉 This PR is included in version 1.57.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀