I've seen it happen too many times. A developer copies a log into Slack to ask for help debugging. Hidden in that log is an API key. Now that secret is sitting in a chat history, indexed, searchable, and potentially compromised.
This is why I built LogShield.
The Problem
Logs are everywhere. They flow through CI/CD pipelines, get attached to bug reports, shared in chat tools, and increasingly fed into AI assistants for analysis. Every one of these is a potential leak vector.
Most teams know this is a problem. But the solutions available today fall into two camps:
- Enterprise DLP systems - expensive, complex, and designed for compliance rather than developer workflows.
- Regex scripts - brittle, inconsistent, and never quite catch everything.
Neither works for the average DevOps engineer who just wants to safely share a log.
Why Determinism Matters
The first principle of LogShield is determinism. The same input always produces the same output.
This sounds obvious, but it's surprisingly rare. Many tools use probabilistic detection, entropy analysis, or machine learning to identify secrets. These approaches have a fundamental problem: they're unpredictable.
When you run a probabilistic tool twice on the same input, you might get different results. That makes them unsuitable for:
- CI/CD pipelines (where reproducibility is essential)
- Audit trails (where you need to prove what was redacted)
- Diff-based workflows (where spurious changes create noise)
LogShield uses explicit, rule-based detection. If a pattern matches, it gets redacted. If it doesn't, it doesn't. Every time.
Treating False Positives as a Failure Mode
The second principle is even more important: zero false positives.
A false positive in log sanitization means losing debugging context. Order IDs, transaction hashes, request identifiers - these look like secrets but aren't. If your tool redacts them, you've made the log useless.
LogShield is intentionally conservative. When there's ambiguity, it prefers not to redact. This is a deliberate trade-off:
- Missing a secret = you can fix it by adding a rule.
- Redacting non-secrets = you've destroyed information that can never be recovered.
What LogShield Does Not Do
I'm equally proud of what LogShield doesn't do:
- No cloud service or hosted mode
- No AI or probabilistic detection
- No telemetry or data collection
- No learning or adaptation
These aren't limitations - they're features. LogShield is designed to be boring, predictable, and trustworthy.
Try It
npm install -g logshield-cli
cat your.log | logshield scanThat's it. No signup, no config files, no API keys. Just pipe in a log and get a safe output.
If you find LogShield useful, consider starring it on GitHub. And if you have feedback, I'd love to hear it.