secrets management
8 articles with this tag
Stop secrets before they commit with gitleaks: catch API-key leaks before the push
Secrets can't be 'deleted after they leak.' Once committed, a secret stays in Git history, and once pushed it must be treated as leaked — the key needs revoking/rotating. gitleaks is a free tool that scans the whole repo and commit history with regex/entropy to find API keys, private keys, and tokens. The core of the defense is two gates: a pre-commit hook that stops it locally before the push, and CI/cron that catches what slips through. .gitignore only prevents new tracking — it can't detect, so you still need a scanner.
Security inventory — 7 checks people running several servers overlook
For solo/small operators, incidents come less from missing controls than from untracked state. The boundary is the PC holding your keys. Tier 2FA by root of trust, matrix your SSH keys to kill duplicates/unused/orphans, remove plaintext passwords from the cloud, remediate reversibly one at a time, and keep secrets out of the ledger. Inventory before adding tools.
Is storing your passwords in Google Drive safe? How to keep them properly
Keeping passwords in a plaintext Google Doc/Sheet is dangerous: one Google account becomes the single point of failure for every password — account takeover, a rogue connected app, or phishing leaks them all at once. The fix is a dedicated password manager (contents stay encrypted even when synced). If you must use Drive, store only an encrypted vault file and put phishing-resistant MFA on the account.
Are password managers safe? How they work, cloud vs local, and how to choose
A password manager is safer than reuse or plaintext storage. The key is zero-knowledge encryption: your master password decrypts the vault only on your device, the provider holds only ciphertext, so a provider breach doesn't expose your passwords. The real single point is your master password plus vault MFA. Choose cloud (Bitwarden/1Password) or local (KeePass) by use.
The security baseline for indie devs and small operators: the whole standard set
The baseline isn't 'all equally important.' This site's priority order: 1) keys to the kingdom (MFA, domain, email), 2) secrets and code, 3) the app itself, 4) patch, detect, recover. With finite time, fill it top-down. Most serious breaches come not from novel attacks but from a gap in this foundation.
Self-hosted Git vs GitHub: which is actually more secure?
Self-hosting Git doesn't make you 'more secure' — it relocates the risk. The accidental-public-exposure class disappears, but patching the server, backups, and pre-commit secret detection move onto you. The right call if you pay the price; worse than GitHub if you neglect it. This site's view: self-hosting only works bundled with its compensating controls.
Did you leave a secret file in a public directory? Audit your webroot
Anything in your webroot is fetchable by URL by anyone. A leftover token/credential JSON, .env, or backup means instant exposure — and if it came from a shared template, every site has the same hole. Fix: put only publicly-shareable things in the public dir, keep secrets outside the webroot at perms 600, and once you find one, audit every site and host.
Codecov breach (2021) — when a 'trusted tool' in CI was hijacked and secrets leaked
A trusted CI tool (the curl|bash Bash Uploader) was altered upstream. Because your own code was untouched, it went unnoticed for ~2 months while CI secrets leaked; a checksum check caught it. In your CI: verify fetched artifacts, least-privilege secrets, rotation, egress monitoring.