scan4secrets is a Python SAST-plus-DAST scanner that finds leaked credentials across source trees, running web apps, and CI logs, built for authorized assessments and defensive auditing.
| Tool | m14r41/scan4secrets — combined SAST/DAST secret scanner with live vendor verification and a vulnerability/misconfiguration engine |
| Category | Secret detection and static/dynamic application security testing |
| Primary Use | Auditing your own source trees, staging applications, and CI output for leaked API keys, plus code vulnerabilities, before attackers find them |
| Safe Use | Educational and documentary analysis for authorized professionals: run it only against codebases and applications you own or are contractually permitted to test |
| Telemetry Note | --verify sends one HTTP request per detected token to the vendor's own API, which can surface in provider audit logs — a useful defensive signal that a leaked credential is being triaged |
scan4secrets positions itself as a hybrid instrument in a space dominated by single-mode tools. Where gitleaks, trufflehog, and detect-secrets excel at static secret detection over git history, the README argues they stop at the repository boundary — they do not crawl a running application, do not parse JavaScript source maps, and do not perform code-level vulnerability analysis. scan4secrets stacks all three capabilities into a single Python CLI: static analysis of a local tree with --path, dynamic crawling of a live target with --url, and a misconfiguration engine toggled by --misconfig. The framing is explicit that this is a complement to gitleaks, not a replacement — pre-commit SAST in one pipeline slot, live DAST against staging in another.
The rule inventory is unusually large for a personal project: 416 rules total, split into 193 secret rules and 223 vulnerability/misconfiguration rules. The secret coverage reads like a map of the modern SaaS ecosystem — cloud providers (AWS, GCP, Azure, Hetzner, Fly.io), payments (Stripe, Adyen, Razorpay), messaging (Slack across five token types, Discord, Twilio, Telegram), AI vendors (OpenAI, Anthropic, Groq, Pinecone), and infrastructure plumbing from HashiCorp Vault to Tailscale. Rules are declared in a YAML schema rather than TOML, which the comparison table presents as an ergonomic advantage for teams writing custom detections.
What stands out technically is the context-aware detection layer. Beyond line-by-line regex matching, a whole-file pass catches secrets that line scanners structurally miss: values nested inside XML tags, split <key>/<value> pairs, multi-line YAML and properties files, and Base64-encoded credentials. More interesting is the fix for a classic entropy-gate blind spot — assignments with credential-bearing names like AM_CLIENT_SECRET=… are flagged on the name signal alone, with no entropy floor, so low-entropy but genuinely live secrets no longer fall through. That is the kind of design decision that separates scanners that produce evidence from scanners that produce noise.
The --misconfig engine is where the tool drifts from pure secret scanning into lightweight SAST. The README lists coverage across injection classes (SQLi, NoSQL, OS command, SSTI, XXE, deserialization, LFI/path traversal, LDAP/XPath, SSRF, open redirect), web-layer misconfigurations (CORS, CSRF-disabled, prototype pollution, XSS across eleven templating engines including EJS, Jinja, Pug, and React), crypto weaknesses (DES, RC4, ECB, static-IV, weak-RSA), JWT flaws like alg:none and hardcoded signing secrets, and IaC misconfigurations across Terraform, Kubernetes, Dockerfile, and GitHub Actions. Each finding is claimed to carry a structured record — severity, file:line evidence, vulnerable and secure code samples, remediation, and CWE plus OWASP Top-10 mapping — with taint and context gating applied to suppress false positives. Language support spans Python, Node, TypeScript, PHP, Ruby, Go, Java, Kotlin, and .NET, plus config dialects.
Live verification is the feature most relevant to incident-grade triage. With --verify, each detected token triggers exactly one HTTP request against the vendor's own API — a GitHub PAT against GET /user on api.github.com, a Slack bot token against auth.test, a Stripe live key against a one-record charges listing — and success is judged by a 200 response. Every finding then carries verified=true|false|null in all output formats. The README's phrasing is operationally precise: a verified token is evidence, an unverified one is a hypothesis. For defenders, note the double edge — those verification probes appear in the vendor's audit logs, which is itself a detection signal if someone else is verifying your leaked key.
The DAST crawler is the most aggressive subsystem and the one that demands strict authorization discipline. By default every --url run seeds 1,279 sensitive paths — .env, .git/config, wp-config.php, backup.zip, admin panels, source maps — organized into stack-specific wordlists like wordpress, env, Node.js-Express-JS, and Docker-Compose-Kubernetes. The crawler honors same-eTLD+1 scope by default with --strict-host for tighter containment, runs concurrently under --threads (default 16), parses .js.map files to scan the original sources embedded in production source maps, extracts string-literal endpoints from bundled JavaScript, and scans response headers as well as bodies. Mitigating controls exist — --max-urls and --max-depth caps prevent accidental denial of service — but the default-on path guessing means an operator should never point this at infrastructure they lack written permission to test.
Authenticated crawling is supported with --cookie and --header injection, and traffic can be routed through --proxy at http://127.0.0.1:8080-style endpoints, making it drop-in compatible with Burp and ZAP workflows. That integration point matters for assessment teams: the crawler becomes a discovery feed for a manual proxy session rather than a replacement for human analysis, and the README's quick-start examples consistently reference staging or example targets rather than third-party production systems.
Reporting is where scan4secrets shows CI-native ambitions. Output formats include SARIF for GitHub Code Scanning, GitLab Security Dashboard, and Defect Dojo; jsonl for SIEM/SOAR pipelines such as Splunk and Sentinel; csv for triage spreadsheets; excel for executive summaries; pdf for compliance packets; and a self-contained html report with expandable finding cards, filtering, and sorting. A policy gate via --fail-on high exits non-zero on high-severity findings, turning the tool into a CI blocking step. One caution worth flagging: secrets are rendered in full by default for paste-ready evidence, and --mask must be passed explicitly to redact them for screenshots or shared transcripts — an easy hygiene slip in report handling.
Installation is straightforward and non-weaponized: git clone https://github.com/m14r41/scan4secrets followed by pip install -e ., or pipx install git+https://github.com/m14r41/scan4secrets, or a Docker run from ghcr.io/m14r41/scan4secrets:latest. The repo sits at 119 stars, MIT-licensed, Python, with topics including sast, secrets, and codereview — an early-stage but actively documented project.
For a defensive workflow, the sensible deployment is a three-layer one: scan4secrets --path . --fail-on high --report sarif as a CI gate on every merge; --misconfig-only runs in code review to catch JWT and crypto flaws before they ship; and periodic authenticated DAST against owned staging environments to catch what escaped the pipeline — exposed .env files, leaked source maps, secrets in headers. The comparison table's honest acknowledgment of what gitleaks still does better for git history is a good sign of a maintainer who understands tool boundaries. Treat verification results as incident evidence, keep reports masked when shared, and remember the audit-log footprint of every --verify probe.
The residual risks are typical of young, broad-coverage tools: a 416-rule corpus will produce false positives the taint gating cannot fully suppress, verification probes send real credentials over the wire and should only run from controlled egress, and the DAST wordlist defaults assume you truly own the target scope. Used within those constraints, scan4secrets is a credible single-binary consolidation of three audit tasks that usually require a toolchain.
m14r41/scan4secrets.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.