Docker

Coding agents are good at writing code that looks right. The failure mode everyone who uses them has hit is code that calls something that doesn’t exist: a helper the model assumed you had, a method the library never shipped, a package name that sounds plausible. Python doesn’t complain until the line runs. A reviewer skimming a 400-line agent PR may not notice either, because the code reads fine. The Rabbit Hole Generator picked Skylos this week. Its pitch for that problem is to treat review as a proof: before a human looks, statically check that every package, helper, and API the change references actually exists, and say incomplete instead of guessing when it can’t tell. Its README tagline is “Code checks that show their work.” That’s a claim a security reader can test directly, so I did. I planted eight different AI-style mistakes and ran them through Skylos, through two ordinary Python tools for comparison, and through the pull request gate Skylos generates for GitHub Actions. Then I tried to get a bad change past that gate. ...

A number travels further than the system that produced it. A CI job says a model scored 0.97 on a benchmark, and that 0.97 ends up in a Slack thread, a slide, a vendor questionnaire, an audit binder. By the third hop, nobody can say who produced it or whether it’s the same number the job printed. It’s a screenshot. The standard fix is a digital signature: the producer signs the result with a private key, and anyone holding the matching public key can check that the bytes haven’t changed and that the key holder signed them. Signing software artifacts is well understood by now; projects like Sigstore do it at scale. But most of that machinery assumes the person checking can reach the internet: a transparency log, a certificate authority, an identity provider. An auditor in a locked-down review room, or an incident responder archiving evidence for a year, may not have any of that. ...

Most REST APIs ship with two kinds of tests: unit tests that check functions in isolation, and integration tests that walk the happy path. “Create an item, read it back, delete it, get a 204.” Those tests are written by the same people who wrote the code, so they test the inputs those people expected. Nobody writes the test that sends a 65-character name, a quantity of 2^64, or a DELETE for an item that was never created, because nobody thought of it. ...

It started with a misconfigured CI runner. A developer had a Jenkins pipeline building Docker images. The container ran as root. A dependency had a known RCE vulnerability. When the exploit landed, the attacker had root inside the container, and because that process was root, they also had root on the host. They pivoted to the secrets store, grabbed credentials, and spent three weeks inside the network before anyone noticed. ...

Container Networking Deep Dive: From Network Namespaces to Kubernetes Note: This guide is based on the Linux kernel networking documentation, Docker networking documentation (v24+), Kubernetes networking model documentation (v1.28+), and CNI specification v1.0. All examples use documented networking primitives and follow production container networking patterns. Container networking is fundamental to modern cloud-native applications. Understanding how packets flow from pod to pod, how services load-balance traffic, and how network policies enforce security requires knowledge of Linux networking primitives, Container Network Interface (CNI) plugins, and Kubernetes networking abstractions. ...