🐛 New check: Secret scanning #4878
Open
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.
What kind of change does this PR introduce?
New check
PR title follows the guidelines defined in our pull request documentation
Tests for the changes have been added (for bug fixes/features)
Which issue(s) this PR fixes
#30
Special notes for your reviewer
This PR adds a new check for secret scanning. A project will score a high score if they have secret scanning and it runs it. The check covers multiple different ways of scanning for secrets:
3.1 gitleaks
3.2 TruffleHog
3.3 detect-secrets
3.4 git-secrets
3.5 ggshield
3.6 sshgit
3.7 repo-supervisor
Of these tools, the Scorecard Secret-Scanning check will both check if the project has either of these workflows - which will give the project a 1 score - and also whether the tools run. The first 5 tools are supposed to run on commits, and the last 2 run periodically. If they also run, the project will score another 7 points. Currently, the motivation to not score 10 in this case is that projects should enable Native GitHub scanning.
This can be tested out with
go run main.go --checks=SecretScanning --repo=github.com/owner/repo. Try for example to enable and disable native GitHub secret scanning in your own repository and see the project score 0 when secret scanning is disabled and 10 when it is enabled.In addition, try to run it on projects with some of the CI tools enabled or use my test repositories - each should score 1 for simply having the workflow and not having native GitHub secret scanning:
Currently, details like the scores are merely suggestions as a starting point for getting these formalized. Modifying them won't be a bit challenge, so if a project should score 3 for having a CI workflow without running it, that is fine.
Does this PR introduce a user-facing change?
Yes