Targeted Secret Scanning Workflow And Detection Coverage

Issue 95 Edition 2026-04-05 5 min read

General

Sources: 1 • Confidence: High • Updated: 2026-04-12 10:01

Key takeaways

scan-for-secrets is a Python tool that takes provided secrets and scans a specified directory for them.
A tool named scan-for-secrets version 0.1 has been released.
The author publishes transcripts of local Claude Code sessions using the claude-code-transcripts tool and is concerned that secrets such as API keys could appear in those logs.
Users can define a recurring set of secrets to protect by listing commands that output those secrets in a ~/.scan-for-secrets.conf.sh file.
scan-for-secrets scans not only for literal secrets but also for common encodings such as backslash-escaped or JSON-escaped forms.

scan-for-secrets is a Python tool that takes provided secrets and scans a specified directory for them.
scan-for-secrets scans not only for literal secrets but also for common encodings such as backslash-escaped or JSON-escaped forms.
If the -d option is omitted, scan-for-secrets defaults to scanning the current directory.

A tool named scan-for-secrets version 0.1 has been released.
The author built scan-for-secrets using README-driven development, specifying behavior in the README and having Claude Code implement it using red-green TDD.

The author publishes transcripts of local Claude Code sessions using the claude-code-transcripts tool and is concerned that secrets such as API keys could appear in those logs.

Users can define a recurring set of secrets to protect by listing commands that output those secrets in a ~/.scan-for-secrets.conf.sh file.

What interfaces exist for supplying secrets to scan-for-secrets (CLI flags, stdin, environment variables), and what are the exact expected formats?
Which encodings beyond backslash-escaped and JSON-escaped are supported, and is the behavior formally specified by tests?
What are the tool’s expected performance characteristics and file-handling behavior (large repositories, binary files, symlinks, excluded paths)?
What is the false-positive/false-negative profile when scanning typical transcripts/logs, and are there recommended thresholds or workflows for triage?
How is ~/.scan-for-secrets.conf.sh intended to be secured, and what guidance exists to prevent the config mechanism from becoming a new secret-leak vector?

Rising need for pre-publication controls for AI coding transcripts and other logs, with targeted secret matching as a practical workflow to reduce accidental key exposure.
Opportunity for developer workflow tools to add targeted secret scan steps alongside linting and tests, especially for artifacts like transcripts and generated JSON where escaping can hide leaks.
Increased attention to operational security of local developer automation, since shell-based secret enumeration can streamline scans but also introduces new handling and storage risks.

Evidence of adoption such as recurring use in publish pipelines for transcripts, CI usage examples, or community reports that it prevented real leaks in logs or transcripts.
Expanded, test-backed documentation of supported encodings and file handling, indicating reliability beyond literal matching and demonstrating a maintained detection surface.
Guidance and tooling around securing the config mechanism, such as clear practices for protecting the shell config and avoiding it becoming a new leak vector.

Reports of high false positives or false negatives when scanning typical transcripts and logs, making triage burdensome or undermining trust in the workflow.
Performance or file handling limitations in large repositories, binaries, symlinks, or excluded paths that block practical integration into real projects.
Security concerns that the shell-configured command approach commonly exposes secrets itself, leading users to avoid the workflow or creating new incidents.