Security & SRE Hardening (DevSecOps)
I harden infrastructure pragmatically, secrets management, network isolation, supply-chain security, and reliability guardrails, without drowning your team in process. The "lazy SRE" approach, maximum safety from the fewest high-leverage changes.
Sound familiar?
- ✕Secrets live in env files, CI variables, and Slack messages
- ✕The attack surface keeps growing and nobody's mapped it
- ✕A scary CVE dropped and you don't know if you're exposed
- ✕Reliability is hope-based, with no SLOs and no error budgets to speak of
- ✕Security reviews stall delivery because the process is heavyweight
- ✕You want to harden things but can't afford to stop shipping
What you get
- ✓Secrets centralized, rotated, and out of source control
- ✓A smaller, mapped attack surface with the obvious holes closed
- ✓Supply-chain controls (image scanning, SBOMs, pinned dependencies)
- ✓SLOs and error budgets that turn reliability into a decision you can actually make
- ✓Hardening that fits into how your team already works
Pragmatic hardening, not security theater
Most “security work” is a pile of low-value controls that slow teams down without removing real risk. I work the other way. Find the few changes that shrink the attack surface the most, then make them stick with the least ongoing overhead. This is the Lazy SRE philosophy I write about, and it’s how I actually work.
What I help with
- Secrets. Out of env files, CI variables, and Slack, and into a real manager (Vault, cloud KMS, External Secrets) with rotation.
- Network plane. Shrink the internet-facing surface, kill the VPN appliances and concentrators that turn into CVE magnets, and isolate east-west traffic.
- Supply chain. Image scanning, SBOMs, pinned and verified dependencies, signed artifacts.
- Reliability. SLOs, error budgets, symptom-based alerting, runbooks, and failure testing so on-call is humane.
- Policy as code. Guardrails in the pipeline so the secure path is the default one.
How an engagement works
- Map. What’s reachable, where secrets live, and where the real risk sits.
- Triage. Rank fixes by risk removed per unit of effort.
- Ship the high-leverage ones first. Close the big holes before fussing over the small ones.
- Bake it in. Guardrails in CI/CD so it stays hardened without constant attention.
Frequently asked questions
What is the "Lazy SRE" approach to security?+
It's the opposite of security theater. Instead of a hundred low-value checkbox controls, you find the handful of changes that remove the most risk for the least ongoing effort. Deleting an internet-facing appliance, centralizing secrets, isolating the network plane. Maximum safety, minimum babysitting. I've written a whole series on it.
Where should we even start with hardening?+
Attack surface and secrets, almost always. Map what's reachable from the internet and shrink it, then get secrets out of env files and CI variables into a real secrets manager with rotation. Those two moves remove most of the realistic risk for a typical team before you go anywhere near the exotic stuff.
Can you harden without slowing down our delivery?+
That's the entire point. Heavyweight security that blocks shipping just gets bypassed. I bake guardrails into the pipeline (scanning, policy-as-code, sane defaults) so the secure path is also the easy path and developers don't have to think about it.
Do you do SRE reliability work too, not just security?+
Yes. SLOs, error budgets, alerting that pages on symptoms instead of noise, runbooks, and failure testing. Security and reliability are really the same discipline seen from two angles, keeping the system trustworthy under pressure.
related work