8 posts tagged with "security"

A follow-up to The Silent Exfiltration.

That article described a pipeline in which a single malicious dependency could read every secret in the runner environment and post it to an arbitrary host, before any scan, on any branch, without a merge. It ended with a remediation ladder.

This one starts with an uncomfortable observation: organisations that climbed that ladder are still being hit. The largest software companies in the world, with dedicated supply chain security teams and eight-figure security budgets, had credentials compromised in this attack class in 2026. The conclusion is not that they were careless. The conclusion is that prevention has a ceiling, and above that ceiling a different approach is required – one that assumes the attacker is already executing within the build, and asks how much they obtain, how far they reach, and how long before anyone notices.

Part 2 showed that OPA/OPAL sidecars hold down about a third of the cluster and, on top of that, force you to under-provision headroom. This part is about the migration itself: how to pull the PDP out of every pod without losing data freshness or hitting a latency wall.

The properties of externalized authorization don't change — single policy plane, no drift, tamper-resistant audit log. What changes is where the PDP lives and how policy and data reach it.

Everything below is illustrative and generalized — a reference model, not data or code from any specific system. Substitute your own.

Part 2 of a series on ABAC in production. Part 1 covered in-process guards and why they're enough for most teams. This part is about what happens when they stop being enough, and what the bill looks like.

Everything below is illustrative and generalized — a reference model, not data or code from any specific system. Substitute your own. The method is what matters: measure your own numbers the same way, and the proportions will likely hold.

The setup​

Picture a typical modern platform: microservices on something like NestJS, a database, deployed to managed Kubernetes (EKS/GKE/AKS — doesn't matter), roughly a hundred to a hundred and fifty services, zero-trust model. Every user request fans out through 5–15 services, and every service-to-service call is authorized independently — no trust at the perimeter.

Authorization lives outside the applications: an ABAC policy engine (OPA) makes the decisions, and OPAL keeps policies and data in sync. User attributes sit in the database and are editable from a UI. A textbook externalized-authorization setup.

Sooner or later a simple question comes up that you usually have no number for: what does this cost? Not "is OPA expensive in principle," but concretely — how much CPU and how many dollars go into the authorization layer itself. This article is about how to measure that, and why the number turns out to be somewhere other than you'd expect.

Once you have more than a handful of services, "can this caller do this thing to this resource?" stops being a one-liner. The answer usually depends on attributes — who the subject is, what they own, which tenant they belong to, what action they're attempting, sometimes the time of day. That's attribute-based access control, ABAC: the decision is a function of subject, resource, action, and context, rather than a flat list of roles.

The interesting question isn't whether to do ABAC. It's where the decision gets computed. There's a whole spectrum. This article is the cheap, simple end of it — and most teams should start, and often stay, here. Part 2 measures what the externalized alternative actually costs once you genuinely need it.

Everything below is illustrative and generalized — a reference model, not data or code from any specific system. Substitute your own.

With the general availability of Anthropic’s new "Mythos-class" reasoning model, Claude Fable 5, the developer ecosystem has been flooded with benchmarks hailing its long-horizon autonomous capabilities. But synthetic leaderboards rarely paint an accurate picture of day-to-day repository engineering.
To see how Fable 5 holds up under real conditions, I ran an end-to-end security and logic audit on a real-world repository – nestjs-env-getter, a zero-runtime-dependency configuration manager for NestJS applications. I pitted Fable 5 (Max Effort) against the seasoned veteran Opus 4.8 (Max Effort), using Sonnet 4.6 (High Effort) as the execution muscle to see which model writes a better project blueprint for downstream automation.
The results exposed a massive paradigm shift in how frontier models approach codebase context, safety guardrails, and downstream delegation. Here is the comprehensive breakdown of my first brief testing.

Two days ago, Anthropic launched Claude Fable 5, pitching it to the public as a breakthrough in cybersecurity capability. Naturally, I put it to the test on some of my own codebases: a lightweight lib for NestJS apps (nestjs-env-getter) and a highly complex, 40k+ LOC private AI agent orchestrator. The results weren't just disappointing – they exposed a structural comedy of guardrails that completely breaks the promise of AI-driven defence for regular engineers.

Engineering teams frequently misconfigure AI coding agents (Copilot, Kiro, Claude, Codex, and others) by relying exclusively on on-demand skills — callable procedures and tool descriptions defined in an agent's tool registry (such as those conforming to the agentskills.io standard) — to enforce strict project rules. This approach fundamentally misunderstands the architecture of foundation models. When compliance mandates are embedded within dynamic tool descriptions, they are subject to conditional execution and instructional distraction. To prevent agents from silently violating security baselines and tooling mandates, organisations must implement a dual-layer architecture: static steerings for immutable boundaries and dynamic skills for isolated execution.

Modern CI/CD pipelines for Node.js applications show three worsening structural issues — secrets injected into the runner environment at the start of the pipeline, unrestricted npm lifecycle script execution during dependency installation, and open outbound network access on CI runners — which together enable silent, zero-alert credential exfiltration by any malicious package in the dependency tree. These findings are platform-independent: GitLab CI, GitHub Actions, and similar systems all have identical default insecure settings. The March 2026 compromise of the Axios npm package, a North Korean state-sponsored supply chain attack targeting a library with about 100 million weekly downloads, is discussed as a real case study confirming the large-scale exploitation of this attack surface.