Repository navigation
ci: fix failing Secrets Scan (gitleaks false positive on test fixture) - #85
Conversation
The Secrets Scan job has failed on every scheduled main run since the weekly cron was enabled, which is what turns the CI badge red. Gitleaks' generic-api-key rule fires on: internal/config/loader_test.go:65 cfg.Auth.SessionSecret = "f47ac10b58cc4372a5670e02b2c3d479" That value is the canonical RFC 4122 example UUID with hyphens stripped. TestWarnInsecureConfig_StrongSecret uses it purely to assert that a high-entropy session_secret does NOT emit an "INSECURE CONFIG" warning. It is not a live credential and never was. CI checks out with fetch-depth: 0, so gitleaks scans the full history and the finding is pinned to commit 063ffbe. Editing the file at HEAD would not clear it - an allowlist is the correct remedy. Adds .gitleaks.toml which extends the upstream default ruleset (nothing is weakened) and allowlists only that one literal string, scoped to the secret match itself via regexTarget. Verified locally with gitleaks 8.24.3, the exact version the action pins: before: leaks found: 1, exit 2 after: no leaks found, exit 0 Also confirmed the allowlist is not overly broad: planting a fake AWS key and GitHub PAT in internal/config/ still trips the scan with exit 2.
There was a problem hiding this comment.
Pull request overview
This PR aims to fix the failing scheduled CI “Secrets Scan” by adding a Gitleaks configuration that keeps the default ruleset while allowlisting a specific known test-fixture value that was flagged as a false positive in git history.
Changes:
- Adds a repo-level Gitleaks config extending the upstream default ruleset.
- Introduces a narrowly scoped allowlist entry intended to suppress one specific false-positive secret match from a historical commit.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #85 +/- ##
==========================================
- Coverage 80.10% 80.05% -0.06%
==========================================
Files 58 58
Lines 7686 7686
==========================================
- Hits 6157 6153 -4
- Misses 1188 1190 +2
- Partials 341 343 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
8d3af57 to
e659055
Compare
Second issue found & fixed: workflow had been auto-disabledWhile verifying, no CI ran on this PR at all. The cause: GitHub auto-disables scheduled workflows after 60 days of repo inactivity. So the badge was red for a compounding reason - the last recorded run was the failing one from 2026-07-13, and nothing has been able to run since. I re-enabled it via Verification: full pipeline greenRun 31891739377 on this branch: Once this merges to |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: pradithya <4023015+pradithya@users.noreply.github.com>
Problem
The CI/CD Pipeline badge on the README has been red since the weekly scheduled build was enabled — every
schedulerun onmainhas failed (checked back to 2026-05-11).The culprit is the Secrets Scan job, which fails in ~6s. All other jobs pass.
Root cause
Gitleaks'
generic-api-keyrule fires on a test fixture:That's the canonical RFC 4122 example UUID with the hyphens stripped.
TestWarnInsecureConfig_StrongSecretuses it purely to assert that a high-entropysession_secretdoes not emit anINSECURE CONFIGwarning. It is not a live credential and never was — no rotation needed.Because CI checks out with
fetch-depth: 0, gitleaks scans the entire history and the finding is pinned to commit063ffbeb. Editing the file at HEAD would not clear it; an allowlist is the correct remedy.Fix
Adds
.gitleaks.tomlthat:useDefault = true) — no rules are weakened or droppedregexTarget = "secret"Verification
Run locally with gitleaks 8.24.3, the exact version
gitleaks/gitleaks-action@v2pins:leaks found: 1no leaks foundConfirmed the allowlist is not overly broad — planting a fake AWS key (
AKIA...) and GitHub PAT (ghp_...) intointernal/config/still trips the scan with exit 2.Note (out of scope)
Two unrelated things surfaced while debugging, happy to file separately:
gitleaks/gitleaks-action@v2andactions/cache@v4emit Node 20 deprecation warnings.