If your workloads run on Kubernetes, where should your security logs come from?
This post, part of the “Continuous Visibility into Ephemeral Cloud Environments” series, describes a design for a state of the art security logging platform for Kubernetes clusters. It completes the set started by the AWS and GCP posts, both of which promised “a follow-up post” on worker node and container logs. This is that post, a few years later than planned.
Earlier this week I read The AI-Native SDLC Playbook from Anthropic.
It should be mandated reading in Engineering orgs, and even more so for Security people, at every level of seniority.
Read the post. Take the time to think each concept through. I truly think we, as an industry, should have the courage to throw away the playbooks we’ve been working on for the past 20+ years and create new (and better) ones for the AI era.
If you followed the wave of supply-chain attacks from the first half of 2026, you’ve probably realised that continuously patching and upgrading your dependencies is no longer optional.
For me, Renovate handles the patching part well.
Most bumps are safe, but majors, 0.x jumps, dead dependencies, and quietly deprecated framework configs are hard to spot from a CI test.
Manually reviewing every PR with the same rigor also doesn’t scale, and is a waste of time, to be honest.
CloudSecList just shipped a redesigned landing page.
Claude Design did the mockups. Claude Code wrote most of the code for Jekyll. I did everything in between, which turned out to be most of the actual work.
Claude Code ships with a capable baseline. After months of daily use across a multi-project monorepo, my default install has grown into something that looks less and less like the box it came in.
Rather than dump a big settings.json and hope it’s useful, I want to walk through my own setup.
