fix(api): update buildspec and Dockerfile to prepare workspace packag…

[Itsnotaka]

…es for Docker

What does this PR do?

• Fixes #XXXX (GitHub issue number)
• Fixes COMP-XXXX (Linear issue number - should be visible at the bottom of the GitHub issue description)

Visual Demo (For contributors especially)

A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).

Video Demo (if applicable):

• Show screen recordings of the issue or feature.
• Demonstrate how to reproduce the issue, the behavior before and after the change.

Image Demo (if applicable):

• Add side-by-side screenshots of the original and updated change.
• Highlight any significant change(s).

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
app	Skipped			Nov 18, 2025 4:48pm
portal	Skipped			Nov 18, 2025 4:48pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

3 OSV vulnerabilities: xlsx v0.18.5 (2 HIGH: Prototype Pollution, ReDoS) and ai v5.0.0 (LOW; filetype whitelist bypass; fixed in 5.0.52).

---

📦 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/api/Dockerfile (HIGH Risk)

#	Issue	Risk Level
1	Remote install via curl	bash (bun) allows arbitrary code execution

Recommendations:

1. Do not pipe remote scripts directly into a shell. Download the installer first (curl -fSL -o bun-install.sh), verify its checksum or signature, then run it.
2. Pin the bun installer / runtime to a specific, known-good version and verify its integrity (sha256 or GPG) before executing.
3. Remove the '|| true' after 'bun install' so that installation failures break the build instead of being silently ignored.
4. Use a multi-stage build: run installers and build steps in a build stage, then copy only the runtime artifacts into a minimal final image so installer tooling and caches are not present in the final image.
5. If possible, use an official, version-pinned bun runtime base image (or prebuilt artifacts) rather than installing from the network during build.
6. Prefer building dependencies deterministically inside the image (or include verified, checksumed node_modules). If you must copy prebuilt node_modules, verify checksums or use an artifact repository to avoid tampered packages.
7. Pin the base image by digest (e.g. node:20-alpine@sha256:...) and scan final images with an image scanner for known CVEs and malware.
8. Run installer steps as a non-root user or drop privileges after installation where possible; at minimum perform installation in a temporary build stage running as root and ensure the final stage runs as an unprivileged user.
9. Protect the build environment against MITM: use HTTPS with certificate verification (curl -fSL does this by default), avoid insecure proxies, and consider reproducible builds or signed release artifacts.

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

#	Issue	Risk Level
1	curl	bash from bun.sh — arbitrary remote code execution
2	No integrity check for bun installer (no checksum/signature)	HIGH
3	Echoing APP_NAME may leak sensitive env vars to logs	HIGH
4	Build runs with root paths (/root/.bun) — privileged execution	HIGH
5	Unsanitized IMAGE_TAG from CODEBUILD_RESOLVED_SOURCE_VERSION used in docker tag/push	HIGH
6	Docker build context can include malicious Dockerfile to exfiltrate secrets	HIGH
7	No image vulnerability scanning before pushing to ECR	HIGH
8	Persistent node_modules cache enables dependency poisoning across builds	HIGH

Recommendations:

1. Do not pipe remote installers to a shell. Vendor the bun binary, use a package manager, or download the installer and verify signatures/checksums before executing.
2. Verify the bun installer integrity: fetch a published checksum/signature over HTTPS and validate it prior to running the installer.
3. Avoid printing environment variables or sensitive values to build logs. Remove or redact echo lines that reveal env var contents (e.g., APP_NAME) or restrict log access.
4. Run builds as a non-root user where possible and ensure CodeBuild IAM role follows least privilege. Avoid relying on /root paths for tooling installation.
5. Sanitize and validate IMAGE_TAG before using it in docker tag/push. Restrict allowed characters and length, and fall back to a safe default if the derived tag is malformed.
6. Limit Docker build context and ensure .dockerignore excludes secrets and CI credentials. Use multi-stage builds and explicitly control files copied into images. Consider building from a controlled build context (e.g., a prepared artifact) rather than the repo root.
7. Integrate image vulnerability scanning (ECR image scanning, Clair, Trivy, etc.) in CI/CD and block push/deploy on high severity findings.
8. Avoid long-lived node_modules caches for CI or verify/cache by lockfile integrity. Rebuild dependencies from lockfile and consider ephemeral install caches or integrity checks to mitigate dependency poisoning.

---

💡 Recommendations

View 3 recommendation(s)

1. Upgrade vulnerable packages in package.json: bump ai to >=5.0.52 (per scan) and upgrade xlsx from 0.18.5 to a patched release (check SheetJS advisories/changelog), then reinstall dependencies and run tests.
2. Protect against prototype pollution from spreadsheet parsing: never merge parsed objects directly into application prototypes; create results with Object.create(null) or validate/whitelist parsed object keys before merging into app state.
3. Harden parsing of untrusted files to reduce ReDoS/filetype bypass impact: enforce server-side file size and MIME checks, parse uploads in a constrained worker or sandbox with timeouts, and validate/normalize file contents before passing to xlsx.

---

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

[CLAassistant]

All committers have signed the CLA.

[claudfuen]

🎉 This PR is included in version 1.59.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀