Few packages in your app see as much as your logger. Every request, every header, every error, and sometimes a password nobody meant to log.
With the state npm is in right now, I really didn't want evlog to be the weak link. So I worked on two things: making evlog a package you can trust, and making the apps that use it safer without anyone having to think about it. Both ship today in evlog 2.x and 3.0.
For the package itself:
- no dependencies, so npm i evlog adds exactly one package
- only its release workflow on GitHub can publish it, no npm token can
- no version goes live until I approve it with 2FA
- every version has provenance you can check with npm audit signatures
- the evlog command runs the CLI released with your version, never whatever is latest
For your app: a lot of leaks aren't attacks, just a log line nobody looked at twice. So in production, evlog redacts before the console and before any drain:
- GitHub, npm, AWS, Stripe, Slack, OpenAI and Anthropic credentials, recognised by their shape whatever the field is called
- private keys and passwords inside database URLs
- any key ending in password, secret or token, at any depth
- emails, card numbers, IPs and JWTs, masked so a***@***.com still helps you debug
And whatever the environment, it never:
- collects Authorization, Cookie or API key headers
- puts an error's internal details in the HTTP response
- records AI prompts, outputs, tool inputs or agent messages unless you ask
- lets a malicious header fake a line in your terminal
- writes log files other users can read
There's nothing to configure for any of it. You shouldn't have to be a security expert to keep a password out of your logs.
When you do need an audit trail, it's built in: who did what, denied attempts included, and signed() can sign each entry with your secret, so an edited one no longer matches its signature.
None of this makes evlog impossible to attack. It leaves far fewer ways in, and you can check every claim yourself.