Rich Gibbs

I ran a read-only server audit. Here's what I found that the scanners missed.

server · audit · security · quickcheck · vps · ec2 · hardening · indie-founder · backup

Direct answer

A read-only server audit is useful because it finds quiet operational risks like exposed backups, stale secrets, weak file permissions, and forgotten deploy artifacts without needing destructive access.

I keep my servers boring. SSH keys only. UFW defaults-deny. Unattended-upgrades on a timer. Fail2ban because why not. Nothing fancy — just the basics that every indie founder’s “I’ll get to it” list already has.

I thought I was fine. And I mostly was. But “mostly” is the kind of word that keeps incident responders employed.

Last month I ran a structured read-only audit on my own infrastructure. Same process I use for the QuickCheck — just a systematic posture review. No exploits. No intrusive scans. Just a checklist of things that tend to drift when you’re focused on shipping instead of hardening.

I wasn’t expecting to find much. That’s what made the find annoying.

The find

In a /var/backups/ directory on a utility box, there was a compressed archive from nine months ago. Inside: a full .env file from an old deployment script — database host, API keys, a service account token — world-readable. The backup job that created it had been disabled when we moved to a new deploy pipeline, but the artifact was still there. Anyone with a shell on that box — a compromised dependency, an unattended curl | bash, a stray container — could have read the whole thing.

No, this wasn’t an exposed CVE or an active exploit. It was quieter than that. It was the kind of thing that only matters after something else goes wrong. But if something had gone wrong — if someone had gotten a foothold — that file would have turned a limited incident into a full credential dump in about 30 seconds.

What I deliberately did not do

I did not run a vulnerability scanner. I did not attempt to crack anything. I did not change any configuration during the review. This was a read-only posture check: what’s listening, who has access, where are the seams, what did I forget about.

That distinction matters. A pentest answers “can someone break in right now?” A read-only audit answers “if someone does break in, how bad is it?” They’re different tools for different questions. Most solo devs need the second one long before they need the first. (I wrote more about that distinction here.)

The fix

The fix took fifteen minutes: delete the archive, rotate the compromised keys, add backup-cleanup to the deploy checklist. No firewall changes. No architecture redesign. No downtime. The risk wasn’t in the remediation — it was in the nine months the file was sitting there without anyone noticing.

That’s the part that stuck with me. It wasn’t a sophisticated attack that would have exposed me. It was a backup artifact from a retired pipeline, doing exactly what backups do — persisting data after the original source is gone.

What I do differently now

I added a quarterly check to my calendar: “read-only audit, one box.” Same methodology each time. Check users and groups. Check world-readable files in unexpected places. Check what’s listening on interfaces it shouldn’t be. Check cron jobs and systemd timers that might outlive their purpose. Takes about an hour. Has paid for itself twice over in peace of mind.

Your mileage will depend on your setup — age of the server, number of people who’ve had access, how many experiments got deployed and never cleaned up. But the basic principle holds: the best time to audit is before you have a reason to. The second-best time is now.

If you want a second set of eyes

Every time I tell this story at a meetup or on a thread, someone asks if I do these audits for other people. So I productized the methodology: the Hardening QuickCheck is the same structured read-only review I run on my own boxes. You get a report with what I found, why it matters, and what to do next. No production changes. No credentials stored. Just a prioritized write-up from someone who has been surprised by a backup file too.

See what a report looks like if you want to judge the format before committing.

And to be clear: this is a posture review, not a penetration test or a compliance certification. It won’t guarantee your server is unhackable. What it will do is tell you where the quiet risks are — including the ones that scanners miss because they aren’t looking for your old deploy-backup-2024.tar.gz.


Read-only audit, not a pentest. Your mileage depends on your setup. Not compliance certification or a guarantee of security.

Frequently asked questions

What can a read-only server audit find?

It can find world-readable backups, stale environment files, exposed logs, weak permissions, old deploy artifacts, missing updates, and unsafe service exposure.

Does a read-only audit require SSH write access?

No. The point is to inspect evidence and configuration without changing the host or taking over the deployment path.

Why do scanners miss some server risks?

Scanners usually focus on ports, CVEs, and known signatures. They can miss local operational mistakes such as old backups, forgotten archives, and context-specific secret exposure.