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

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
app (staging)	Skipped			Nov 18, 2025 5:04pm
portal (staging)	Skipped			Nov 18, 2025 5:04pm

[comp-ai-code-review]

Comp AI - Code Vulnerability Scan

⏳ Analysis in progress...

Reviewing 2 file(s). This may take a few moments.

---

Powered by Comp AI - AI that handles compliance for you | Reviewed Nov 18, 2025, 04:39 PM

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV scan found 3 vulnerabilities: xlsx@0.18.5 (2 HIGH: prototype pollution, ReDoS) and ai@5.0.0 (LOW). No hardcoded credentials found. download-agent code accepts unvalidated 'os' and tokens in URLs.

---

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

🔴 apps/api/Dockerfile (HIGH Risk)

#	Issue	Risk Level
1	Remote code execution via curl	bash installer (bun.sh) at build time
2	No checksum/signature verification for downloaded installer	HIGH
3	Ignored bun install failures (
4	COPY . . may overwrite installed node_modules allowing tampered deps	HIGH
5	Copying node_modules from context may introduce unverified packages	HIGH

Recommendations:

1. Do not pipe remote installers directly into a shell. Download the installer first, verify its integrity, then run it in a controlled way (e.g., RUN curl -fsSL -o /tmp/bun-install.sh && verify && bash /tmp/bun-install.sh).
2. Verify the installer using a pinned checksum or signature (e.g., compare SHA256, verify GPG signature) before executing. Pin to a specific, known-good version instead of installing the latest implicit release.
3. Remove the '|| true' that masks bun install failures so the build fails on installer or dependency errors. Fail-fast prevents continuing with a partial/missing/compromised environment.
4. Add a .dockerignore (exclude node_modules, .env, etc.) to prevent host files from being copied into the image. Explicitly avoid copying node_modules from the build context.
5. Use multi-stage builds: install dependencies inside the image (or use a verified lockfile) in a clean stage and copy only the built artifacts into the final runtime image instead of copying node_modules from the host.
6. Prefer installing bun via a packaged distribution or an official release artifact when available (or pin the installer URL to a specific release tarball) so you can verify signatures/checksums more reliably.
7. If you must copy certain node_modules from the context, ensure those artifacts are produced by a trusted CI pipeline and verify checksums or signatures before including them in the image.

🔴 apps/api/buildspec.yml (HIGH Risk)

#	Issue	Risk Level
1	Unverified curl	bash installer for bun (remote code execution)
2	Docker build context includes node_modules and prisma (secret leakage)	HIGH
3	Copies host files into image; .env or credentials may be included	HIGH
4	Build commands list files and echo vars; logs may expose secrets	HIGH
5	No validation of AWS/ECR/ECS env vars before use	HIGH
6	Using --ignore-scripts fallbacks may skip important install hooks	HIGH

Recommendations:

1. Replace curl | bash installer with a verified installer: use a pinned release (checksum/PGP), install from a package repository, or vendor the installer artifact into CI. Validate the downloaded script's checksum before executing.
2. Use a .dockerignore and multi-stage Docker builds so the build context does not include node_modules, source files, or other host artifacts. Only copy the minimal build artifacts into the image.
3. Avoid copying arbitrary host folders into the image. Explicitly exclude .env, credentials, and other secrets. Use build-time secret mechanisms (Docker BuildKit secrets) or inject secrets at runtime (CI secret store, AWS Secrets Manager, ECS task definition secrets).
4. Do not print or ls sensitive directories or environment variables in CI logs. Mask sensitive variables in the CI system, remove echo statements that show values (e.g., APP_NAME) if it can be sensitive, and avoid verbose command output that can leak secrets. Consider redaction and stricter log retention policies.
5. Validate required CI/env variables before use (e.g., AWS_ACCOUNT_ID, ECR_REPOSITORY_URI, ECS_CLUSTER_NAME, ECS_SERVICE_NAME) and fail early with non-sensitive error messages. Also limit the CI role’s permissions and use short-lived credentials.
6. Avoid falling back to --ignore-scripts. Diagnose and fix the failing postinstall/preinstall scripts or run necessary install hooks explicitly in the pipeline in a controlled way. If scripts must be skipped, document the risk and ensure no security-related hooks are bypassed.
7. Scan built images and artifacts for secrets prior to pushing (e.g., trivy, gitleaks, GitGuardian). Add automated image vulnerability scanning in the pipeline.
8. Harden Docker build by using a minimal base image, running as non-root inside the container, and minimizing installed packages to reduce attack surface.

🟡 apps/portal/src/app/(app)/(home)/[orgId]/components/tasks/DeviceAgentAccordionItem.tsx (MEDIUM Risk)

#	Issue	Risk Level
1	Download token included in URL query (can leak via Referer or logs)	MEDIUM
2	Client sends forgeable orgId/employeeId to /api/download-agent/token	MEDIUM
3	No CSRF protection visible for POST to /api/download-agent/token	MEDIUM
4	Detected OS value is used without validation in download URL	MEDIUM
5	Sensitive token exposed to browser history and extensions	MEDIUM

Recommendations:

1. Do not put auth tokens in URL query parameters. Instead: return the installer from an authenticated endpoint (e.g., a GET to /api/download-agent that requires server-side session/cookie auth) or use an Authorization header. For client-initiated downloads, use fetch() with the token in the Authorization header, convert response to a Blob and createObjectURL for download so the token never appears in the URL or browser history.
2. Make download tokens one-time use, short TTL, and bound to the authenticated user/session (and optionally client IP / user agent). Server must validate that the requesting user (from session/auth) is authorized for the requested orgId/employeeId and that the token matches those constraints.
3. Enforce CSRF protections on the /api/download-agent/token endpoint if it accepts state-changing requests that rely on cookie/session auth. Options: require a CSRF token (double submit cookie), use SameSite=strict/lax for auth cookies, or require Authorization headers (Bearer tokens) which are not sent by browsers in CSRF attacks.
4. Validate and whitelist the detectedOS value server-side (accept only expected values like 'macos', 'macos-intel', 'windows') before using it to select/download a binary. Treat client-provided values as untrusted.
5. Avoid exposing sensitive tokens to Referer headers and browser history. If an anchor tag must be used, set a strict referrer policy on the page (e.g., ) and consider adding rel="noreferrer noopener" to links. Prefer the fetch+blob approach to keep tokens out of URLs entirely.
6. Set appropriate cache-control headers on the download response (Cache-Control: no-store, Pragma: no-cache) and ensure responses do not get stored in intermediate logs or caches.
7. Log and monitor token usage (issuance, consumption, failures). Implement rate limiting and revoke tokens on suspicious activity.

🟡 apps/portal/src/app/api/download-agent/route.ts (MEDIUM Risk)

#	Issue	Risk Level
1	Download token in URL query (exposed via referer/logs)	MEDIUM
2	No validation that token matches requested OS/file	MEDIUM
3	Missing input validation for 'os' and 'token' params	MEDIUM
4	Non-atomic KV get+del allows race/replay use of token	MEDIUM
5	No rate limiting or abuse protection on download endpoint	MEDIUM
6	Error logs may leak sensitive info (stack/obj logged)	MEDIUM
7	No content-type/size validation of S3 objects before streaming	MEDIUM

Recommendations:

1. Avoid sending one-time tokens in URL query parameters. Use Authorization header, POST body, or an HttpOnly secure cookie to prevent leakage via referer and logs.
2. Bind download tokens to the exact asset/OS in the KV entry and validate that the requested 'os' matches the token's allowed asset before serving.
3. Validate and sanitize input: enforce an allowlist for 'os' (e.g., 'macos', 'macos-intel', 'windows') and validate token format/length. Return minimal error messages.
4. Use an atomic get-and-delete operation for single-use tokens (or store a token state and use a KV primitive that supports atomic operations) to prevent race conditions and replay.
5. Implement rate limiting and abuse protections per IP/account for this endpoint to mitigate brute-force or mass-download attacks.
6. Avoid logging full error objects or stack traces in production. Log structured, sanitized error identifiers and capture detailed errors in a secure internal error-tracking system.
7. Validate S3 object metadata before streaming: check Content-Type and Content-Length (size) and ensure the object key matches expected patterns. Consider serving pre-signed S3 URLs with limited expiry instead of proxying streams when appropriate.
8. Sanitize filename used in Content-Disposition to prevent header injection and ensure proper quoting; set appropriate Content-Security and download-related headers.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade vulnerable npm packages: bump xlsx (0.18.5) to a version that patches GHSA-4r6h-8v6p-xvw6 and GHSA-5pgg-2g8v-p4x9, and upgrade ai from 5.0.0 to >=5.0.52 (fixes GHSA-rwvc-j5jr-mgvh). Update package.json/lockfile and run tests.
2. Change how download tokens are delivered/validated in apps/portal/src/app/api/download-agent/route.ts and apps/portal/src/app/(app)/(home)/[orgId]/components/tasks/DeviceAgentAccordionItem.tsx: do not place auth tokens in URL query strings; accept tokens via Authorization header or POST body, bind tokens to the exact asset/OS and enforce single-use semantics in storage.
3. Add strict server-side validation and sanitization for inputs used to select or name downloads: implement a whitelist for 'os' (e.g., 'macos','macos-intel','windows'), validate token format/length before use, and properly sanitize/quote any filename placed in Content-Disposition to prevent header injection.

---

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

✅ Itsnotaka
❌ 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.59.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀