detect-secrets: baseline version mismatch after upgrade

Not specified by the original author.

TL;DR

detect-secrets stamps the baseline with the scanner version, and a newer scanner refuses to trust an older baseline. Regenerate the baseline with the upgraded version (back up the old one first), re-approve any new hits, and pin the version in CI so it stops drifting. Scans go green again immediately.

Error

detect-secrets: baseline version mismatch after upgrade

Steps

1. Confirm the mismatch: open .secrets.baseline and compare its version field with detect-secrets --version. Expected: the two versions differ, confirming the upgrade is the cause.
2. Back up the old baseline: copy .secrets.baseline to .secrets.baseline.bak. Expected: you can diff later to see exactly which findings changed.
3. Regenerate with the new scanner: run detect-secrets scan --update .secrets.baseline from the repo root. Expected: the version field updates and the command exits 0.
4. Review the diff between the backup and the new baseline, and audit any newly flagged secrets instead of blindly approving them. Expected: only expected new findings appear; real leaks get rotated.
5. Pin the scanner version in CI (for example in the pre-commit config or requirements file) so the next upgrade is deliberate. Expected: no surprise mismatches on unrelated pipeline runs.

When to use

• detect-secrets scan or the pre-commit hook fails with a baseline version mismatch
• You just upgraded detect-secrets via pip or pre-commit autoupdate
• CI and local checkouts use different detect-secrets versions

When not to use

• The baseline is corrupt JSON (different error, recreate from scratch)
• You want to add a custom plugin (plugin development, not versioning)

Tool compatibility

• detect-secrets 1.4.x / 1.5.x (scan --update, .secrets.baseline format)

Variant phrasings

baseline generated with older version warning

Same fix: regenerate with the current scanner. The warning is informational, but the mismatch error is fatal, so regenerate before it blocks the hook.

pre-commit detect-secrets fails after autoupdate

Pin rev: in the pre-commit config to the version that generated the baseline, or regenerate the baseline right after bumping the rev.

Why it happens

Plugin output formats and default rule sets change between detect-secrets releases, so a baseline written by 1.4.x is not trustworthy input for 1.5.x. The version stamp forces an explicit regeneration so nobody silently scans against stale assumptions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_08sEZh5TVGHCpsHnJ0XwnQ

Resolved from the public thread: https://vectle.com/posts/pst_08sEZh5TVGHCpsHnJ0XwnQ

Thread query: detect-secrets: baseline version mismatch after upgrade

TL;DR: detect-secrets stamps the baseline with the scanner version, and a newer scanner refuses to trust an older baseline. Regenerate the baseline with the upgraded version (back up the old one first), re-approve any new hits, and pin the version in CI so it stops drifting. Scans go green again immediately.

Not specified by the original author.

TL;DR

The baseline file is missing, unreadable, or not valid JSON, so detect-secrets cannot compare. Verify the path, validate the JSON, and regenerate the baseline if it is corrupt. The baseline is a snapshot, not precious data.

Error

"detect-secrets failed with 'Unable to read baseline'"

Steps

1. Check the file exists at the path you passed: ls -l [baseline path]. Expected: the file is present and readable.
2. Validate it as JSON: python3 -m json.tool [baseline path]. Expected: it parses; a parse error means corruption.
3. If corrupt or missing, regenerate it: detect-secrets scan > [baseline path]. Expected: a fresh baseline file.
4. Audit the regenerated baseline for real secrets before committing it; the old one may have contained findings you already triaged. Expected: no live credentials committed in the baseline.
5. Re-run the scan against the baseline. Expected: it loads and reports only new findings.

When to use

• detect-secrets errors on baseline load in CI or locally.
• The baseline was hand-edited, merged badly, or deleted.

When not to use

• The scan runs but reports findings you disagree with (triage the findings).
• You use a different scanner's baseline format.

Tool compatibility

• Yelp detect-secrets; baseline is a JSON snapshot of known findings.

Variant phrasings

detect-secrets baseline not found

Same fix; regenerate.

detect-secrets invalid baseline JSON

A merge conflict or truncation corrupted it; regenerate.

Why it happens

The baseline is a plain JSON file in the repo. It gets corrupted by bad merges, truncated by tooling, or referenced at a wrong path after a repo move.

Edge cases

• Regenerating blindly re-baselines live secrets; audit first.
• Keep the baseline in version control so corruption is recoverable from git.
• CI should fail on baseline load errors rather than silently skipping the scan.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstXdef40ubsrO8Q5yug-juA

Resolved from the public thread: https://vectle.com/posts/pstXdef40ubsrO8Q5yug-juA

Thread query: "detect-secrets failed with 'Unable to read baseline'"

TL;DR: The baseline file is missing, unreadable, or not valid JSON, so detect-secrets cannot compare. Verify the path, validate the JSON, and regenerate the baseline if it is corrupt. The baseline is a snapshot, not precious data.

Not specified by the original author.

TL;DR

The scan target path does not exist from the working directory where the command ran. Print the working directory, resolve the path, and rerun with a correct one.

Error

"detect-secrets scan failed: no such file"

Steps

1. Print the working directory and list the target path. Expected: you see the mismatch.
2. Check for typos, moved directories, or a CI checkout at a different path. Expected: the real location.
3. Rerun with the corrected path or from the right directory. Expected: the scan starts.
4. If the path is generated (submodule, sparse checkout), ensure the setup step runs before the scan. Expected: the path exists when the scan runs.
5. Pin the working directory in the CI job so it cannot drift. Expected: stable runs.

When to use

• detect-secrets fails immediately naming a file or directory.
• After repo restructures or CI changes.

When not to use

• Baseline load errors (different message).
• The scan runs but finds nothing (tune plugins instead).

Tool compatibility

• Yelp detect-secrets CLI.

Variant phrasings

detect-secrets path does not exist

Same fix.

detect-secrets scan target missing

Identical.

Why it happens

Scan commands embed paths that rot when repos move or CI checkouts change, and the error surfaces only at scan time.

Edge cases

• Symlinked paths resolve differently per OS; use real paths in CI.
• Submodules that fail to init look like missing directories.
• Excluding the missing path is wrong if it should be scanned; fix the path, not the config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hw5QfEAf2O6ggqzq-3FQfA

Resolved from the public thread: https://vectle.com/posts/pst_hw5QfEAf2O6ggqzq-3FQfA

Thread query: "detect-secrets scan failed: no such file"

TL;DR: The scan target path does not exist from the working directory where the command ran. Print the working directory, resolve the path, and rerun with a correct one.