|
| 1 | +# GitGuardian CI Workflow Design |
| 2 | + |
| 3 | +Date: 2026-06-11 |
| 4 | +Repository: `FrontAgent/FrontAgent` |
| 5 | +Base branch: `develop` |
| 6 | + |
| 7 | +## Goal |
| 8 | + |
| 9 | +Add an independent GitGuardian secret-scanning workflow that uses the repository secret |
| 10 | +`GITGUARDIAN_API_KEY` and follows the existing FrontAgent CI trigger pattern. |
| 11 | + |
| 12 | +## Context |
| 13 | + |
| 14 | +FrontAgent already runs CI, Contract Guard, and Repo Guard from `.github/workflows/`. |
| 15 | +Existing CI and Contract Guard target `develop`, so the GitGuardian workflow should use |
| 16 | +the same branch policy unless maintainers explicitly broaden the security coverage. |
| 17 | + |
| 18 | +GitGuardian's current GitHub Actions documentation recommends running ggshield from |
| 19 | +GitHub Actions, checking out full history with `fetch-depth: 0`, and passing |
| 20 | +`GITGUARDIAN_API_KEY` through the environment. |
| 21 | + |
| 22 | +## Selected Approach |
| 23 | + |
| 24 | +Create a standalone `.github/workflows/gitguardian.yml` workflow. |
| 25 | + |
| 26 | +This keeps secret scanning separate from Node quality checks and makes the |
| 27 | +`GitGuardian scan` status easy to add as a required check. The workflow should trigger |
| 28 | +on pushes to `develop` and pull requests targeting `develop`. |
| 29 | + |
| 30 | +## Workflow Behavior |
| 31 | + |
| 32 | +- Workflow name: `GitGuardian scan`. |
| 33 | +- Events: |
| 34 | + - `push` to `develop`. |
| 35 | + - `pull_request` targeting `develop`. |
| 36 | +- Permissions: `contents: read`. |
| 37 | +- Concurrency: |
| 38 | + - Group by PR number when available, otherwise by ref. |
| 39 | + - Cancel in-progress runs for pull request updates. |
| 40 | +- Job: |
| 41 | + - Runs on `ubuntu-latest`. |
| 42 | + - Checks out the repository with `actions/checkout@v6`. |
| 43 | + - Uses `fetch-depth: 0` so ggshield can scan the relevant commit range. |
| 44 | + - Runs `GitGuardian/ggshield/actions/secret@v1.51.0`. |
| 45 | + - Passes the official GitHub SHA environment variables plus |
| 46 | + `GITGUARDIAN_API_KEY: ${{ secrets.GITGUARDIAN_API_KEY }}`. |
| 47 | + |
| 48 | +## Error Handling |
| 49 | + |
| 50 | +The workflow should fail when GitGuardian detects exposed secrets or when the |
| 51 | +configured API key is missing/invalid. No local fallback or soft-fail behavior is |
| 52 | +included because this is a security gate. |
| 53 | + |
| 54 | +## Testing |
| 55 | + |
| 56 | +Local verification should include: |
| 57 | + |
| 58 | +- YAML structure inspection by reading the new workflow file. |
| 59 | +- `pnpm quality:precommit`, because `.github/workflows/` is a repo-harness critical |
| 60 | + skeleton path in `docs/knowledge-contract.md`. |
| 61 | +- `mcp__gitnexus.detect_changes` before final review to confirm the affected scope. |
| 62 | + |
| 63 | +## Out Of Scope |
| 64 | + |
| 65 | +- Adding a `.gitguardian.yaml` ignore policy. |
| 66 | +- Enabling GitGuardian full-history repository monitoring outside GitHub Actions. |
| 67 | +- Changing branch protection settings. |
| 68 | +- Modifying existing CI, Contract Guard, or Repo Guard behavior. |
0 commit comments