chore(api): add prisma client and update bun install command

[Marfuen]

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

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

No OSV/package CVEs found. Scanner flags the apps/api/Dockerfile: it pipes a remote bun installer into a shell and runs installs as root.

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 1 file(s) with issues

🔴 apps/api/Dockerfile (HIGH Risk)

#	Issue	Risk Level
1	RCE: piping remote bun installer (curl	bash) during image build
2	Build-time root execution: installer runs as root, risks CI compromise	HIGH
3	COPY . . after deps install can overwrite or inject files from build context	HIGH
4	No integrity/signature verification for downloaded installer	HIGH

Recommendations:

1. Do not pipe remote scripts directly into a shell. Download the installer to a file first, inspect it, and verify its integrity before executing.
2. Verify the installer using a trusted checksum or GPG signature published by the vendor before running it (compare SHA256/PGP signatures obtained over a secure channel).
3. Use a multi-stage build or an official bun base image so the installer does not run in the same layer as your final runtime image. In multi-stage builds, install/build in a builder stage and copy only the artifacts you need into the runtime stage.
4. Avoid running installers as root. Create a dedicated non-root build user and run the installer and dependency installation as that user in the builder stage. This reduces the blast radius if a malicious installer runs.
5. Add and maintain a .dockerignore to prevent unnecessary files from being included in the build context (e.g., .git, local node_modules, secrets, CI configs).
6. Do not use COPY . . after installing deps in the image. Instead, copy only required files (or copy source into the builder stage) so files in the build context cannot overwrite installed artifacts. Alternatively, perform dependency installation after copying only package manifests and source files needed for install.
7. Pin the bun installer / runtime version you install to an explicit release to avoid unexpected upstream changes. Consider fetching the installer from a pinned URL if provided by the vendor.
8. Consider vendorizing/building bun and dependencies outside CI in a trusted pipeline or use reproducible images from a trusted registry to remove the need to download and execute remote installers during image build.

---

💡 Recommendations

View 3 recommendation(s)

1. Do not pipe a remote installer into a shell in the Dockerfile. Instead download the installer to a file (e.g. curl -fSL -o /tmp/bun-installer.sh), verify its integrity (SHA256 or GPG signature) and then execute the local file with an explicit path.
2. Perform installations in a builder stage and as a non-root user. Create a builder stage or add a non-root user in the Dockerfile, run the installer and dependency installs as that user, then copy only the built artifacts into a minimal final stage.
3. Avoid COPY . . after installing dependencies. Copy only package manifests (package.json, lockfile) to install deps, then copy the application source; add a .dockerignore and explicitly include only the files needed for build to prevent context files from overwriting image content.

---

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

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
app	Building	Preview	Comment	Oct 14, 2025 8:23pm
portal	Building	Preview	Comment	Oct 14, 2025 8:23pm

[claudfuen]

🎉 This PR is included in version 1.56.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀