Skip to content

Conversation

@Marfuen
Copy link
Contributor

@Marfuen Marfuen commented Oct 14, 2025

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 vercel bot temporarily deployed to Preview – portal October 14, 2025 20:43 Inactive
@vercel
Copy link

vercel bot commented Oct 14, 2025

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

2 Skipped Deployments
Project Deployment Preview Comments Updated (UTC)
app Skipped Skipped Oct 14, 2025 8:43pm
portal Skipped Skipped Oct 14, 2025 8:43pm

@comp-ai-code-review
Copy link

comp-ai-code-review bot commented Oct 14, 2025

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

OSV/npm scan: no CVEs found. Dockerfile contains a piped remote-install (curl https://bun.sh/install | bash) and a broad COPY . . which can embed repo files into the image.


📦 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 Remote script execution: curl https://bun.sh/install bash
2 Unverified package install: bun install without checksum/lock verification HIGH
3 Potential secret leakage: COPY . . may bake .env/keys into image HIGH

Recommendations:

  1. Do not pipe remote scripts directly into shell during image builds. Instead, download the installer artifact over HTTPS, verify its signature/checksum, and run the verified installer from a local file. Prefer pinned release tarballs or signed releases.
  2. Ensure deterministic dependency installation: include and COPY the appropriate lockfile (bun.lockb or package-lock.json/yarn.lock) into the image before running bun install, and verify checksums. Consider using a verified package registry, and avoid --ignore-scripts unless you understand/need it. Where supported, use reproducible, verified installs (e.g., bun install using lockfile).
  3. Harden the build context: keep a .dockerignore that excludes .env and other secret files (confirm it is present and correct). Additionally, remove secrets from the repository, use build-time ARGs or secret managers (Docker BuildKit secrets, CI secrets) rather than baking secrets into images, and consider multi-stage builds so build tools and temporary files never end up in the final runtime image.
  4. Use multi-stage builds so the final image only contains runtime artifacts; perform all installs and code generation in a build stage, and COPY only the necessary output (dist, node_modules pruned for production) into the final stage running as a non-root user.
  5. Limit network exposure during build where possible (e.g., run installs from an internal artifact mirror), and pin base image versions (you already use node:20-alpine — keep explicit versions/tags and periodically scan base image for CVEs).
  6. Add CI checks that fail the build when unexpected sensitive files are present in the build context, and scan images for secrets and malware as part of CI/CD.

💡 Recommendations

View 3 recommendation(s)
  1. Stop piping remote scripts in the Dockerfile: download the installer to a local file (e.g. RUN curl -fSL -o /tmp/bun-install.sh https://bun.sh/install), verify its checksum/signature in the Dockerfile build steps, then run the verified file (sh /tmp/bun-install.sh).
  2. Replace COPY . . with explicit COPY directives that only bring required files into the image (for example, COPY package.json src/ dist/ /app/) so unintended files are not included in the image.
  3. Add a .dockerignore that excludes sensitive files from the build context (at minimum: .env, *.key, *.pem, .git, node_modules) and ensure the Dockerfile copies only the files needed for the build/runtime.

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

@Marfuen Marfuen merged commit 09adcf6 into main Oct 14, 2025
8 checks passed
@Marfuen Marfuen deleted the mariano/api-fix-7 branch October 14, 2025 20:43
@claudfuen
Copy link
Contributor

🎉 This PR is included in version 1.56.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants