Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
2 changes: 1 addition & 1 deletion .github/workflows/delete-orphan-edges.yml
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,7 @@ jobs:
echo "✅ Confirmação aceita. Procedendo com a remoção real."

- name: Setup Supabase CLI
uses: supabase/setup-cli@v1
uses: supabase/setup-cli@v2
with:
version: latest
Comment on lines +58 to 60
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== 1) Detectar refs flutuantes nos workflows =="
rg -n 'supabase/setup-cli@v2|version:\s*latest' .github/workflows

echo
echo "== 2) Resolver commit SHA real da tag v2 =="
REF_JSON="$(gh api repos/supabase/setup-cli/git/ref/tags/v2)"
OBJ_TYPE="$(jq -r '.object.type' <<<"$REF_JSON")"
OBJ_SHA="$(jq -r '.object.sha' <<<"$REF_JSON")"

if [[ "$OBJ_TYPE" == "tag" ]]; then
  COMMIT_SHA="$(gh api repos/supabase/setup-cli/git/tags/"$OBJ_SHA" --jq '.object.sha')"
else
  COMMIT_SHA="$OBJ_SHA"
fi

echo "commit_sha_v2=$COMMIT_SHA"

Repository: adm01-debug/Promo_Gifts

Length of output: 512


🌐 Web query:

GitHub Actions pinning version SHA security best practices

💡 Result:

Best practice: Pin GitHub Actions to a full-length (40-character) commit SHA in every uses: reference, and (where possible) enforce this via the GitHub “allowed actions” policy so workflows fail if an action isn’t pinned. 1) Why pin to commit SHA (not tags/branches) - GitHub security hardening guidance recommends pinning actions to a full-length commit SHA because it makes the action behave like an immutable release; this helps mitigate the risk of a bad actor adding a backdoor to an action repository by changing what a mutable ref points to. [1] - Pinning a short SHA is explicitly insecure; GitHub warns that short SHAs can collide because users can fork and craft commits, and workflows using shortened SHAs will fail. [2] 2) What GitHub expects your workflow to look like - Example pattern from GitHub action versioning guidance: use the long SHA form rather than @vX.Y.Z or @main. [3] - GitHub policy enforcement checks for a “full commit SHA”; if an action isn’t pinned, the workflow fails. [4] 3) How to operationalize it (enforcement) - GitHub’s “allowed actions” policy can enforce SHA pinning. When enabled, workflows that attempt to use an action that isn’t pinned to a full commit SHA will fail. [4] - At the enterprise level, GitHub also documents an option “Require actions to be pinned to a full-length commit SHA” (including GitHub-authored actions). [5] 4) Managing updates without losing security - GitHub recommends pinning to SHAs to prevent malicious code from being automatically used when branches/tags are updated. [4] - Dependabot can be used to update vulnerable actions and can work with SHA-pinned actions; GitHub notes that Dependabot only creates alerts for vulnerable actions that use semantic versioning and will not create alerts for actions pinned to SHA values. [1] - If you want automated updates for SHA pins specifically, you’ll typically use a dedicated workflow/tool approach (e.g., Dependabot/Renovate with support for SHA-pinned updates, or a “ensure SHA pinned actions” job) rather than relying on Dependabot vulnerability alerts alone. (Policy guidance around updating pinned actions is discussed in community-maintenance PRs and tooling, but the core official security recommendation is still the SHA pin + enforcement pattern.) [6][7] 5) Practical security hardening checklist (pinning is one part) - Alongside SHA pinning, GitHub’s security-hardening guidance also covers other controls (e.g., trusting tags only if you trust the creator; auditing action code; and governance via policies). [1] Example: SHA pinning in a workflow - Use: - uses: OWNER/REPO@<FULL_40_CHAR_SHA> # <optional human-readable version> - Avoid: - uses: OWNER/REPO@v4 (mutable to minor/patch updates) - uses: OWNER/REPO@main / @latest (branches/tags can move) If you tell me which actions you currently use (the uses: lines from your workflows), I can help you convert them to full-SHA pins and suggest an enforcement configuration consistent with your org/repo setup.

Citations:


🌐 Web query:

supabase setup-cli latest version stable release

💡 Result:

Latest stable Supabase CLI release (as of 2026-05-11): v2.98.1 (published 2026-05-04). [1] Notes about “setup-cli” (GitHub Action) vs “Supabase CLI version”: - The GitHub Action supabase/setup-cli is a separate project from the Supabase CLI itself; the action accepts a version input and installs that CLI version (or latest if omitted). [2][3] - In the action’s action.yml, if version is omitted it “detect[s] from the root lockfile and otherwise use latest.” [3] How to pin the stable CLI in CI using supabase/setup-cli: - Use the stable CLI version explicitly: - uses: supabase/setup-cli@v2 - with: { version: "2.98.1" } [2][3] - Or let the action install the default latest (not necessarily “stable” if you later switch to a prerelease-aware workflow): - with: { version: "latest" } [2] Sources: [1] https://github.com/supabase/cli/releases [2] https://github.com/supabase/setup-cli/releases [3] https://github.com/supabase/setup-cli/blob/main/action.yml

Citations:


🏁 Script executed:

#!/bin/bash
# Verificar contexto do workflow: o que exatamente faz, e se há outros lugares com mesmo padrão
echo "== Contexto do workflow delete-orphan-edges.yml =="
head -n 20 .github/workflows/delete-orphan-edges.yml

echo
echo "== Ocorrências de `@v2` em todo o repo =="
rg '@v2' --type yaml

echo
echo "== Ocorrências de version: latest em workflows =="
rg 'version:\s*latest' --type yaml

Repository: adm01-debug/Promo_Gifts

Length of output: 1085


Pin a action e versão explícita da CLI para evitar regressões não-determinísticas no CI.

Em linha 58 e linha 60: @v2 e version: latest são refs flutuantes. Isso causa risco de breaking changes silenciosas quando a tag v2 aponta para um novo commit (sem seu controle) ou quando o binário CLI é atualizado.

O workflow executa com SUPABASE_ACCESS_TOKEN, logo uma regressão aqui pode deletar edge functions inesperadas. Use:

-        uses: supabase/setup-cli@v2
+        uses: supabase/setup-cli@<COMMIT_SHA_COMPLETO_DA_TAG_v2>
         with:
-          version: latest
+          version: 2.98.1

Resolva o SHA completo (40 chars) da tag v2 no repositório supabase/setup-cli via GitHub UI ou CLI (gh api repos/supabase/setup-cli/commits/v2), e substitua 2.98.1 pela versão atual do CLI desejada. Isso garante reprodutibilidade entre execuções e bloqueia supply-chain drift.

🤖 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/delete-orphan-edges.yml around lines 58 - 60, Substitua as
referências flutuantes supabase/setup-cli@v2 e o campo version: latest por
valores imutáveis: troque supabase/setup-cli@v2 pelo ref completo usando o
commit SHA (40 chars) da tag v2 do repo supabase/setup-cli e substitua version:
latest pelo número de versão CLI desejado (por exemplo 2.98.1) obtido do
release; isso garante que a step uses: supabase/setup-cli@<full-sha> e version:
<explicit-version> em vez de refs flutuantes.


Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/deploy-edge-functions.yml
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@ jobs:
- uses: actions/checkout@v4

- name: Setup Supabase CLI
uses: supabase/setup-cli@v1
uses: supabase/setup-cli@v2
with:
version: latest

Expand Down
Loading