Repository navigation
Record what the ggshield config does and does not reach - #31
Merged
Merged
Conversation
The file is read by the ggshield CLI, so it governs a local or manual `ggshield secret scan`. It does not configure the GitGuardian GitHub App, whose check on a pull request is scanned server-side with its exemptions held in the dashboard -- which is why the 2026-11-07 finding had to be resolved there while this file already existed here. Measured the same day: no workflow runs ggshield, across 429 workflow files in laranail/packages and simtabi/packages plus the 8 reusable workflows in laranail/.github. The entries therefore have no consumer in CI today, so a green GitGuardian check is not evidence that one of them applied. Correcting the key spelling was still right; the note stops the next reader mistaking the file for a CI-level control.
`plaintext-secret` sat in the group headed "still on KEY=value lines in the current tree, so these are the entries actually doing work". It is not in the tree at all -- #23 removed it -- and survives only in three commits of history, so it belonged in the second group. An exemption whose stated reason is wrong is a licence rather than a ceiling. Re-measured every entry while here. The other five are correctly placed: `plaintext` is at EncryptCliTest.php:11 and `oldsecret` at AuditTest.php:128, both still on assignment lines; `hunter2`, `newsecret` and `redaction-canary-not-a-secret` are in the tree but on no assignment line. Each line now names where its value actually is.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
.gitguardian.yamlis read by theggshieldCLI. It does not configure theGitGuardian GitHub App, whose
GitGuardian Security Checksrun on a pullrequest is scanned server-side with its exemptions held in the dashboard. That
is why the 2026-11-07 finding had to be resolved in the dashboard while this
file already existed in the repository.
Measured 2026-11-07: no workflow runs
ggshield— 429 workflow filesacross
laranail/packagesandsimtabi/packages, plus the 8 reusableworkflows in
laranail/.github, none referencing it. So the six entries haveno consumer in CI today.
Fixing the key spelling in #30 was still right — a wrong key is wrong wherever
something does read it — but the file as written implied a CI-level control it
does not provide. This records the scope so the next reader does not take a
green GitGuardian check as evidence that an entry here applied.
Comment-only; the YAML parses and
secretstill carries exactlyignored_matches,ignored_paths,show_secrets.Open question for the owner
Whether these files should gain a real CI consumer (a
ggshield secret scanstep) is an estate-wide decision — it needs a
GITGUARDIAN_API_KEYorg secret,which only you can create, and it duplicates what the App already reports. Not
proposed here.