Yesterday I wrote about moving autonomous-agent secrets out of a flat .env file. Why I kept Vaultwarden for people and recovery, added HashiCorp Vault for workloads, and treated identity, audit, PKI, and tested recovery as part of the deployment rather than follow-up work.
For a long time, my autonomous agent found credentials the same way many applications do. Why I replaced a flat environment file with scoped Vaultwarden access, short-lived agent sessions, and a verified audit trail that now reaches Graylog and Wazuh.
Most of the storage I have bought across my career came from a few of the usual vendors, and most of it worked. It also came with things I could not source elsewhere, firmware that refused drives and software layer I paid for every year whether I used it or not. The Pro15 is a different animal...
After years of working, teaching, writing in this field, the pattern I see most in newcomers is not lack of ability. It is freezing...
I work two support queues. In one, readers email when a lab created output or did not match the screenshots within the book, the other, my extended family calls because the smart doorbell logs visitors an hour before they arrive, or the Wi-Fi is "broken" while every light on the router looks fine...
This installment goes in a different direction. Where the last post zoomed all the way in — past the running host, past the alert, down to a single line of source...stepping away from individual controls entirely and asks about the distributed, multi-platform enterprise the cloud produced.
We've climbed through the rings of the architecture... This installment goes further upstream than any of them. It steps back to the code itself — and asks how you find the flaw while it's still cheap to fix and it hasn't shipped yet. That's the domain at the heart of Application Security Testing.
This installment does something different. Every domain we've covered so far — even the unglamorous hygiene loop — was, at bottom, an attempt to keep the bad day from arriving. This one starts the morning after it did...
My lab runs Debian 13 as the primary environment, so when a 356-page Ubuntu book landed on my desk, my first instinct was to skim it, nod politely... Instead I read the whole thing — and I'm giving it five stars...
I've been working through the second edition of the Cybersecurity Architect's Handbook's "secret menu" one domain at a time...the controls that still mean something after everything else has fallen. This installment does something different...it looks down at the ground all of them are standing on.
Every control we design as architects ultimately serves one of two questions. Who is allowed to do what — and is the data still protected ... Access control answers the first. Data protection answers the second. Together they form the innermost ring of a defense-in-depth architecture...
Every query a device makes is a statement of intent — what it wanted to reach, when, and how often — and once you're logging them, you're no longer just blocking bad names. You're watching behavior....
