Stop excluding the trufflehog postgres detector

[albertvillanova]

This PR re-enables the postgres detector in the secret scanning workflow.

Reverts the exclusion added in #3192.

Motivation

The exclusion is the oldest thing in this workflow, added in March 2025 with the comment "exclude buggy postgres detector that is causing false positives and not relevant to our codebase". It was adapted from the text-generation-inference workflow rather than diagnosed here, so unlike the lob exclusion there is no record of a specific false positive that it was suppressing in this repository, and no way to check whether the upstream bug that motivated it still exists.

Since then the scanner has moved from an unpinned main to v3.97.0. Rather than keep carrying an exclusion whose justification cannot be reconstructed, this checks whether it is still needed.

Solution

Scanning the full history of main with the currently pinned scanner and no exclusions at all reports nothing:

docker run --rm -v .:/repo ghcr.io/trufflesecurity/trufflehog:3.97.0@sha256:ff4c95e9... \
  git file:///repo --results=verified,unknown --fail-on-scan-errors

chunks: 34856, bytes: 23333266, verified_secrets: 0, unverified_secrets: 0  -> exit 0

That is 3426 commits, the same scope as our weekly full-history sweep, so the detector finds nothing to report anywhere in the repository, not just in the current tree. The harness was sanity-checked against a synthetic secret that the scanner does report, so the clean result reflects detectors running and finding nothing rather than a scan that covered nothing.

This is weaker evidence than for lob, where the upstream fix can be pointed at directly. Here the argument is only that the detector is currently silent across the whole history. If it turns out to produce false positives on some future commit, the exclusion can be restored with an actual example attached, which is a better state than an exclusion nobody can justify.

Changes

• Remove postgres from --exclude-detectors

Note

#6920 removes lob from the same list. The two touch the same line, so whichever merges second needs a rebase, and at that point --exclude-detectors becomes empty and should be dropped along with the comment introducing it.

---

Note

Low Risk
CI-only TruffleHog flag change with no app or auth impact; main risk is future postgres-detector false positives failing the workflow.

Overview
Re-enables the TruffleHog postgres secret detector in the GitHub Actions secret-leaks workflow by dropping --exclude-detectors=postgres from extra_args. Scanning still uses --results=verified,unknown and --fail-on-scan-errors on the pinned v3.97.0 image.

This reverses a long-standing exclusion that was copied from another project without a documented false positive in this repo. Full-history validation with the current pin reportedly finds no postgres hits, so the workflow now runs that detector again; if noise shows up later, the exclusion can be restored with a concrete example.

^{Reviewed by Cursor Bugbot for commit 949a4d2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[qgallouedec]

lgtm. checked on my side, nothing postgres-shaped anywhere on main (postgres://, :5432 both empty), so no risk today.

One thing: this and #6920 touch the same line, and once both land --exclude-detectors is empty with a dangling comment above it. It's probably easier to just fold them into a single PR that just drops the flag and the comment?

your call

[albertvillanova]

It was just a one-line Git conflict resolution.

Sorry, I was still sleepy when merging and forgot the comment. 🙏