Skip to content

chore: update all dependencies to latest stable #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
alaxricardsilva wants to merge 1 commit into
base: master
Choose a base branch
from
Open

chore: update all dependencies to latest stable #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions .github/workflows/docker-backend-image.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,19 +22,19 @@ jobs:
uses: actions/checkout@v4

- name: "Use Node.js"
uses: actions/setup-node@v4
uses: oven-sh/setup-bun@v2
with:
node-version: '20.x'
bun-version: '1.3.14'
Comment on lines +25 to +27

@coderabbitai coderabbitai Bot Jun 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/docker-backend-image.yml | head -35

Repository: alaxricardsilva/Atendlyx-Izing

Length of output: 1043

🌐 Web query:

GitHub Actions security best practices commit SHA tag pinning mutable

💡 Result:

GitHub Actions security best practices mandate pinning actions to full-length (40-character) commit SHAs to ensure immutability and mitigate supply chain risks [1][2][3][4]. Why Pinning is Necessary: Git tags (e.g., v1, v4) and branch references (e.g., main, master) are mutable [2][5][6]. Anyone with push access to an action’s repository can move these references to point to a different, potentially malicious commit at any time [1][5][7][8]. If you use a mutable tag, your workflow may execute code that you have not audited or approved [9][10][6]. Pinning to a full-length commit SHA ensures that the exact, immutable version of the code you audited is executed every time, protecting your pipeline from "tag poisoning" or account compromise [1][5][4]. Best Practice Implementation: 1. Use Full-Length SHAs: Always use the complete 40-character commit hash [5][7][4]. Short SHAs are insufficient and less secure [5]. 2. Include Informative Comments: Append a human-readable comment (e.g., # v4.1.1) after the SHA [3][6]. This maintains readability and allows automated tools like Dependabot or Renovate to correctly identify and propose updates for newer versions [3][9][7][11]. 3. Automate Updates: Use Dependabot or Renovate to monitor for updates [9][11][6]. These tools recognize SHA-pinned actions and can automatically open pull requests to bump the SHA to the latest secure release [3][7][11]. 4. Enforce Policies: GitHub administrators can enforce SHA pinning at the organization or repository level [1][12][8]. When this policy is enabled, workflows using unpinned actions (tags or branches) will fail, forcing compliance across the dependency tree, including transitive actions [12][8][10]. 5. Consider "Cooldowns": To further mitigate supply chain risks, some security teams implement a "cooldown" period (e.g., 7–14 days) before adopting new action versions, reducing the window of exposure to recently injected malicious code [10]. Example of Secure Pinning: - uses: actions/checkout@b4ffde6 # v4.1.1 By moving from mutable tags to immutable SHA references, you establish a reliable baseline for workflow security that is significantly more resistant to external tampering [1][3][4][6].

Citations:

🌐 Web query:

oven-sh setup-bun action security vulnerability

💡 Result:

There is no widely recognized, specific "security vulnerability" (in the sense of a known CVE or an unpatched critical exploit) currently associated with the oven-sh/setup-bun GitHub Action as of June 2026 [1][2]. However, there is active community discussion and ongoing development regarding hardening the action against supply chain risks: 1. Asset Verification: Development work has been underway to improve the integrity of downloaded archives [3]. Pull requests have introduced mechanisms to compute local hashes and enforce the verification of signed manifests to ensure the downloaded Bun binaries have not been tampered with [3]. 2. Immutable Releases: Users have raised concerns regarding the need for "immutable releases" within GitHub Actions to mitigate potential supply chain risks [1]. Some users advocate for pinning actions by commit SHA rather than by tag (e.g., uses: oven-sh/setup-bun@v2 vs uses: oven-sh/setup-bun@<commit-sha>) as a general best practice for all third-party actions to prevent unexpected changes [1]. 3. Third-Party Alternatives: Alternative community implementations, such as step-security/setup-bun, exist and market themselves as secure, drop-in replacements, emphasizing enhanced security features [4]. The oven-sh/setup-bun action remains the official, GitHub-verified way to set up Bun in CI/CD workflows [2][5][6]. Like any third-party CI/CD action, it is recommended to follow standard security practices: - Pin the action to a specific commit SHA to ensure immutability [1]. - Regularly audit your workflows for dependencies. - Keep the action updated to the latest version to benefit from security and integrity improvements [3].

Citations:

Fixe a ação para um commit SHA imutável, não para uma tag.

oven-sh/setup-bun@v2 é mutável. Para hardening da cadeia de CI, use o hash completo do commit (40 caracteres), seguido por um comentário legível com a versão (ex: # v2.x.x). Tags podem ser movidas por qualquer usuário com acesso ao repositório da ação, criando risco de supply chain attack.

🧰 Tools
🪛 zizmor (1.25.2)

[error] 25-25: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/docker-backend-image.yml around lines 25 - 27, The
setup-bun action is referenced using a mutable version tag (`@v2`) which poses a
supply chain security risk since tags can be moved. Replace the tag reference in
the uses field of the setup-bun action with the full immutable commit SHA (40
characters), and add a comment on the same line indicating the corresponding
version (e.g., # v2.x.x) for readability. This ensures the workflow uses a
specific, unchangeable commit rather than a potentially moving tag.

Source: Linters/SAST tools


- name: "Verify Node.js version"
run: node -v
- name: "Verify Bun version"
run: bun --version

- name: Build Backend
run: |
cd backend
npm install
PUPPETEER_SKIP_DOWNLOAD=true PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true bun install --frozen-lockfile
export NODE_OPTIONS="--max_old_space_size=4096"
CI=false npm run build
CI=false bun run build

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
Expand All @@ -49,4 +49,3 @@ jobs:
run: |
docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 -t izingopenio/izingopenio-backend:latest --push ./backend

16 changes: 6 additions & 10 deletions .github/workflows/docker-frontend-image.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,25 +22,21 @@ jobs:
uses: actions/checkout@v4

- name: "Use NodeJS"
uses: actions/setup-node@v4
uses: oven-sh/setup-bun@v2
with:
node-version: '20.x'
bun-version: '1.3.14'
Comment on lines +25 to +27

@coderabbitai coderabbitai Bot Jun 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/docker-frontend-image.yml | head -50

Repository: alaxricardsilva/Atendlyx-Izing

Length of output: 1488

🏁 Script executed:

# Check if the file exists and get its full content length
wc -l .github/workflows/docker-frontend-image.yml

Repository: alaxricardsilva/Atendlyx-Izing

Length of output: 121

🌐 Web query:

GitHub Actions pinning to commit SHA best practices security

💡 Result:

Pinning GitHub Actions to a full-length commit SHA (40 characters) is a critical security best practice to protect against supply chain attacks [1][2][3]. Because Git tags and branches are mutable—meaning they can be overwritten or force-pushed to point to different commits—relying on them exposes your workflows to risks where a compromised upstream repository could inject malicious code into your CI/CD pipelines [4][5][3]. Best Practices for SHA Pinning: 1. Use Full-Length SHAs: Always use the full 40-character commit SHA [1][6][3]. Short SHAs are insufficient and insecure [3]. 2. Document with Comments: When pinning to a SHA, include the original tag or version as a comment on the same line (e.g., uses: actions/checkout@<sha> # v4.2.0) [5][7][3]. This practice allows automated tools like Dependabot and Renovate to correlate the pin with semantic versions and generate appropriate update pull requests [8][7][9]. 3. Automate Updates: Do not avoid updates; use automated dependency management tools such as Dependabot or Renovate to keep your pinned SHAs current [4][10][7]. These tools can be configured to automatically open pull requests when new tagged versions of an action are released, maintaining both security and up-to-date functionality [8][5][9]. 4. Enforce via Policy: Organizations can enforce this practice at the repository or organization level using GitHub's "allowed actions and reusable workflows" policy [11][8]. Enabling this policy causes any workflow referencing a non-SHA (i.e., a tag or branch) to fail, ensuring consistent adherence across your codebase [11][8][7]. 5. Use Helper Tools: Utilize specialized CLI tools to help identify, apply, and maintain SHA pins across your workflows. Popular options include: - pinact [12] - frizbee [10] - ratchet [10] - pin-github-action [10] - actionlint (for validation) [7] While pinning to a SHA is the most secure method, it is particularly essential for third-party actions [4][3]. Actions managed by GitHub (e.g., in the actions/ organization) are generally considered safer due to GitHub's internal supply chain controls, but pinning them remains a recommended hardening step for high-security environments [6][3]. Finally, remember that SHA pinning protects against the retargeting of existing tags or branches, but it does not protect against malicious code that may have been intentionally introduced in the upstream repository before you pinned it [7][9]. Always vet third-party actions before integrating them into your workflows [1][6].

Citations:

Fixe a ação em um commit SHA específico para garantir a integridade da pipeline.

A tag @v2 é mutável e pode ser reescrita em repositórios upstream, expondo a pipeline a riscos de supply chain attacks. Use o SHA completo com 40 caracteres e adicione um comentário com a versão original para que ferramentas de automação como Dependabot possam rastrear atualizações:

uses: oven-sh/setup-bun@[SHA-40-caracteres] # v2
🧰 Tools
🪛 zizmor (1.25.2)

[error] 25-25: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/docker-frontend-image.yml around lines 25 - 27, The
oven-sh/setup-bun action is currently pinned to a mutable tag `@v2` which creates
a supply chain security risk. Replace the `@v2` tag with the full 40-character
commit SHA of that version and add an inline comment with the original version
tag (# v2) so automation tools like Dependabot can properly track future
updates. This ensures the pipeline always uses a specific immutable commit
rather than a tag that could be rewritten upstream.

Source: Linters/SAST tools


- name: Verify Node.js version
run: node -v

- name: Install Quasar CLI
run: npm install -g @quasar/cli
- name: Verify Bun version
run: bun --version

- name: Install dependencies
run: npm install
run: bun install --frozen-lockfile
working-directory: ./frontend

- name: Build Frontend
run: |
cd frontend
export NODE_OPTIONS=--openssl-legacy-provider
npx quasar build -P -m pwa
bun run build

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
Expand Down
12 changes: 6 additions & 6 deletions backend/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
FROM node:18-bookworm-slim as global-deps-stage
FROM oven/bun:1.3.14-debian as global-deps-stage

WORKDIR /app

Expand All @@ -9,23 +9,23 @@ RUN apt-get update \
&& apt-get update \
&& apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 \
--no-install-recommends \
&& rm -rf /var/lib/apt/lists/* && npm install pm2@latest -g
&& rm -rf /var/lib/apt/lists/* && bun add -g pm2@latest

@coderabbitai coderabbitai Bot Jun 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n backend/Dockerfile

Repository: alaxricardsilva/Atendlyx-Izing

Length of output: 1527

Fixe uma versão exata para pm2 em vez de usar @latest.

Usar pm2@latest em dependência global de runtime torna a imagem não determinística, pois cada build pode instalar uma versão diferente de pm2. Isto aumenta o risco de quebras inesperadas e expõe a aplicação a vulnerabilidades de supply-chain. O restante do Dockerfile já segue a prática de pinning (ffmpeg=7:5.1.4-0+deb12u1, bun:1.3.14-debian), então pm2 deve fazer o mesmo. Substitua pm2@latest por uma versão validada, como pm2@5.x.x.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/Dockerfile` at line 12, The pm2 installation in the Dockerfile is
using `@latest` instead of a pinned version, which makes the image
non-deterministic and introduces supply-chain risks. Replace the `pm2@latest`
specification in the `bun add -g pm2@latest` command with a specific validated
version number, such as `pm2@5.x.x` or a more precise version, to maintain
consistency with the pinning approach already used for other dependencies like
ffmpeg and bun in the same Dockerfile.


ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD true
ENV NODE_ENV=dev
ENV CHROME_BIN=google-chrome-stable

FROM global-deps-stage as develop-stage
COPY package*.json ./
RUN npm install
COPY package.json bun.lock ./
RUN PUPPETEER_SKIP_DOWNLOAD=true PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true bun install --frozen-lockfile

FROM develop-stage as build-stage
COPY . .
RUN npm run build
RUN bun run build

FROM build-stage as development-stage
ENV NODE_ENV=development
ENTRYPOINT ["npm", "run", "dev:server"]
ENTRYPOINT ["bun", "run", "dev:server"]

FROM build-stage as production-stage
ENV NODE_ENV=production
Expand Down
3,680 changes: 3,680 additions & 0 deletions backend/bun.lock
View file
Open in desktop

Large diffs are not rendered by default.

Loading