[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 29, 2025 5:44pm
portal (staging)	Ready	Preview	Comment	Oct 29, 2025 5:44pm

[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: MEDIUM

No known OSV CVEs. Code-level issues: unsanitized organizationId used in DB access; z.any() allows unvalidated user_settings; raw result fields are stored (stored XSS / secret leakage risk).

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 3 file(s) with issues

🟡 apps/app/package.json (MEDIUM Risk)

#	Issue	Risk Level
1	react-markdown + rehype-raw: XSS when rendering untrusted markdown	MEDIUM
2	xml2js: XXE or DoS if parsing untrusted XML by default	MEDIUM
3	Using npx in scripts to fetch packages can enable remote code execution	MEDIUM
4	Large/unvetted dependency list increases supply-chain compromise risk	MEDIUM

Recommendations:

1. react-markdown + rehype-raw: Do not enable rehype-raw on untrusted markdown. Either strip/disable raw HTML or run the rendered HTML through a proven sanitizer (e.g., DOMPurify / rehype-sanitize) with an allowlist of safe tags/attributes. Prefer rendering markdown without raw HTML if user input is untrusted.
2. xml2js: Treat all XML input as untrusted. Disable entity expansion / external entity resolution, or switch to a parser that disables XXE by default. Enforce strict input size and parsing timeouts and validate input schema before parsing. Consider using a safe XML library (or fast-xml-parser configured to disallow entities) and reject overly large payloads.
3. npx in scripts: Avoid runtime remote package fetches with npx for production or CI scripts. Pin tools in devDependencies and invoke via package manager (pnpm/yarn/npm exec) or preinstall in CI images. If npx must be used, pin exact versions and review package contents before use; prefer using a signed/built binary or locked tool.
4. Supply-chain risk (large deps): Maintain an SBOM, pin dependency versions (lockfile), enable automated dependency vulnerability scanning (Dependabot, Renovate, Snyk, GitHub Advanced Security), review transitive dependencies, and minimize dependency surface by removing unused packages. Use reproducible builds and least-privilege principles for CI secrets.

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

#	Issue	Risk Level
1	Missing validation: integration.user_settings uses z.any()	MEDIUM
2	Unvalidated integration results saved to DB (title/description/resultDetails)	MEDIUM
3	Stored XSS risk from saving raw result fields	MEDIUM
4	Sensitive data leakage: secrets or error messages may be logged or stored	MEDIUM
5	Using title as unique identifier can cause overwrites/tampering	MEDIUM
6	Type cast of decrypt may hide runtime type/runtime issues	MEDIUM
7	Error create uses integration.integration_id as FK, may mismatch	MEDIUM

Recommendations:

1. Tighten the task schema: replace z.any() for settings and user_settings with a strict Zod schema describing expected credential and config shape. Validate before calling processCredentials.
2. Validate and type-check all integration results returned from integrationHandler.fetch() (e.g., with a Zod schema). Reject or normalize unexpected/missing fields before DB persistence.
3. Sanitize or escape free-text fields (title, description, resultDetails) before storing or at least before rendering. Prefer storing a sanitized/normalized form + original in a secure, audited place if needed.
4. Avoid persisting secrets or plaintext credentials. Ensure processCredentials returns a credentials object that excludes secrets or redacts them. Do not log full error stacks or raw decrypted values; redact secrets from logs and resultDetails.
5. Use a stable unique key for deduplication (externalId, findingId) instead of title. If title must be used, combine with other stable attributes (externalId, fingerprint) to avoid collisions and tampering.
6. Do not perform unsafe casts (decrypt as DecryptFunction). Ensure the decrypt function adheres to the expected runtime contract or wrap it in an adapter that validates inputs/outputs. Add runtime checks and tests for the decrypt API.
7. Fix FK consistency when recording errors: the code uses integration.integration_id for the integrationId FK in the error path, but elsewhere uses integration.id (database id). Use the correct DB primary key (existingIntegration.id / integration.id) or map external IDs explicitly and validate existence before creating records.
8. Limit error detail stored in resultDetails: store an error code and minimal message, preserve stack traces only in secure internal logs, not in DB records accessible to users.

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

#	Issue	Risk Level
1	Unsanitized organizationId used directly in DB query — potential injection risk	MEDIUM
2	No validation of payload or types before DB access or external calls	MEDIUM
3	Sensitive settings/userSettings included in batch payload — data leak risk	MEDIUM
4	Logging and rethrowing raw errors may expose internal or secret data	MEDIUM

Recommendations:

1. Validate and canonicalize organizationId before use. Enforce a strict format (e.g., UUID) and reject or normalize invalid values before passing to the ORM.
2. Add schema validation for the task payload (e.g., zod/Joi/TypeBox). Validate shapes and types of payload fields at the task entry so downstream code can rely on typed values.
3. Minimize selected columns from the DB. Only select fields required for the integration test runner; avoid selecting raw settings/userSettings when not strictly necessary.
4. Redact or omit secrets from settings/userSettings before including them in the batch payload. Create a sanitizer that strips credentials, tokens, private keys, or replaces them with masked placeholders.
5. Use a secure contract/interface for sendIntegrationResults so it accepts a sanitized DTO rather than raw DB objects. Consider encrypting any sensitive fields before sending to other systems.
6. Avoid logging raw errors or untrusted data. Sanitize error messages (strip out stack traces, secrets) before logging, or log structured error codes with limited metadata.
7. Confirm the ORM uses parameterized queries (most modern ORMs do). If raw SQL is used anywhere with user-provided input, ensure parameterization or prepared statements.
8. Implement access controls and least privilege for any systems consuming the batch (ensure only authorized services can view sensitive payloads).
9. Introduce monitoring/alerting for unexpected payload sizes or unusual numbers of integrations being exported to detect exfiltration patterns.

---

💡 Recommendations

View 3 recommendation(s)

1. Validate and canonicalize organizationId at task entry (e.g., assert UUID format) and ensure DB access uses parameterized/ORM-bound queries instead of interpolating unchecked input.
2. Replace z.any() for integration.user_settings with a strict Zod schema describing expected fields; validate integrationHandler.fetch() outputs with Zod before persisting to the DB.
3. Sanitize or escape title/description/resultDetails before storing (strip HTML or use a server-side sanitizer), and redact/remove any secrets or full error stacks from persisted records; store only minimal error codes/messages.

---

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

[claudfuen]

🎉 This PR is included in version 1.56.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀