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

1 Skipped Deployment

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

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV: xlsx@0.18.5 has two HIGH GHSA advisories (prototype pollution, ReDoS). ai@5.0.0 has a LOW advisory (filetype whitelist bypass, fixed in 5.0.52). Code shows unsanitized orgId used in DB queries and IDOR/cache issues.

---

📦 Dependency Vulnerabilities

🟠 NPM Packages (HIGH)

Risk Score: 8/10 | Summary: 2 high, 1 low CVEs found

Package	Version	CVE	Severity	CVSS	Summary	Fixed In
xlsx	0.18.5	GHSA-4r6h-8v6p-xvw6	HIGH	N/A	Prototype Pollution in sheetJS	No fix yet
xlsx	0.18.5	GHSA-5pgg-2g8v-p4x9	HIGH	N/A	SheetJS Regular Expression Denial of Service (ReDoS)	No fix yet
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/app/(app)/[orgId]/frameworks/lib/getPeople.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Unsanitized organizationId used directly in DB queries	MEDIUM
2	No authorization check for caller accessing organization data	MEDIUM
3	policy.signedBy checked with string.includes — can falsely match or bypass	MEDIUM
4	No validation of fields (signedBy, role, completedAt) before use	MEDIUM
5	Unbounded IN on member IDs may cause performance/DoS issues	MEDIUM

Recommendations:

1. Validate and normalize organizationId before passing to DB (e.g., ensure it matches expected UUID format or internal ID type). Even when using an ORM that parameterizes queries, validate the identifier to avoid logic errors and enforce type safety.
2. Enforce authorization at the API/handler level so callers can only request data for organizations they are permitted to access. Add explicit permission checks before calling this function or accept a validated/authorized context instead of raw org IDs.
3. Do not rely on string.includes for membership of signedBy. Store signatures as a normalized array (e.g., string[] or related table) or parse and split the stored string into exact IDs and check equality to avoid partial matches.
4. Add defensive checks and type guards before using fields: ensure policy.signedBy is defined and of expected type, member.role is a string (handle null/undefined), training completion completedAt is checked for existence and valid date, etc. Fail gracefully or skip malformed records.
5. Avoid building large unbounded IN lists. Paginate members or process in chunks; or use joins/relations in the DB query to let the database handle filtering/aggregation. Add limits or streaming to reduce memory/CPU and mitigate potential DoS from very large organizations.

🔴 apps/app/src/app/(app)/[orgId]/frameworks/page.tsx (HIGH Risk)

#	Issue	Risk Level
1	IDOR: orgId from params used without verifying user's membership	HIGH
2	Auth bypass: no access denial if member is null	HIGH
3	Cache data leak: cache() used for session/org-dependent functions	HIGH
4	Cached functions have no user/org cache key; may return others' data	HIGH
5	Unvalidated orgId used directly in DB queries	HIGH
6	Excessive data exposure: full member record passed to client	HIGH
7	headers() used inside cached funcs may return stale/wrong request context	HIGH

Recommendations:

1. Enforce authorization: verify the authenticated user is a member of the organizationId from params (or deny/redirect) before loading org-specific data. Do not rely on later optional member lookups for access control.
2. Fail-closed on missing membership: if the member lookup returns null, return a 403/redirect rather than continuing to render org data.
3. Avoid caching request- or user-specific data in global caches: remove cache() from getScores/getControlTasks or include a cache key based on the session user id and organization id so cached values cannot leak across users/orgs.
4. Use session-bound organization id for sensitive queries where appropriate (e.g., session.session.activeOrganizationId) and confirm it matches the route orgId if the route must support cross-org viewing.
5. Validate and canonicalize route params (orgId) before use (e.g., ensure correct UUID format) and fail-fast on invalid values.
6. Limit data returned from DB queries: use select to return only the fields needed (for member, tasks, frameworks) to avoid exposing unnecessary sensitive fields to the client.
7. Do not call headers() inside cached functions that can be reused across requests. For request-scoped data, compute per-request (uncached) or derive and pass explicit cache keys tied to request/session context.
8. Introduce centralized authorization middleware (or server-side guard) so all org-scoped routes enforce the same membership checks before any DB reads.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade vulnerable packages: update xlsx@0.18.5 to a release that addresses GHSA-4r6h-8v6p-xvw6 and GHSA-5pgg-2g8v-p4x9, and update ai to >=5.0.52 (fixes GHSA-rwvc-j5jr-mgvh). Pin the fixed versions in package.json and re-run the audit to verify resolution.
2. Validate/normalize orgId and enforce authorization before DB access: add a server-side guard or middleware that validates orgId format (e.g., UUID/type check) and verifies the requesting user is a member of that organization; fail-closed (403) before any DB queries or data construction in getPeople.ts and page.tsx.
3. Stop using globally cached request-scoped functions and limit returned fields: remove cache() from functions that call headers()/session or include a cache key containing session.user.id and orgId; and change DB queries to select only the fields required for the client (avoid returning full member records).

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Nov 26, 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.

✅ carhartlewis
❌ 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.67.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀