docs: secret-scanning triage record + ggshield config (GitGuardian findings from #38) - #40
Conversation
GitGuardian went live on the org during PR #38 and flagged 3 findings there plus 14 from the historical scan — all verified as development defaults, required interpolations carrying no value, or published contract mock constants (the dokploy file history was audited end to end; no real credential has ever been committed). docs/secret-scanning.md is the auditable finding-by-finding record, the disposition (dashboard ignore as test/dev credential), and the standing policy: a finding outside this inventory is treated as a real leak — rotate first. .gitguardian.yaml excludes .env.example for ggshield CLI scans only; the GitHub App reads no in-repo config, so the noise reduction itself is dashboard-side.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
t0kubetsu has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 56 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Secret-scanning triage record + policy (GitGuardian findings from #38)
GitGuardian's first run on the org concluded
failureon #38 with 3 findings, on top of 14 historical-scan incidents. Every one was verified repo-side:docker-compose.dokploy.yml,infra/compose/api.yml,.env.examplenc3_authdev-default lines — the dokploy one is a${NC3_AUTH_DB_PASSWORD:?}interpolation carrying no value at all.env.exampledomains/*/examples.py, smoke suitedocker-compose.dokploy.ymlhistory audited end to end: no non-interpolated credential has ever existed in it. Real credentials live only in the Dokploy env tab / mounted secret files; GitHub push protection is enabled on all 12 org repos.What this PR adds
docs/secret-scanning.md— the auditable inventory + verdicts, the disposition (dashboard ignore as test/dev credential), and the standing policy: a GitGuardian finding not in this inventory is treated as a real leak (rotate first). Also records why the GG check stays non-required..gitguardian.yaml— ggshield (CLI) config excluding.env.example; explicitly documented as having no effect on the GitHub App.Remaining step (dashboard-side, not doable from the repo)
Mark the 17 incidents Ignored — test/dev credential in the GitGuardian workspace, referencing
docs/secret-scanning.md. The GitHub App reads no in-repo configuration.