You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lint & Validate's "Scan Git history for secrets" step (scripts/secret-scan.sh, gitleaks v8.30.1) has been failing on PRs against main — currently seen on PR#62's runs. CI's own output is --redact=100 and prints only a count (leaks found: 7), with no per-finding detail and no report artifact uploaded, so the count alone doesn't tell you anything about real risk.
I reproduced the exact scan locally (fetched the same ephemeral refs/pull/62/merge commit GitHub Actions checked out, by SHA — d5d3ee40fed87159c4f6a8a35e6e264526c6e7e8 — since that ref itself is gone now that the PR is merged; confirmed an exact match: 432 commits scanned, 7 leaks) and read the actual findings from an unredacted report. This repo is public, so anything gitleaks flags here should be treated as already exposed to the internet, not just to internal collaborators — regardless of whether the specific value is still valid today.
Deliberately not including any secret material (even truncated) in this public issue — findings below are identified by rule/file/line/commit only. Maintainers with repo access can look up the actual historical content via git show <commit>:<file>.
Findings (7 total, 4 distinct incidents)
#
Rule
File
Line
Commit
Date
My read
1
github-fine-grained-pat
.env
15
979ba0c
2026-05-28
Real-shaped GitHub Fine-Grained PAT. Needs a live check: is this token still enabled in the account's PAT settings? If yes, revoke immediately — full repo access.
2
generic-api-key
.env
8
cced81d
2026-05-22
RAGBIO_API_KEY=..., 64 hex chars. Same env var name still referenced live in docker-compose.yml's rag service build args today. Needs a live check: is the currently-configured RAGBIO_API_KEY the same value? If so, it's the same key as this leaked one and should be rotated.
Same token committed to both files (identical match). Decoded payload: token_type=refresh, user_id=10, HS256, iat≈2026-05-24, exp≈2026-05-25 (~24h lifetime). Already expired as of today (2026-08-27) — low exploitation risk for the token itself. Still worth fixing: (a) a real, working refresh token for a real user was hardcoded into two compose files rather than generated/injected at runtime, (b) it reveals the JWT's exact claim shape and alg choice, which is free reconnaissance for anyone targeting the auth service regardless of this specific token's validity.
5–7
curl-auth-user
DEPLOYMENT.md
232, 317, 320
975460f
2026-05-22
curl -u admin:omnibioai — reads as the Grafana admin basic-auth example in the deploy runbook, password omnibioai. If that's still the actual default/documented Grafana admin password in this deployment, it's a weak, guessable, publicly-documented credential — the kind of thing credential-stuffing bots try first. Needs a live check: has this been rotated per-deployment, or is admin:omnibioai still the real default?
Why I'm not assigning a severity label
Real severity here depends entirely on live-system checks I didn't do and shouldn't do unilaterally (querying/testing whether the PAT and API key are still active is itself a sensitive action against live credentials). Rough read: #1 and #2 are the ones that matter most if the underlying credentials were never rotated — please verify and rotate if so. #3/#4 (JWT) is already expired, lower urgency, more a "stop hardcoding real tokens into compose files" hygiene fix. #5–7 (Grafana default) matters only if that password is still live and Grafana is reachable beyond a trusted network.
Decide whether the flagged history itself needs remediation (e.g. .gitleaksignore entries with justification once each secret's live status is confirmed rotated/dead, or a git filter-repo history rewrite if the exposure is judged serious enough to warrant it) — either way this should be a deliberate decision, not something done as a side effect of an unrelated PR.
Once resolved, Lint & Validate on open/future PRs should go green again — right now this same check is red on main itself too, unrelated to any specific PR.
How I got the data
.env is in .gitignore (3 entries) and untracked today — these are stale, already-remediated-going-forward entries in history, not currently-committed files. Repro: fetch the exact merge-preview commit by SHA (git fetch origin <sha> still works even after the refs/pull/N/merge ref itself is deleted), then gitleaks git --redact=0 --report-format json --report-path <out> <repo> against that checkout.
Summary
Lint & Validate's "Scan Git history for secrets" step (scripts/secret-scan.sh, gitleaks v8.30.1) has been failing on PRs againstmain— currently seen on PR#62's runs. CI's own output is--redact=100and prints only a count (leaks found: 7), with no per-finding detail and no report artifact uploaded, so the count alone doesn't tell you anything about real risk.I reproduced the exact scan locally (fetched the same ephemeral
refs/pull/62/mergecommit GitHub Actions checked out, by SHA —d5d3ee40fed87159c4f6a8a35e6e264526c6e7e8— since that ref itself is gone now that the PR is merged; confirmed an exact match: 432 commits scanned, 7 leaks) and read the actual findings from an unredacted report. This repo is public, so anything gitleaks flags here should be treated as already exposed to the internet, not just to internal collaborators — regardless of whether the specific value is still valid today.Deliberately not including any secret material (even truncated) in this public issue — findings below are identified by rule/file/line/commit only. Maintainers with repo access can look up the actual historical content via
git show <commit>:<file>.Findings (7 total, 4 distinct incidents)
github-fine-grained-pat.env979ba0cgeneric-api-key.envcced81dRAGBIO_API_KEY=..., 64 hex chars. Same env var name still referenced live indocker-compose.yml'sragservice build args today. Needs a live check: is the currently-configuredRAGBIO_API_KEYthe same value? If so, it's the same key as this leaked one and should be rotated.jwtdocker-compose.yml:232,docker-compose.release.yml:2139812268,11c868ftoken_type=refresh,user_id=10, HS256,iat≈2026-05-24,exp≈2026-05-25 (~24h lifetime). Already expired as of today (2026-08-27) — low exploitation risk for the token itself. Still worth fixing: (a) a real, working refresh token for a real user was hardcoded into two compose files rather than generated/injected at runtime, (b) it reveals the JWT's exact claim shape and alg choice, which is free reconnaissance for anyone targeting the auth service regardless of this specific token's validity.curl-auth-userDEPLOYMENT.md975460fcurl -u admin:omnibioai— reads as the Grafana admin basic-auth example in the deploy runbook, passwordomnibioai. If that's still the actual default/documented Grafana admin password in this deployment, it's a weak, guessable, publicly-documented credential — the kind of thing credential-stuffing bots try first. Needs a live check: has this been rotated per-deployment, or isadmin:omnibioaistill the real default?Why I'm not assigning a severity label
Real severity here depends entirely on live-system checks I didn't do and shouldn't do unilaterally (querying/testing whether the PAT and API key are still active is itself a sensitive action against live credentials). Rough read: #1 and #2 are the ones that matter most if the underlying credentials were never rotated — please verify and rotate if so. #3/#4 (JWT) is already expired, lower urgency, more a "stop hardcoding real tokens into compose files" hygiene fix. #5–7 (Grafana default) matters only if that password is still live and Grafana is reachable beyond a trusted network.
Suggested next steps
RAGBIO_API_KEY(finding Electron AppImage: verify portable IPC handlers work on clean machine #2) if either is still active — treat as compromised given the repo is public.omnibioaiin any live deployment; rotate if so..gitleaksignoreentries with justification once each secret's live status is confirmed rotated/dead, or agit filter-repohistory rewrite if the exposure is judged serious enough to warrant it) — either way this should be a deliberate decision, not something done as a side effect of an unrelated PR.Lint & Validateon open/future PRs should go green again — right now this same check is red onmainitself too, unrelated to any specific PR.How I got the data
.envis in.gitignore(3 entries) and untracked today — these are stale, already-remediated-going-forward entries in history, not currently-committed files. Repro: fetch the exact merge-preview commit by SHA (git fetch origin <sha>still works even after therefs/pull/N/mergeref itself is deleted), thengitleaks git --redact=0 --report-format json --report-path <out> <repo>against that checkout.