DevSecOps

This is the third article in my “Back to Basics” series. The goal is simple: take something modern engineers interact with daily through abstractions, and explain what is actually happening underneath. In the first article, I hardened an SSH daemon and explained why the defaults are insecure. In the second, I showed that containers are ordinary Linux processes wrapped in namespaces and cgroups. This article applies the same approach to TLS: strip away the abstractions, read the raw structures, and understand what the tooling is doing on your behalf. ...

It’s 2026 and I still receive questions from customers and colleagues about why they should adopt a hardened container image catalog, why it matters, and how to justify the investment internally. I hear it from security engineers, from architects, from technical leads at companies that are otherwise doing serious work on their security posture. The honest answer is short: European regulations like DORA and NIS2 require it, and from a purely technological standpoint it is the logical evolution of how we have always managed infrastructure. Both arguments stand independently. Together they leave no room for debate. ...

The Problem We Have Today Open source security is no longer limited by finding vulnerabilities. It is limited by coordination. Modern software depends on thousands of open source components: libraries, container images, build tools, package managers, CI/CD actions, and infrastructure projects. When a serious vulnerability appears, many teams still struggle with basic questions. Question Why it is hard Where is the vulnerable component running? SBOMs and inventories are often incomplete. Who owns the remediation? Dependencies cross teams, vendors, and platforms. Can we patch fast enough? Testing, release windows, and legacy systems slow everything down. What if no clean patch exists yet? Teams need mitigations, not only advisories. AI makes this harder. Frontier models can inspect code, reason across dependencies, and find chained vulnerabilities faster than traditional disclosure processes were designed to handle. Discovery is accelerating. Exploitation windows are shrinking. ...

A few days ago during WWDC26, Apple released container 1.0. The release notes are short, but the important part is clear: Apple wants people to try the new container machine functionality. As a team leader, when new products or tools enter the areas I work on, I like to spend some free time testing them directly. It helps me understand where they can be useful, where the limits are, and what security implications they may have for my engineering team or for customers. ...

Attackers Now Run at Machine Speed If you have been following this blog, you know that 2026 has not been a quiet year for the security community. The Trivy supply chain attack in March was the wake up call: a trusted security scanner turned into a credential harvesting machine, followed by the CanisterWorm escalation that propagated itself through the npm ecosystem at a speed no human operator could match. In the weeks after, we saw several other serious and successful exploitations following the same pattern: automation turned against the defenders, with exploits appearing within hours of a patch instead of months. ...

Every technical support team I have worked with shares the same friction point: an analyst keeps four tabs open simultaneously (the EDR console, a ticketing system, an asset CMDB, and a query window) and spends a sizeable chunk of their shift copy-pasting IDs between them. The intelligence exists. The problem is getting it out fast enough. The Model Context Protocol (MCP) is the most credible attempt I have seen yet to reduce that cost. It is a small, open specification for letting LLM-driven assistants invoke external tools in a typed, structured way: a server exposes a catalogue of tools with JSON Schema input contracts, and any MCP-aware client (Claude Desktop, Claude Code, Zed, or your own automation) can call them without writing any glue code. One server definition, every compatible client for free. ...

A few months back I saw a post circulating on LinkedIn about a developer who had been targeted by a fake recruiter. The person had been invited to a “technical assessment,” cloned a repository, and ran the code provided as part of the interview. What followed was a silent drain of every credential stored on their machine. I remember reading it and feeling a specific kind of disgust, not just at the technical sophistication of the attack, but at the deliberate choice to weaponize something as emotionally charged as a job search. ...

It Happened Again On April 22, 2026, the official Bitwarden CLI npm package (@bitwarden/cli) was compromised. For roughly 90 minutes, between 5:57 PM and 7:30 PM ET, anyone who ran npm install @bitwarden/cli received a malicious package. Around 334 developers did exactly that. The attackers did not break into Bitwarden’s npm account directly. Instead, they hijacked a GitHub Actions workflow in Bitwarden’s CI/CD pipeline and weaponised npm’s Trusted Publishing mechanism to push a poisoned release. Trusted Publishing is OIDC-based and requires no stored credentials: it was introduced as a hardening measure after credential-based attacks. It became the entry point. ...

Every few kernel cycles, a release quietly shifts what is possible for the platforms running on top of it. Linux 7.0 is one of those releases. There is no single flashy new security module, no headline-grabbing feature, but there are several changes that collectively improve weak seams that cloud-native security teams have been working around for years. Before this release reached mainstream distributions, I spent a good hour working through the upstream changelog with GitHub Copilot, running multiple state-of-the-art models, cross-referencing commit messages, kernel documentation, and coverage from the broader community, and iterating until the picture was clear. ...

Introduction I have been experimenting with Spec-Driven Development for a while now. If you are not familiar with the approach, I have a few articles tagged spec-kit that cover the theory and a real hands-on walkthrough where I built a Go TUI for Apple Container management. The short version: instead of vibe-coding with an LLM and hoping for the best, you invest upfront in a structured specification, then let the AI work against that spec. The results are measurably different. ...