chore: add Dependency Guard workflow (alpha)

[gvago]

Adds supply-chain security scanning via qodo-ai/dependency-guard.

Fires on PRs that change lockfiles. Posts a verdict comment (SAFE / WARNING / MALICIOUS).

Setup required: Add QODO_API_KEY secret in repo settings before merging.

Alpha — GitHub only, comment-only (no merge blocking yet).

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Add Dependency Guard workflow for supply-chain security

✨ Enhancement

Walkthroughs

Description

• Adds Dependency Guard workflow for supply-chain security scanning
• Triggers on lockfile changes across multiple package managers
• Posts verdict comments (SAFE/WARNING/MALICIOUS) on PRs
• Requires QODO_API_KEY secret configuration in repository

Diagram

flowchart LR
  PR["Pull Request with<br/>lockfile changes"]
  TRIGGER["Dependency Guard<br/>workflow triggered"]
  SCAN["Scan package<br/>artifacts"]
  VERDICT["Post verdict<br/>comment"]
  PR -- "on: paths" --> TRIGGER
  TRIGGER -- "checkout code" --> SCAN
  SCAN -- "QODO_API_KEY" --> VERDICT

Loading

File Changes

1. .github/workflows/dependency-guard.yml ✨ Enhancement +25/-0

New Dependency Guard security scanning workflow

• New GitHub Actions workflow for supply-chain security scanning
• Triggers on changes to lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt,
 poetry.lock, Pipfile.lock)
• Uses qodo-ai/dependency-guard@v1 action with QODO_API_KEY secret
• Configured with read contents and write pull-requests permissions

.github/workflows/dependency-guard.yml

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

1. Unpinned action versions ☑ 🐞 Bug ⛨ Security

Description

The workflow uses moving tags (actions/checkout@v4, qodo-ai/dependency-guard@v1), so the
executed CI code can change without review, creating a supply-chain risk and reducing
reproducibility.

Code

.github/workflows/dependency-guard.yml[R21-22]

+      - uses: actions/checkout@v4
+      - uses: qodo-ai/dependency-guard@v1

Evidence

The workflow references third-party actions by major-version tags, which are mutable and can be
retargeted to different commits over time. This contradicts the repo’s own security guidance to pin
versions for reproducible builds.

.github/workflows/dependency-guard.yml[21-22]
SECURITY.md[71-76]
Best Practice: GitHub Actions Security Hardening

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow uses mutable action tags (`@v4`, `@v1`). This allows the code executed in CI to change without review and weakens supply-chain security.
## Issue Context
This repo’s SECURITY.md recommends pinning versions for reproducible builds. GitHub Actions security guidance also recommends pinning actions to full commit SHAs.
## Fix Focus Areas
- .github/workflows/dependency-guard.yml[21-24]
## Suggested change
- Replace `actions/checkout@v4` with a pinned commit SHA for the desired release.
- Replace `qodo-ai/dependency-guard@v1` with a pinned commit SHA for the desired release.
- (Optional) Add comments indicating the intended version (e.g., `# v4.x.x`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Fork PRs lack secret ☑ 🐞 Bug ☼ Reliability

Description

This workflow runs on pull_request but unconditionally passes secrets.QODO_API_KEY; for PRs from
forks, the secret is not available, so the scan cannot authenticate and will not reliably post a
verdict comment.

Code

.github/workflows/dependency-guard.yml[R3-24]

+on:
+  pull_request:
+    paths:
+      - '**/package-lock.json'
+      - '**/yarn.lock'
+      - '**/pnpm-lock.yaml'
+      - '**/requirements.txt'
+      - '**/requirements*.txt'
+      - '**/poetry.lock'
+      - '**/Pipfile.lock'
+
+jobs:
+  scan:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: qodo-ai/dependency-guard@v1
+        with:
+          qodo-api-key: ${{ secrets.QODO_API_KEY }}

Evidence

The trigger is pull_request and the job always passes secrets.QODO_API_KEY to the action. GitHub
Actions does not provide repository secrets to workflows triggered by forked PRs, so this workflow
won’t function as described for external contributors.

.github/workflows/dependency-guard.yml[3-5]
.github/workflows/dependency-guard.yml[22-24]
Best Practice: GitHub Actions documentation

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow is triggered by `pull_request` and always attempts to run using `secrets.QODO_API_KEY`. On fork PRs, secrets are unavailable, so the workflow cannot authenticate and won’t deliver the intended SAFE/WARNING/MALICIOUS comment.
## Issue Context
If the goal is to cover open-source contributions, you need a safe fallback behavior for forks (skip with clear messaging), or a maintainer-triggered alternative.
## Fix Focus Areas
- .github/workflows/dependency-guard.yml[3-12]
- .github/workflows/dependency-guard.yml[20-24]
## Suggested change
Implement one of these patterns:
1) **Skip on forks / missing secret** (recommended for safety):
- Add a job/step `if: ${{ !github.event.pull_request.head.repo.fork && secrets.QODO_API_KEY != '' }}`.
- Add a fallback step that posts a neutral comment or step summary like "Dependency Guard skipped (fork PR / missing QODO_API_KEY)".
- Optionally add `continue-on-error: true` for alpha so it doesn’t create a failing check.
2) **Maintainer-triggered scan for forks**:
- Add `workflow_dispatch` with PR number input to allow maintainers to run the scan with secrets when needed.
Avoid switching to `pull_request_target` unless you are very careful to never execute untrusted PR code while secrets are available.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more