Investigate and implement secret scanning for commits and CI #748

New issue

Open

opened 2026-06-12 10:45:00 -05:00 by Codex · 0 comments

Codex commented

2026-06-12 10:45:00 -05:00

Member

Forgejo has an upstream feature request for native commit secret scanning, but it is still an open feature request rather than something this repository can depend on today: https://codeberg.org/forgejo/forgejo/issues/3721

We should investigate practical options that work with our current Forgejo Actions setup, choose one, and implement it.

Scope

Investigate secret-scanning options that can run in this repository today.
Include at least:
- Forgejo upstream/native secret-scanning status: https://codeberg.org/forgejo/forgejo/issues/3721
- TruffleHog: https://github.com/trufflesecurity/trufflehog
- Betterleaks: https://github.com/betterleaks/betterleaks
Compare CI integration effort, scan coverage, false-positive handling, maintenance cost, output quality, licensing, and whether the tool can scan both git history/diffs and filesystem content.
Pick one tool for the first implementation.
Add a Forgejo Actions workflow or extend an existing workflow to run the selected scanner.
Add any required scanner configuration, ignore file, or documented allowlist mechanism.
Ensure findings fail CI clearly without printing raw secrets in logs.
Keep the first implementation focused on repository code and CI. Full Forgejo-native push rejection can remain a future enhancement unless it is already available and practical.

Acceptance Criteria

The investigation result is recorded in the issue or implementation PR with a clear recommendation and rationale.
The chosen scanner runs in Forgejo Actions on pull requests and pushes to protected/default branches.
The scanner checks the repository content and/or git diff in a way that catches newly introduced secrets.
CI fails when a high-confidence secret is detected.
CI output identifies the finding location well enough to fix it while avoiding raw secret disclosure.
Known safe examples, placeholders, fixtures, or generated files can be allowlisted without disabling the scanner globally.
The implementation does not require paid third-party services.
The workflow is reproducible for local/manual runs where practical.
Existing workflows continue to run normally.
The final implementation documents why the selected tool was chosen over the other investigated options.

Test Coverage Required

Run the secret scanner against the current repository and confirm the baseline is clean or that any findings are triaged before enabling CI failure.
Add or document a safe synthetic test case, fixture, or dry-run command proving the scanner fails on an obvious fake secret without exposing real credentials.
Run the affected Forgejo Actions workflow locally or through CI if available.
Run existing focused CI checks touched by the workflow change.
If PHP files are changed, run vendor/bin/pint --dirty --format agent.

Progress Checklist

Review Forgejo upstream secret-scanning status and confirm whether native support is usable now.
Evaluate TruffleHog for Forgejo Actions usage, output quality, verification behavior, configuration, and maintenance fit.
Evaluate Betterleaks for Forgejo Actions usage, output quality, configuration, and maintenance fit.
Decide which scanner to implement first.
Add the scanner workflow/configuration.
Add allowlist or ignore handling for safe known examples.
Confirm CI fails on a safe synthetic secret test.
Confirm the current repository baseline is clean or triaged.
Document the selected tool and why it was chosen.

The repository should have an automated secret-scanning solution so accidentally committed credentials, API tokens, private keys, and similar sensitive values are caught before they reach protected branches. Forgejo has an upstream feature request for native commit secret scanning, but it is still an open feature request rather than something this repository can depend on today: https://codeberg.org/forgejo/forgejo/issues/3721 We should investigate practical options that work with our current Forgejo Actions setup, choose one, and implement it. ## Scope - Investigate secret-scanning options that can run in this repository today. - Include at least: - Forgejo upstream/native secret-scanning status: https://codeberg.org/forgejo/forgejo/issues/3721 - TruffleHog: https://github.com/trufflesecurity/trufflehog - Betterleaks: https://github.com/betterleaks/betterleaks - Compare CI integration effort, scan coverage, false-positive handling, maintenance cost, output quality, licensing, and whether the tool can scan both git history/diffs and filesystem content. - Pick one tool for the first implementation. - Add a Forgejo Actions workflow or extend an existing workflow to run the selected scanner. - Add any required scanner configuration, ignore file, or documented allowlist mechanism. - Ensure findings fail CI clearly without printing raw secrets in logs. - Keep the first implementation focused on repository code and CI. Full Forgejo-native push rejection can remain a future enhancement unless it is already available and practical. ## Acceptance Criteria - The investigation result is recorded in the issue or implementation PR with a clear recommendation and rationale. - The chosen scanner runs in Forgejo Actions on pull requests and pushes to protected/default branches. - The scanner checks the repository content and/or git diff in a way that catches newly introduced secrets. - CI fails when a high-confidence secret is detected. - CI output identifies the finding location well enough to fix it while avoiding raw secret disclosure. - Known safe examples, placeholders, fixtures, or generated files can be allowlisted without disabling the scanner globally. - The implementation does not require paid third-party services. - The workflow is reproducible for local/manual runs where practical. - Existing workflows continue to run normally. - The final implementation documents why the selected tool was chosen over the other investigated options. ## Test Coverage Required - Run the secret scanner against the current repository and confirm the baseline is clean or that any findings are triaged before enabling CI failure. - Add or document a safe synthetic test case, fixture, or dry-run command proving the scanner fails on an obvious fake secret without exposing real credentials. - Run the affected Forgejo Actions workflow locally or through CI if available. - Run existing focused CI checks touched by the workflow change. - If PHP files are changed, run `vendor/bin/pint --dirty --format agent`. ## Progress Checklist - [ ] Review Forgejo upstream secret-scanning status and confirm whether native support is usable now. - [ ] Evaluate TruffleHog for Forgejo Actions usage, output quality, verification behavior, configuration, and maintenance fit. - [ ] Evaluate Betterleaks for Forgejo Actions usage, output quality, configuration, and maintenance fit. - [ ] Decide which scanner to implement first. - [ ] Add the scanner workflow/configuration. - [ ] Add allowlist or ignore handling for safe known examples. - [ ] Confirm CI fails on a safe synthetic secret test. - [ ] Confirm the current repository baseline is clean or triaged. - [ ] Document the selected tool and why it was chosen.

Codex added the

labels

2026-06-12 10:45:07 -05:00