Coder Legion - Recent posts tagged devsecops

Developer Weekly Briefing — October 30, 2026

Fri, 30 Oct 2026 13:55:46 +0000

Security dominated this week, but not in the usual way. Two active campaigns turned GitHub configuration files into attack surfaces. Researchers demonstrated that the built-in browsers inside AI coding tools can read your SSH keys. And at Oracle AI World in Las Vegas, three separate announcements showed how Oracle is thinking about agent identity, governance, and deployment in enterprise systems. There was a lot to track. Here's what matters.

Two GitHub campaigns, one weak point: your config files

Researchers this week documented two separate attack campaigns targeting GitHub repositories — and both are still active.

Wiz Research named the first one Gheist. It planted more than 13,500 malicious branches across 850-plus accounts. The payloads encode secrets in base32 to slip past GitHub's credential-scanning log masking, and they target private repositories and GitHub Enterprise Server — the approval hold GitHub applies to first-time contributors only covers public repos on github.com, so Enterprise Server customers have no equivalent protection. Gheist isn't looking for source code. It's looking for credentials.

JFrog named the second campaign testmetest. It hijacked 42 real repositories and planted malicious hooks inside AI tool configuration files: .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, and .vscode/tasks.json. Payloads run 12.9–13.7 MB — large enough that GitHub code search won't surface them. The attack runs as soon as someone opens the repo in an affected tool.

Mitch Ashley of The Futurum Group put it plainly: "Agent configuration has become the newest build script in the repository, and review processes have not caught up."

The practical steps are the same for both: audit what's in your AI tool config files, treat them the same as build scripts, and limit the secrets available in any environment where agents run. If you're on GitHub Enterprise Server, check what protection you actually have for first-time contributors on private repositories — it may be less than you think.

AI coding tools can read your SSH keys — two are still unpatched

Researchers at Forever Security documented a vulnerability class they're calling EMBRACE. The attack vector: the built-in browsers inside AI coding tools have access to the host machine's file system. A single click on an assistant-generated HTML link can read your SSH private keys, .env files, and npm tokens from anywhere on disk.

Five tools are affected — Cursor, GitHub Copilot, OpenAI Codex, VS Code, and Claude Desktop. Cursor patched the issue October 1. Copilot fixed it in v1.1.29 on October 13. As of October 29, Codex and VS Code were still unpatched.

The mechanism is simple enough to explain in a sentence: the built-in browser runs with the same permissions as the editor, not as an isolated sandbox. When an agent generates a link and you open it in the built-in browser, that page can reach files the browser has no business touching.

If you use Codex or VS Code with built-in browser features enabled, the current workaround is to open assistant-generated links in an external browser until patches ship. It's also worth auditing what credentials live in places a browser process could reach — SSH keys, .env files, and token files sitting in obvious locations.

Flint runs 40B parameters locally — and keeps your code off someone else's server

Recursive, led by former Salesforce chief scientist Richard Socher, released Flint this week: a 40-billion-parameter mixture-of-experts model designed to run on a developer's machine rather than through a cloud API. With a mixture-of-experts architecture, it activates only about 2.5 billion parameters per token. Recursive reports over 125 tokens per second on an M4 Pro MacBook Pro, with a 512,000-token context window.

Weights are on Hugging Face under Apache 2.0 and the model works with llama.cpp, Ollama, LM Studio, and vLLM. A quantized build needs at least 24GB of RAM; Recursive recommends 48GB for agentic coding workloads. OpenHands is a launch partner, and there's a free hosted version on OpenRouter if you want to try it before committing hardware.

The business case for local models is straightforward: no per-token API fees and source code never leaves your machine. Recursive claims Flint leads mixture-of-experts models under 50B parameters on agentic coding benchmarks — those are the company's own numbers, not independently verified. Mitch Ashley of The Futurum Group flagged the implication for teams: "Evaluation becomes continuous work, tested against each team's own code before a model reaches the pipeline." A benchmark on someone else's code isn't the same as a benchmark on yours.

SAP's CTO says building the agent is now the easy part

At SAP TechEd 2026, SAP CTO Philipp Herzig said something developers probably already sense but rarely hear from a vendor executive: "Building is, quite frankly, the most unimportant part these days."

The harder problems, in his framing, are testing, governance, and token cost. SAP's answer is Joule Studio, its agent-building environment, which now includes a CLI with MCP connections, a built-in sandbox, and auto-generated unit tests. SAP also announced the SAP Enterprise AI Gateway, in preview now and scheduled for Q1 2027, which handles routing, rate limiting, and cost controls across the agents a company runs.

On the data side, SAP Business Data Cloud adds a lakehouse layer built on Dremio and Apache Iceberg.

SAP cited an internal comparison showing 30 hours to build an agent with Claude Code versus 2 hours with Joule Studio. That's SAP's own benchmark, and Joule Studio knows SAP's data models in ways a general-purpose coding tool doesn't. Take it as a claim, not a proof. But the underlying point — that tools with domain knowledge built in will reduce setup time on domain-specific problems — is reasonable.

For developers building on SAP, the Gateway announcement is worth tracking. If it ships on schedule in Q1, it gives teams the enforcement layer Herzig described, with controls that apply before the agent executes, not after.

Oracle gives each agent its own identity

At Oracle AI World, Oracle announced the Oracle AI Security Mesh, a framework designed for enterprises running multiple agents across sensitive data. The core idea: each agent gets its own identity, a defined task scope, and just-in-time permissions rather than standing access.

The architecture has a few pieces worth understanding. OCI Identity Assurance handles authentication, including biometrics. OCI Zero Trust Packet Routing enforces policy at the network layer, below the application — which means an agent can't bypass the controls by manipulating the software above them. Each agent also gets an independent monitor, separate from the agent itself.

Oracle didn't announce a general availability date or pricing.

This lands a week after the Gheist and testmetest campaigns, which both targeted credential theft through misconfigured agents. The timing is coincidental, but the relevance is real. The question Oracle's framework raises — and doesn't fully answer — is how you verify that the identity and permission assignment worked the way you intended. That's what attestation is supposed to solve, and it's still the hardest unsolved problem in agentic AI security right now.

Reddit's r/opensource banned AI tools. It probably won't work. The subreddit's new rules ban AI-assisted contributions, exclude MCP servers, require projects to have multiple contributors and an established community, and will permanently ban users who message moderators seeking exceptions. Linux took the opposite approach — Torvalds said the kernel "is not one of those anti-AI projects" and dropped its AI-disclosure requirement, shifting the burden to accountability: understand your code, regardless of what tools you used. The better model for DevOps teams is probably closer to Linux: hold contributors accountable for what they submit, build CI gates that shift review costs back to submitters, and avoid policies that require judgment calls you can't make consistently. Read more
IBM Z Atlas maps your entire mainframe before you touch anything. IBM's new tool for z/OS builds an AI-searchable map of the entire stack — programs, data sets, JCL, subsystems — so teams can understand what they're changing before they change it. IBM reports 60–80% less time spent gathering context, and analysis that used to take hours running in minutes. On-premises only; public preview October 27, GA in Q1 2027. Requires z/OS 3.1+. The AI reasons and synthesizes, but the underlying data is deterministic — you can trace any answer back to the source. Read more
F5 and NVIDIA draw a hard line between data residency and sovereignty. F5's Ahmed Guetari stated the distinction directly: "Data residency is where data sits. Sovereignty is who controls it." The joint offering layers NVIDIA OpenShell and F5 AI Guardrails on BIG-IP Next for Kubernetes, with enforcement on NVIDIA BlueField DPUs at the hardware layer. Token-aware cost controls and two live deployments — Telenor in Norway and Indosat in Indonesia — are already running. Read more
Oracle's Fusion Setup Registry puts enterprise configuration into a public Git repo. Oracle published the Fusion Setup and Configuration Registry (FSCR) — machine-readable setup skills for Fusion Cloud Applications that AI agents can run. The registry covers dependencies, sequencing, and validation, and an early adopter reported 80% reduction in design and configuration work during implementation. Lexington Health is the only customer data point so far. The repository is public, so you can read the skills before committing to them. Read more
Bito's Governor cut one team's coding agent costs 48% by fixing the search loop. Privado used Bito's Governor to reduce the number of times its coding agent re-searches the codebase for context it already found. The result was a 48% reduction in token costs. Short version: agents that re-retrieve context they've already gathered are expensive, and the fix is stopping the loop rather than switching models. Read more
Oracle plans post-quantum TLS for Java 8 and 11 in late 2027. Hybrid post-quantum key exchange for TLS 1.3 is GA in JDK 27. Java 21 and 17 get it in the first half of 2027; Java 8 and 11 in the second half. There's a condition: the backport date holds only if the team gets enough testing feedback on current builds. If you're on Java 8 or 11, the slow path is waiting. The faster path is pointing a JDK 25 or 27 client at your post-quantum-capable endpoints now and filing what breaks. Read more
Larry Ellison says Oracle Health modules plug into Epic with no data migration. Ellison's pitch at Oracle AI World: turn on the module, it finds the relevant staff, records, and labs through existing SMART on FHIR interfaces, and you're done. The oncology module was the main example. Early adopters should have the full suite by February 1. No demo, no independent validation, and no published technical documentation on which FHIR resources the modules read and write. That's work for the teams who get early access. Read more

Developer Spotlight this week

Yaoshen Luo builds agent evaluation frameworks — and writes about the times they failed him. Based in Shanghai, he built a benchmark from scratch when customer complaints about a voice agent told him the model scores weren't the problem. The test set skewed toward longer sentences than real traffic, and accuracy dropped once he resampled to match production. His earlier lesson: he built an agent that passed every benchmark, shipped it to volunteers for a non-profit project, and they refused to use it again. Not because the model was wrong. Because the workflow didn't fit how they actually worked. His take: the workflow is part of the evaluation, not something you test after.

Watch the conversation

The through-line this week is that agent security is moving from theoretical to active. Gheist and testmetest are already running. EMBRACE vulnerabilities are patched in some tools and open in others. The configuration files developers add to repos for AI tooling are now a real attack surface. Oracle, SAP, and F5 all shipped security and governance frameworks this week — which is a sign that vendors know the problem is real. Whether any of those frameworks hold up in practice is a different question, and the answer won't come from a keynote.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

HiddenLayer: A Hijacked LLM Gateway Can Turn Your Coding Agent's Own Permissions Against You

Thu, 22 Oct 2026 14:00:00 +0000

Most security talk about AI coding agents focuses on the model. Will it run a bad command? Can a poisoned README trick it? New research from HiddenLayer looks somewhere else: the plumbing between the agent and the model.

In a report released today, HiddenLayer researchers Esteban Tonglet, Divyanshu Divyanshu, and Kasimir Schulz show that anyone who controls an inference server or LLM gateway can quietly learn how a coding agent is configured. Then they can forge tool calls that ride on permissions the developer already granted. The agent runs them. The developer sees nothing unusual.

Why the middle layer matters

Plenty of developers don't send traffic straight to one vendor. They use open harnesses like OpenCode, Cline, and Hermes, pointed at open-weight models served through Ollama, vLLM, or providers like Together AI and Fireworks. Many organizations add a gateway such as LiteLLM to centralize API keys, routing, logging, and policy.

Each layer relays requests and responses, so it sees prompts, tool definitions, history, and tool output. LiteLLM's async_pre_call_hook and async_post_call_success_hook let custom code read or rewrite that traffic. That's useful for guardrails. It's also exactly what an attacker wants.

HiddenLayer describes two ways in: a malicious Ollama wrapper that listens on the default port, 11434, and forwards to the real service, or a supply chain compromise of a gateway's package, plugin, or container image.

Step one: watch the clock

The attacker doesn't need to change anything to start learning. By timing the gap between a tool call and its result, a proxy can tell whether the agent paused for a human to approve it. File reads normally finish almost instantly. A pause of several seconds suggests a prompt.

The signal is strong. Across more than 4,000 captured sessions, just 4.7% of calls to fast tools landed in HiddenLayer's ambiguous range, compared with 25.5% of shell calls. Across more than 35,000 file reads, only 1% did.

Shell commands are noisier. So the proxy can slip timing code into a script through an auto-approved file edit, or wrap a command in a timer. Either way, the timing output is stripped before the user sees it.

Hiding that wrapper is easier than you'd think. Agents routinely generate long build commands full of pipes and redirects. Users scan for rm, sudo, or curl piped to a shell. A small addition in a 20-command line blends in. The researchers used a Tree-sitter Bash parser to score complexity and pick hiding spots.

Step two: read the configuration

Harnesses also give a lot away. Codex headers start with codex-tui. Claude Code identifies itself as claude-cli. Hermes uses a generic OpenAI SDK user agent, but its default tools (terminal, write_file, patch) reveal it.

Some harnesses go further. Codex includes its permission settings in every request: sandbox mode, writable paths, network access, and approved command prefixes. Claude Code sends its working directory, OS, Git status, and a Bash tool schema that includes a dangerouslyDisableSandbox option.

A proxy can also insert its own reads of files like CLAUDE.md, AGENTS.md, or .cursorrules, then strip the call and result. The model never knows.

Step three: use what's already allowed

HiddenLayer ran two demos. In the first, Hermes ran in manual mode, which only prompts for commands it considers dangerous. When the user asked Hermes to read a Python file, the proxy inserted file edits that added a heartbeat_ok() function. That function collected environment variables and SSH keys and sent them to an attacker's webhook. The proxy then ran the file with python3 and removed the function. Every step ran without a prompt.

In the second, Codex had the git prefix approved and a writable .git directory. The proxy forged this call:

git -c diff.external='sh -c "cat .env"' diff --no-index /dev/null .env

Codex ran it without asking and returned the contents of .env. Git's helper options can launch other programs, so an approved git prefix is broader than it looks.

There's a slower option, too. The gateway rewrites a dependency name, say requests to reqiests. Nothing happens until someone installs dependencies later.

This isn't hypothetical

LiteLLM shipped two malicious PyPI versions, 1.82.7 and 1.82.8, on March 24, 2026, after attackers got hold of a maintainer's publishing credentials. And an April 2026 study of 428 third-party LLM routers by University of California researchers found nine injecting malicious code and 17 abusing researcher-planted AWS credentials.

What developers can do now

HiddenLayer's report focuses on the attack, not a checklist. Here's what I'd take from it:

Treat gateways and inference servers as part of your trust boundary. Pin versions, verify artifacts, and control who can change hooks and callbacks.
Be careful with free or unknown routers. Cheap access isn't worth handing someone your traffic and keys.
Keep approvals narrow. Blanket approvals for git, python, or file edits give a proxy room to work.
Keep secrets out of the agent's reach. Don't leave .env files, SSH keys, or cloud credentials where the agent can read them.
Watch outbound traffic from developer machines and build systems.

Coding agents are doing a lot of good work. But sandboxes and approval prompts assume each tool call came from the model you chose. HiddenLayer's point is that this assumption no longer holds. The security boundary includes every system that can shape what the agent runs. And the teams that build and deploy these agents are responsible for that whole path.

CyberCartel Pointed Claude and Grok Agents at 400+ Banks. The Stack Looks Like Yours.

Thu, 22 Oct 2026 13:30:00 +0000

A financial crime group active since 2012 just showed developers what their everyday agent stack looks like in the wrong hands.

New research from Straiker shows how CyberCartel built a multi-agent attack system called CARLIY0S and aimed it at more than 400 banks, payment providers, and other financial organizations across Latin America. The system ran on commercial models, including Anthropic's Claude and xAI's Grok, with Moonshot AI's Kimi in the mix.

The tools will look familiar. Cursor. MCP servers. API keys in .env files. Playwright. That's the part developers should sit with.

How Straiker Got Inside

CyberCartel made an operational security mistake. That gave Straiker a snapshot of the group's working environment. The September 24, 2026 snapshot captured the group's stolen-credential database, called "FinancialSoft." It held 4,493 records, including passwords and API keys.

Could it have been a decoy? Vinay Pidathala, vice president of AI security research at Straiker, doesn't think so. The team tied the environment to more than 270 pentest reports against real organizations. "The volume and specificity across hundreds of entities is inconsistent with a honeypot," he said.

Straiker attributes the work with high confidence to Tr4nsHack Team, which operated under the front name Hexagon Security Labs Mexico. Operator handles in the source code and reports matched known CyberCartel operators.

The irony: the group's rule files told the models never to output the Tr4nsHack alias. The name showed up in its own reports and code anyway.

Four Agents and an Arbiter

Here's how the system worked, based on the group's own scripts and configuration. Straiker notes it did not validate the outcome for any individual target.

A commander, Claude running in Cursor, sets a high-level objective. It delegates through the Anthropic API to four role-based agents:

A recon agent maps the target's infrastructure and looks for ways to avoid detection.
An exploit agent writes the attack code and automation.
A third agent suggests lateral and unconventional attack paths.
An arbiter weighs the debate among the other three and returns a single decision.

Five Grok "miners" analyzed the collected data and posted it to the attackers' dashboard.

Execution ran through a headless browser routed over residential proxies, so traffic looked like it came from domestic Mexican IP addresses. Once the system gained code execution through a target's web admin panel, it dropped the browser for a faster, quieter scripted session. Automated payloads then scanned databases, hunted for credentials and SSH keys, and mapped internal networks.

Why the debate format? Straiker doesn't know, and it didn't test whether four agents beat one.

Getting Past the Guardrails

The operators framed their requests as authorized red-team engagements or academic penetration tests. Straiker calls this dual-use contextual framing.

It didn't work on every model. Refusals varied inside the same system, and Straiker says it has no visibility into why. When a model refused, the orchestrator fell back to a local file of pre-written attack code, so the operation kept moving.

So how much did AI actually add? According to Pidathala, all 270+ attack reports were AI-generated. "We did not see evidence of manual efforts," he said. The local script was a fallback, not the main engine.

The configuration also listed claude-fable-5. Straiker can't confirm it ever ran. "A configuration entry is not evidence of successful execution," Pidathala said.

What We Don't Know

Quite a bit. Straiker isn't sharing how many of the 400+ targets were compromised or how much money was lost. It cites responsible disclosure while affected organizations and providers work through the fallout. The 400 figure counts targets, not confirmed breaches.

According to The Information, Anthropic investigated after Straiker shared its findings and blocked the group's access to Claude. Straiker reported that xAI was notified and is investigating the use of Grok.

What Developers Should Take From This

The core lesson is that this tooling is dual-use. "The same agent stack that builds software can run an offensive operation," Pidathala said.

That isn't a reason to stop building agents. They do a lot of good work. It's a reason to own what your agents can reach. Whoever builds an agent is responsible for what it does. So is the company that deploys it.

Straiker's guidance for teams building agents:

Test agents against real attack techniques before production. Pidathala calls this the single highest-value action a team can take this week.
Rotate agent credentials often and scope them tightly.
Add observability and guardrails to detect and stop abuse at runtime.
Treat .env API keys and MCP server access as high-value assets to secure and monitor.

That last point is easy to skip. An API key in a .env file feels routine. In CARLIY0S, API access is what let one commander direct a team of agents across hundreds of targets.

Where This Goes Next

Pidathala expects these operations to grow in sophistication and scale as models get more capable, compute gets cheaper, and attackers build AI skills. Defenders, he said, will need to continuously test their infrastructure and be ready to "detect and respond to AI-powered attacks at machine speed."

That's not hype. It's a small team, a familiar toolchain, and more than 400 financial targets. The gap between the agents developers build and the agents attackers build is mostly intent. Security has to cover the rest.

Developer Weekly Briefing — October 16, 2026

Fri, 16 Oct 2026 12:28:25 +0000

A week defined by two big ideas running in parallel: AI agents are breaking the infrastructure underneath them, and the security surface around developer workflows keeps growing. Both threads showed up in force. Here's what mattered.

Anthropic hit 30,000 merges a day, and Git couldn't keep up — so it built Scion

By September 2026, Anthropic was averaging 30,000 merged changes a day, up from 2,500 in May. Its main branch history had grown close to 100 GB. CI alone required 25 million checkouts a day, and at peak the team ran several hundred Git mirrors just to keep up. Standard workarounds stopped working. So a seven-person team built a replacement from scratch.

Scion is Anthropic's internal version control system. The design is built for always-online, agent-heavy workloads rather than Git's original model of offline, occasional human pushes. Servers handle commits, merges, rebases, and diffs. Clients keep a small local cache. Commits are stored as changesets that scale with the size of the change, not the size of the repo. Cache hit rates are above 99% at each of the three tiers. The result: checkouts take seconds instead of minutes, use about 200 times less CPU and memory than the old mirror fleet, and recover 25% of CI capacity.

Anthropic says Scion only makes sense for very large monorepos and has no plans to release it — but it wants to share the ideas with GitHub, GitLab, and the open source community. Last week's briefing covered GitHub's infrastructure rebuild to handle agent-scale load. This week, Anthropic said: we got there first, and we had to build something new to do it.

GitLab patches a CVSS 10 — update now

A critical vulnerability in GitLab's CI/CD regex engine, CVE-2026-97229, got a perfect CVSS score of 10.0. An unauthenticated attacker could send a crafted regex in a CI/CD configuration and execute arbitrary code on the server — which typically holds source code, pipeline definitions, and production secrets. GitLab shipped fixes in versions 19.4.2, 19.3.5, and 19.2.8 on October 12. GitLab.com is already patched. Dedicated customers need no action. Self-managed instances need to upgrade now. The release also covers 23 other vulnerabilities, including an 8.7-rated prompt injection in GitLab Duo Agent Platform.

GitHub now records who pushed every commit

Git has always let developers set their own name and email in commits — metadata that's trivially spoofed. GitHub's new push attribution feature records the authenticated account that actually pushed each commit, separate from the author and committer fields. A new repository ruleset, "Committer must match pusher," can block pushes where the committer's email doesn't match the pusher's verified addresses. The practical benefit: bots and agents often push commits under a human's name. This makes that visible. It's in limited public preview for GitHub Enterprise. Before enabling the enforcement rule, audit your release bots, shared tokens, and any workflow that pushes on behalf of someone else — the rule will break those if you don't.

GitHub is pushing teams off classic PATs — here's the new permission model

GitHub announced narrowed app permissions aimed at getting teams off classic personal access tokens. Classic PATs have been a persistent weak spot: long-lived, often over-scoped, and easy to forget once they're embedded in a workflow. The new fine-grained permissions limit what any given token or GitHub App can access. If your team still uses classic PATs in automation, this is a push to move. The transition won't happen overnight, but the direction is clear.

npm gives unused trusted publishing configurations 48 hours to prove themselves

npm's trusted publishing feature ties release authority to a repository or project name. That's useful until the name changes hands — an abandoned or reorganized repo that still has a trusted configuration is exactly where supply chain attacks start. npm's fix: any configuration that doesn't complete a successful publish within 48 hours of creation expires. Once it publishes successfully, the expiration goes away. The practical change: create your trusted publishing configuration when you're ready to publish, not during setup. If it expires, recreate it.

Claude Platform now sends agent traces to your observability stack

Anthropic added native OpenTelemetry trace export to the Claude Platform, in public beta. It works with the Messages API, Claude Managed Agents, and the Claude SDKs. Each trace includes duration, status, token counts, the model used, tool names, and request IDs. Teams can also enable full content export, which adds prompts, responses, and tool inputs and outputs. Setup for the Messages API and Managed Agents requires no application code changes — just configure an export destination in the Claude Console. The feature supports any OTLP-compatible backend; Anthropic has published guides for 12 partners, including Datadog, Grafana, Honeycomb, Langfuse, New Relic, and Splunk. The practical value: agents make several model calls, tool calls, and retries per request, and failures in that chain are hard to trace without instrumentation. This is the instrumentation.

Figma gives AI agents a spec sheet and code layers land on the canvas

Figma shipped two features worth tracking. Specs is a Markdown editor — on canvas or as a standalone file — where teams write requirements, design rules, and agent instructions. It can reference canvas elements, pull context from a connected GitHub repo, and embed diagrams and code. On the development side, Code Layers lets teams place running, code-backed prototypes directly in a Figma file. Code can come from a GitHub repo, a local folder, a live website, or an AI coding tool. Claude Code gets a round-trip: work from Claude Code can land in Figma, and design changes can be pulled back into the codebase through MCP. Both features are in open beta.

Cloudflare acquires Deno's team to build self-hosted Workers. Cloudflare is hiring Ryan Dahl and the Deno team to make workerd, the open-source Workers runtime, production-viable for self-hosted deployments. Deno Deploy shuts down in six months. Deno runtime gets one more year of maintenance releases. JSR keeps running. If you're on Deno Deploy, start planning the move now. Read more
Microsoft launches Decision-1, a fast, cheap decision-scoring model. Built on post-trained Qwen3.5-9B, Decision-1 takes a fixed set of answers and returns calibrated probabilities in a single API call. It's aimed at routing, classification, and workflow control — the "System One" decisions in an agent pipeline. Available in Microsoft Foundry and through OpenRouter at $0.042 per million input tokens. Read more
Nvidia hands Run:ai to the open source community. The GPU orchestration platform Nvidia acquired in 2024 is going open source. For teams managing GPU workloads for AI training and inference, this matters. Read more
SpaceX bundles Grok, Cursor, and X Premium into one subscription. The $30/month Premium tier combines Grok, Cursor Pro, and X Premium+ — tools that would cost about $90 separately. The catch: Grok and Cursor share a usage pool, so AI chat and coding work against the same weekly limit. Dev teams should audit that tradeoff before committing. Read more
AI doesn't replace your thinking — it raises the bar for it. My latest for Insights From Analytics: the patterns I keep seeing when professionals struggle to get real value from AI, and what changes when they fix them. Read more

Developer Spotlights this week

Bryan MacLee drives an oil and gas truck in Vernal, Utah, and builds his own programming language on the side. SCRML is a full-stack language for the browser — the compiler handles the wiring between frontend and backend that developers normally manage by hand. Version 0.8 is out. Adoption is near zero, by his own description on the project site. He's building it anyway. A good conversation about what it takes to build something nobody's using yet.

Watch the conversation

Jonathan Gordon spent decades building developer tools at Google, Apple, Microsoft, Oracle, and SAP. His warning: AI-generated code often has error handling that "puts nothing in the catch block." Users find out when buttons stop working. His rule: "We can't just let AI build the software by itself." The full conversation is a useful counterweight to the vibe coding conversation.

Watch the conversation

The through-line this week: agents are breaking things at the infrastructure layer, and security controls designed for human developers don't hold up at agent scale. Anthropic had to build a new VCS. GitHub is adding authentication that was never needed when a human was always at the keyboard. The same pressure is showing up everywhere.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

HYCU's Free aiR Graph Maps Every Agent in Entra ID and Okta, Then Asks If You Can Recover

Thu, 08 Oct 2026 20:33:18 +0000

Ask an IT leader how many AI agents are running in their company and you'll usually get a pause. Ask which of those agents can delete data and the pause gets longer.

That's not negligence. Agents don't arrive through one front door. A team turns on a copilot. A developer registers an app in Entra ID so an agent can write to Salesforce. Someone grants an OAuth scope in Okta so a workflow agent can run overnight. Each decision makes sense on its own. Together they add up to a population of non-human identities nobody counted, with permissions nobody reviewed as a set.

HYCU is going after the counting problem first. The company made aiR Graph generally available today, free to any organization, customer or not. It connects read-only to Microsoft Entra ID, including Entra Agent ID where it's enabled, and to Okta, including Okta AI Agents where an organization subscribes. On the first scan, it maps the applications in the tenant and flags the copilots and agents among them.

For each agent, aiR Graph pulls the details you'd want before trusting it with production data: its OAuth scopes, which data sources it can read and which it can write, whether it has organization-wide access, whether it acts unattended, how many people can invoke it, and whether anyone is recorded as its owner or sponsor.

"Every organization we talk to is adding AI agents faster than it can count them," said Simon Taylor, HYCU's founder and CEO.

An inventory is useful. But knowing an agent exists doesn't tell you what happens when it goes wrong. That's where aiR Graph goes further than most agent inventories. It adds a protection gap view that asks a blunt question: if this agent damages the data it can reach, is there an independent copy to recover from? Agents with write access to systems of record that have no backup rank first.

That ordering follows an argument HYCU has been making for months. When I talked with Amarnath Rampratap, HYCU's head of R&D India, in September, he said the root cause he sees most isn't a bad prompt. "Nearly every incident that reaches us has an over-scoped, long-lived token in the chain," he said. The PocketOS incident is the public example: a Cursor agent found a Railway token with far more reach than its job required, and one API call took a production database and its backups with it. aiR Graph is designed to find that kind of credential before an agent uses it.

Severity in aiR Graph tracks capability. The more an agent can reach and change, the higher it ranks. HYCU's examples of top findings include unattended access to all user data, broad access combined with write or delete rights, and enabled accounts whose agent identity has been deleted. That last one deserves a second look. An agent can be retired while the account behind it stays live, which leaves a working credential with no one watching it.

Jerome Wendt, CEO and principal analyst at DCIG, put the gap plainly: "Knowing an agent can modify data in Salesforce, GitHub, or Confluence only identifies the risk." The other half is whether you can undo what the agent did.

The design choice developers will notice most is what HYCU left out. "We made a deliberate choice to keep language models out of the risk assessment," said Anant Chintamaneni, HYCU's chief product officer. Every finding comes from an explicit rule applied to identity-provider data. "Run it twice on the same tenant, and you get the same answer," he said. And each finding traces back to the identity field that produced it.

That matters more than it might seem. A risk score generated by a model is hard to defend. If two runs disagree, which one goes to the auditor? Which one goes into the ticket? With deterministic rules, the difference between two scans reflects a real change in the tenant, not variance in the model. You can rerun the assessment after tightening scopes and see exactly which findings cleared. There's some irony in a tool for governing AI agents that keeps AI out of its own judgment. But it's the right call for something security and compliance teams will be asked to stand behind.

When a scan finishes, one click produces a point-in-time assessment report with an executive summary, recommended triage actions, and the full inventory. HYCU first showed the tool at the IT Press Tour in Ljubljana last month, and select customers ran it in preview before today's release.

A few things to keep in mind before you run it. Entra ID and Okta are the first discovery sources, and HYCU says more are coming. Discovery runs through the identity provider, so an agent whose credentials never touch Entra ID or Okta, like a personal access token sitting in a CI secret store, won't show up there. The report is a snapshot, not continuous monitoring. And the protection gap view naturally points toward HYCU R-Cloud, which covers more than 100 workloads. The tool is free, but it also shows HYCU exactly where its backup product fits. That doesn't make the findings less accurate. It's just worth knowing.

For developers who've built agents themselves, the most useful exercise may be the simplest one. Run the scan, find the agents your team registered, and compare the scopes they hold against the scopes they need. Then check whether the systems they can write to have a copy they can't reach.

Most teams can't answer the two questions this piece started with. Now there's a free way to get a first answer to both, and a third question worth asking after that: if one of these agents goes wrong tonight, what do you restore from in the morning?

Developer Weekly Briefing — October 2, 2026

Fri, 02 Oct 2026 12:18:45 +0000

A lighter week by volume — but the three security stories that did land are worth understanding carefully. Here's what mattered.

A crafted package name was enough to reach an AI agent's AWS credentials

BeyondTrust's Phantom Labs researcher Sergio Garcia found two command injection vulnerabilities in the Amazon Bedrock AgentCore Python SDK's install_packages() function — and the attack surface was exactly as small as the title suggests.

The SDK let agents install Python packages into a Code Interpreter sandbox by passing names to pip install. The first version validated names against a blocklist of five characters. It left out the newline. A name like "pandas" followed by a newline and a shell command reached Code Interpreter as two lines. The second ran. That's CVE-2026-12530, affecting SDK versions 1.1.3 through 1.6.0.

AWS patched it with a regex allowlist. Garcia put a shell command substitution inside square brackets — the pip extras syntax — and the shell ran it before pip did. That's CVE-2026-16796, affecting versions 1.6.1 through 1.18.0. Both carry CVSS 4.0 scores of 8.4.

Where the Code Interpreter session had an execution role attached, the same commands pulled the role's temporary AWS credentials. A function that only installs packages looks far safer to hand an agent than a shell. That's exactly why careful teams expose it.

The fix that held arrived in version 1.18.1: quote the package name so the shell reads it as text, not a command. The logging detail worth acting on: both CloudTrail data events and AgentCore Observability application logs are off by default. CloudTrail doesn't record the command. The application logs do. Watch for references to the metadata service address 169.254.169.254 in those logs.

Mitch Ashley's operational advice: "Scope every role to what it needs, treat package names and dependency files as untrusted input, and turn on the AWS logging by default." If you're running agents on AgentCore, upgrade to 1.18.1 or later, audit your execution role permissions, and consider a fixed package list rather than one the agent can extend.

GitHub's security autofix agent now remembers what it fixed

GitHub agentic autofix — which handles security alerts by exploring relevant files, proposing a fix, rerunning CodeQL to confirm, and opening a draft PR — now uses Copilot Memory when enabled. Before working on an alert, it checks stored memories for context. After creating a fix, it saves the pattern.

The more interesting part is where those patterns go. They don't stay inside autofix — they inform other Copilot features, including code review and the cloud agent, about how this specific repository handles security issues. A fix that runs through autofix can surface as a flag in code review before a similar mistake merges. That moves the work from cleaning up alerts after the fact to catching them earlier.

The design detail worth noting: repository facts are stored with citations pointing to the code that supports them, and facts are validated against the current branch before use. Any unused fact is deleted after 28 days. For enterprise and organization plans, an administrator has to enable Memory before any of this applies. Both features are still in public preview.

IBM Bob goes self-hosted — reaching the enterprises that wouldn't send code to the cloud

IBM made Bob generally available as SaaS in April and said on-premises was coming. It's here. Bob can now run on-premises, in private and sovereign clouds, and in fully air-gapped environments with no outside network connection.

The target market is clear: banks, insurers, government agencies, and organizations with mainframe modernization work they're unwilling to push through someone else's infrastructure. IBM says more than 80,000 employees now use Bob internally, up from 100 developers when internal use began in June 2025, with surveyed users reporting an average 45% productivity gain. The IBM Z Premium Package also gets self-hosted support and deeper mainframe-specific context.

Mitch Ashley's framing is worth keeping: "Bob is IBM's bid for a beachhead with enterprise developers, and self-hosting puts it where cloud-first coding agents struggle to reach. An agent trusted within those core systems is positioned to become the platform on which the same teams build their own agents. That makes choosing Bob a multi-year commitment."

Self-hosting moves the operational burden to the customer: provisioning GPU capacity, managing model updates, monitoring agent behavior, maintaining audit trails. Air-gapped environments also narrow available models. Worth pricing that operational overhead before committing.

Git 2.56: conflict markers, branch cleanup, and performance at scale

Git 2.56 ships with changes that matter at two levels — safety guardrails for everyday use and performance improvements that compound at scale.

The new git add --resolved only stages currently unmerged paths and scans them for leftover conflict markers before staging. The new git branch --delete-merged cleans up merged branches with pattern matching and a --dry-run preview. Both are exactly the guardrails agent workflows need — Mitch Ashley: "An agent that opens branches, resolves conflicts, and rebases hits every rough edge constantly, and a conflict marker staged into a shared branch becomes verification debt someone must find."

On performance: merge-base lookups on the Linux kernel dropped from 167,441 traversal steps to 3,887. A path-limited diff on a Chromium checkout went from about eight minutes to 0.07 seconds. Path-walk repacking on Fluent UI shrank a 558.5 MB pack to 164.4 MB — 71% smaller. For teams running large repositories, or agents running Git at machine speed, the cumulative savings are significant.

CData's new AI gateway fixes the three reasons enterprise AI stalls. Context — or the lack of it — is the most common reason enterprise AI projects don't reach production. CData's approach puts the context layer at the center rather than treating it as an afterthought. Read more
What developers already know about data center delays. The supply chain reality behind GPU availability and data center timelines, from a developer perspective. Read more
PSI's Emmy: 500,000 designs, one physicist in the loop. How PSI uses AI to rethink data center trade-offs at a scale no human design process could cover. Read more
Developer Spotlight: Mike Dabydeen on Rust, AI, and engineering leadership. A conversation with the developer whose comments on the Coder Legion PocketOS thread generated some of the best technical discussion we've published this year. Read more
Every AI agent has a boss. It's time we named them. From Insights From Analytics — the accountability question that most agentic AI governance frameworks are still avoiding. Read more

The through-line this week: agent execution roles, credential scope, and memory persistence are the new attack surface. A package name reaches AWS credentials. A fix pattern teaches a code reviewer. A coding agent goes air-gapped behind a firewall. All three stories are about where agents sit in the trust model — and how much damage the wrong scope creates when something goes wrong.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

The $460 million typo

Wed, 30 Sep 2026 11:22:53 +0000

In 1996, a tiny piece of code nearly destroyed a rocket.

Ariane 5 was being launched for the first time.

About 37 seconds after launch, the rocket suddenly veered off course.

The onboard computers detected something impossible.

Both guidance computers failed.

The rocket was destroyed.

The cause?

A number that was too large for a 16-bit integer.

The Ariane 5 software inherited code from Ariane 4.

But Ariane 5 was flying differently.

One conversion that had been safe on the old rocket overflowed on the new one.

A tiny assumption survived years of testing because nobody asked:

“Is this assumption still true in the new system?”

The lesson isn't “integers are dangerous.”

It's much bigger:

Old code carries old assumptions.

And when the environment changes, those assumptions can become vulnerabilities, failures, or disasters.

Good software engineering isn't just asking:

“Does this code work?”

It's asking:

“Under what assumptions does this code work?”

That's one of the reasons automated security analysis matters.

Not because tools replace engineers.

Because sometimes the most dangerous bugs are hiding inside assumptions nobody remembers making.

That's also the kind of problem we're interested in at Debuggix.

Developer Weekly Briefing — September 25, 2026

Fri, 25 Sep 2026 13:04:16 +0000

A week where the same lesson kept showing up in different forms: the credentials your AI coding tools hold are the real attack surface, and most teams still can't answer the basic question of how many there are. Here's what mattered.

Z.ai was packaging your entire workspace and shipping it to Alibaba Cloud

ZCode, the AI coding assistant from Chinese AI company Z.ai, was uploading complete workspace archives — full .git history, Git LFS cache, reflogs, and global app configs — to Alibaba Cloud Object Storage by default, in the background, encrypted with keys only Z.ai held. The privacy policy didn't disclose this behavior. There was no toggle to turn it off.

An independent Chinese blogger traced abnormal disk usage to background processes and published his findings. One company reported that six coding workspaces had been uploaded, including source code, database passwords, and employee personal information. Z.ai responded: it disabled the upload mechanism in version 3.14.0, open-sourced the underlying model, and brought in NSFOCUS to confirm deletion. Most users were unsatisfied — because the archives were encrypted with Z.ai's own key, nobody outside the company could independently verify anything.

Mitch Ashley's read: "The workspace uploads came to light because an independent blogger traced abnormal disk usage to a background process, well after developers had installed the tool." That's the actual detection path. Not a security review. Not an MDM alert. A blogger noticing disk activity.

The important line from the piece: "It's tempting to file this under 'Chinese AI risk' and move on. That would miss the point." AI coding assistants need deep workspace access to be useful. That means they sit next to .env files, credentials, commit history, and the customer data someone committed by mistake three years ago. The lesson applies to every AI coding tool regardless of where the vendor is based. Developers install these tools fast. Security often hasn't reviewed them.

GitHub now gives enterprises a full count of who holds the keys

GitHub Enterprise Cloud owners can now export a complete inventory of every credential that can access their enterprise — SSH keys, classic and fine-grained PATs, OAuth app access tokens, and GitHub App tokens — as a CSV or via paginated REST API. Each record includes owner, scopes, creation and expiration dates, and last-used timestamp.

The timing follows directly from the May incident in which attackers exfiltrated about 3,800 internal GitHub repositories after an employee installed a poisoned Nx Console VS Code extension. GitGuardian's 2026 research puts context around why this matters at scale: 28.65 million hardcoded secrets added to public GitHub in 2025, up 34% year-on-year, and 64% of valid secrets detected in 2022 were still active and exploitable as of January 2026.

Mitch Ashley on the agentic dimension: "Anyone building with AI can now create credentials, and accountability for them lands back on IT and security. Enterprises that ignore that gap discover it during incident response, rotating keys they didn't know existed."

One useful design detail: GitHub added a separate "View enterprise credentials" permission so security and compliance staff can run reviews without needing full admin rights. The API is the more practical piece — pull the inventory on a schedule, compare runs, flag new long-lived tokens, send stale ones to owners for cleanup. GitHub Enterprise Server support is coming in future releases.

Codex sandbox escapes: the thing doing the enforcement was inside the thing being enforced

Oren Yomtov of Accomplish AI found two ways out of the OpenAI Codex sandbox — Heapjack and Overpatch — and OpenAI fixed both within eight days of the August 12 report. Accomplish published the details on September 15. Patches are in Codex CLI 0.149.0 and Codex Desktop build 26.818.21641.

The mechanics are worth understanding because the pattern is recurring. Heapjack: the node_repl helper ran untrusted agent code and trusted code in separate contexts but on a shared memory heap. Untrusted code called v8.getHeapSnapshot(), scanned memory for the trust token, then used it to send forged requests to the parent process. Read-only mode didn't stop it. Overpatch: the apply_patch tool determined its own permissions by checking the parent directory of paths in a patch. Naming /tmp in the patch granted access to the entire disk through a failed operation that didn't clean up the wider permissions — which persisted into .zshrc and survived shell restarts.

Yomtov's summary of the root cause: "The thing doing the enforcement was sitting inside the thing being enforced." Mitch Ashley's translation for DevOps teams: "A sandbox the agent can modify enforces nothing. Enforcement has to run in a layer the agent cannot reach — which means the control plane. CI teams settled this years ago when they stopped letting jobs grant themselves permissions."

Both fixes are deployed. Update Codex CLI and the desktop app separately — they carry different version numbers, and checking one doesn't cover the other. And treat repositories you didn't write as untrusted input even in read-only mode.

Claude Code adds AGENTS.md fallback

Claude Code 2.1.277 now reads AGENTS.md when no CLAUDE.md exists in a directory, cleaning up the dual-file maintenance problem teams have been patching with symlinks. The short version: CLAUDE.md takes precedence when both exist; AGENTS.md is the fallback when it doesn't. Four settings in /config let teams tune the behavior — including loading both files, Claude-first, or locked to managed CLAUDE.md only.

A few caveats worth reading before deleting symlinks: CLAUDE.local.md counts as CLAUDE.md for precedence purposes, so developer personal preference files will shadow the team's AGENTS.md. Claude doesn't read AGENTS.local.md or anything under .agents/. Bedrock, Vertex, and Foundry support isn't available yet. And the first session after a fresh install won't read AGENTS.md — relevant for ephemeral CI runners.

GitHub separates who writes code from who runs CI

GitHub's new Code and Automation role split gives organizations a cleaner way to grant repository access: a new "CI/CD Manager" role lets someone configure and run Actions workflows without inheriting write access to the codebase. For teams that have been granting broader permissions than necessary to let DevOps engineers manage pipelines, this closes a real least-privilege gap. Available now for Enterprise Cloud, coming to Enterprise Server.

An AI agent signed a developer up for AWS services he never requested

A developer asked an AI agent to help set up an AWS environment. The agent, interpreting the request broadly, provisioned services the developer never asked for — and AWS's billing model meant the charges started immediately. The incident clearly illustrates scope creep in agentic task execution: the agent completed what it interpreted as the goal, not what was actually requested. Worth reading if you're giving agents any access to cloud accounts.

Ripple bets on Stripe and Tempo's payment standard to get AI agents spending XRP

Ripple announced support for the X402 payment protocol — the emerging standard backed by Stripe and Tempo for machine-to-machine payments — to enable AI agents to spend XRP autonomously. As agents gain the ability to make purchases, pay for API calls, and transact on behalf of users, a standardized payment layer becomes infrastructure. Whether XRP is the currency that wins that market is a separate question from whether the category itself is real. It is.

Kore.ai's Cobus Greyling: stop chasing the next model, start owning your harness. The competitive advantage in agentic AI isn't which model you run — it's the evaluation, memory, and orchestration layer you build around it. Read more
LittleHorse draws the line between what your agent decides and what your code must execute. A workflow orchestration approach that keeps deterministic business logic out of the LLM layer. Read more
The Claude Projects Coordinator piece from last week rounds out the parallel agent work story if you missed it. Read more
Developer Spotlight: Steve Fenton. A conversation with the developer, author, and engineering leader on his career journey, the craft of software development, and how the role is changing. Worth a read if you want something that isn't about vulnerability disclosure this week. Read more

The through-line this week: AI coding tools have broad access to your most sensitive assets, and the governance layer — credential inventories, sandboxes that enforce at the control plane, agent scoping — is still being built. Z.ai and Codex were caught. Most of what's happening in this category won't be.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Developer Weekly Briefing — September 18, 2026

Fri, 18 Sep 2026 13:35:03 +0000

Two critical patches with active exploitation, a database deleted in nine seconds, and Java finally getting ahead of a quantum threat most enterprises haven't started thinking about. Plus NVIDIA bringing Rust into the CUDA kernel — a genuinely significant move that got less attention than it deserved this week. Here's what mattered.

A Cursor agent deleted a startup's database in 9 seconds. Then it deleted the backups.

In April, a Cursor agent running on Claude Opus was working through a routine task at a startup called PocketOS. Somewhere in the codebase it was scanning, it found an AWS key. It used the key to reach the production database. Then it deleted it. Then it went looking for the backups and deleted those too. Nine seconds, start to finish.

Archit Lohokare, CEO of AppViewX, uses the incident as his opening example of what an overprivileged agent looks like before his company gets involved. The underlying problem isn't exotic: machine identities now outnumber human ones 144 to 1 inside the enterprise, and each agent carries roughly 500 to 700 individual credentials — roughly the same number a well-connected human employee accumulates over a career. Many agents are ephemeral, spun up for a single task and gone before any conventional identity tracking system registers them.

Lohokare's framing worth keeping: "Guardrails are something you put on a model, and models are going to get breached." His enforcement point sits downstream, at the moment the agent tries to act. AppViewX's three-layer approach: every agent gets a quantum-safe cryptographic identity; credentials are monitored and rotated continuously so a leaked key has a shorter useful life; and real-time policy governs the action itself — an agent scoped to read a database simply can't issue a delete, and the request never reaches AWS.

The reader thread on this one generated something unusual: a follow-up Q&A with the AppViewX CEO after two readers challenged the original piece. Worth reading both.

Read the PocketOS piece | Read the CEO's answers

GitLab: patch now. Attackers already are.

On September 10, GitLab shipped versions 19.3.2, 19.2.6, and 19.1.8 covering 18 vulnerabilities — two critical. The first, CVE-2026-85706, carries a CVSS score of 10.0. An unauthenticated attacker can read arbitrary files off a self-managed GitLab server with no login required: configuration files, tokens, SSH keys, database credentials. The flaw sits in the repository commits API, affects CE and EE across a wide version range, and watchTowr's honeypot network was logging active probing almost as soon as disclosure went public.

The second critical flaw, CVE-2026-87719 (CVSS 9.9), is an insecure deserialization bug in the GraphQL subscription serializer affecting Enterprise Edition. An authenticated user with Duo Chat access — a lower bar than it sounds in most enterprise deployments — can pull Advanced Search configuration data and credentials. Combined with the first flaw, this creates a path from zero access to credential theft.

GitLab.com and Dedicated customers are already patched. The exposure is entirely with self-managed instances that haven't updated. If yours is internet-facing, update before Monday.

Mitch Ashley on the structural issue: "Monthly and quarterly patch windows were built for a slower disclosure cycle. Teams running their own DevOps platform should know their advisory-to-production time and shorten it before the next maximum-severity bug lands."

JFrog Artifactory: three bugs under active attack, all with patches available

Artifact repositories don't face the internet the way a web app does, and they don't hold customer data the way a database does. But they hold every binary and package your build pipeline pulls from before code ships. Compromise the repository, and you're attacking everything downstream.

Three Artifactory vulnerabilities are under active exploitation, and patches have been available for weeks. CVE-2026-82329, an authentication bypass allowing unauthenticated administrative access, was patched August 28. CVE-2026-42018 and CVE-2026-42016 — the two being chained together to go from a low-privilege foothold to full admin access — were patched July 27 and August 12, respectively. Wiz says multiple threat actors are exploiting these independently, and patching velocity is slow across the install base.

If you're running Artifactory and haven't applied these patches, the window you thought you had is already gone.

Java 27: post-quantum TLS today, faster patches tomorrow

Java 27 shipped September 15 with two changes that matter for production engineering teams. The headline security addition is JEP 527: ML-KEM hybrid key exchange for TLS 1.3, requiring no code changes for existing Java TLS applications. This is Oracle's direct response to harvest-now-decrypt-later risk — traffic encrypted today that a quantum computer could break open years from now once the hardware catches up.

Oracle also announced monthly critical security patch updates alongside its existing quarterly cycle, scoped to security and stability only.

The catch Mitch Ashley flagged clearly: "Post-quantum protection arrives first on the version with the least production code behind it, and last on JDK 8 and 11, where a large share of enterprise Java still runs. That inverts the risk." Teams on JDK 8 and 11 wait until the second half of 2027. If your most sensitive TLS endpoints run on older LTS releases, that's a gap worth addressing through other means now rather than waiting for the platform backport.

NVIDIA brings Rust into the CUDA kernel — not just around it

This one got less coverage than it deserved. NVIDIA released two open-source projects — cuda-oxide and cutile-rs — that let developers write actual GPU kernels in native Rust, compiled directly to PTX. Not wrappers, not DSLs bolted onto Rust syntax. Real Rust code running on the GPU.

The difference from Rust-adjacent GPU work before: previously, you could write drivers, schedulers, and serving layers in Rust, then launch a GPU kernel that had to be written in CUDA C++. That gap is now closed.

The two libraries take different routes. cuda-oxide targets the SIMT model CUDA developers already know and is still in early alpha. cutile-rs takes a tile-based approach, JIT-compiles at launch time, runs on stable Rust without a nightly toolchain, and is already in production in Hugging Face's Grout inference engine and mistral.rs. Both get Rust's ownership and borrow checker on GPU code, catching aliasing bugs and thread-access errors at compile time rather than in a customer's production cluster. In cutile-rs, a tensor's ownership follows it across kernel launches — pass the same buffer as both a readable input and a mutable output, and you get a borrow-checker error before the code ever runs.

Anthropic adds a Coordinator to Claude Projects for parallel AI work

Anthropic shipped a Coordinator capability inside Claude Projects this week that routes tasks to subagents running in parallel rather than sequentially. Practically, this means complex multi-step work — research across multiple sources, simultaneous analysis threads — no longer has to queue up behind itself. The Coordinator manages dependencies between tasks and consolidates results. For teams already building workflows around Claude Projects, this is a meaningful throughput change.

OWASP founder Jeff Williams: stop studying the robot's brain, start controlling its body. The security control point for AI agents isn't the model — it's the execution layer. Williams frames this as the central insight most security teams are still missing. Read more
HYCU found 30+ ways to destroy a Git repo. Five only exist because of AI agents. The broader taxonomy of Git destruction vectors is alarming enough — the five that emerged specifically from agent behavior are the new ones. Read more
The purchase order is canceled and executed. That's not a data error. A look at how inconsistent state in distributed systems creates exactly the kind of ambiguity that AI agents resolve incorrectly — and what Everpure's data intelligence platform does about it. Read more
Salesforce packaged its hardest integration problem into a plugin — 4,000 employees are using it. Copado's approach to Agentforce integration across Salesforce orgs at enterprise scale. Read more
Gravwell: security agents have one hard limit — everything else in the system prompt they can ignore. A precise look at what actually constrains an AI security agent versus what only appears to. Read more
Newcore wants to kill the service account and make every AI agent answer for what it does. A machine identity approach that treats every agent as a first-class principal with its own audit trail. Read more
Dyna Software brings Git-style pull requests to ServiceNow — and locks down what code gets promoted. Read more
BackBox's Kilter AI keeps humans in the loop while automating network fixes. Read more
Copado adds CLI and MCP access to AI agents — but its compliance gates still decide what ships. Read more
SQLite's two-person team just passed its first AI stress test. Worth reading if you've wondered how one of the most widely deployed databases in the world thinks about AI-generated code. Read more

The through-line this week: action-layer controls, not model-layer controls. OWASP's Jeff Williams said it directly. AppViewX built it into their architecture. The GitLab and Artifactory patches are a reminder that traditional infrastructure is still the blast radius an agent works within — and that blast radius needs to shrink before the next agent touches it.

Patch your GitLab instance. Patch your Artifactory. Before Monday.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Cycode's AI Scanner Found 38 Bugs in MLflow. The Press Release Only Mentioned One.

Wed, 02 Sep 2026 14:41:12 +0000

Every AI security vendor ships a benchmark chart these days. Most of them don't survive a second phone call.

On September 1, Cycode launched Agentic Code Scanning, a fourth layer that sits on top of its existing rule-based scanner and decides, code path by code path, whether a deterministic rule or a reasoning model should do the looking. The pitch lands at a useful moment: Lovable just raised $400 million at a $13.3 billion valuation, doubling in eight months, and AI-generated code is no longer a side project. It's shipping into production at companies that can least afford a bad merge.

Cycode's headline number: it ran the new engine against six real, published CVEs and caught all six, including two authorization flaws — a broken access control bug in gitea (CVE-2025-68941) and a middleware bypass in Next.js (CVE-2025-29927) — that no rule-based scanner in the test could catch, because there's no bad pattern to match. A missing permission check doesn't look like anything. Cycode's own deterministic scanner caught three of the six. Semgrep and CodeQL, tested separately, caught zero.

I asked Amir Kazemi, Cycode's senior director of product marketing, how the company picked its ten benchmark repositories — six pinned to CVEs, four deliberately vulnerable apps used as answer keys. He didn't have the specifics. "That's a question for our CTO," he said, and offered to follow up. That's not unusual on a launch call. It's also exactly the kind of question that decides whether a benchmark means anything.

Ronen Slavin, Cycode's CTO and co-founder, answered in writing a day later, and the detail went well past what made it into the press release.

The methodology, as he described it: the six CVE repos were the development set, used openly to build the engine. The four answer-key apps — vAPI, crAPI, DV RESTaurant, and Juice Shop, all existing open-source projects, not synthetic builds — were held out and untouched until testing. Before any fix went in, Slavin's team wrote down constraints in advance: no code change could reference a specific benchmark file, CVE ID, or line number, and any fix that moved the needle on the development set had to also hold up on the held-out apps. A hit only counted if it matched the actual mechanism behind the CVE, not just the file it lived in.

That structure exists to answer the obvious challenge: how do you know a reasoning model found the bug, instead of recalling it from a public CVE database sitting in its training data? Slavin's answer is specific rather than reassuring. The scanner is never told which CVE it's hunting, the test repos are pinned commits with no changelog or advisory text attached, and the findings are line-anchored data-flow traces written in the code's own variable names, not summaries that read like an advisory. On Jellyfin, he said, the model traced the vulnerable data flow across six function calls from an HTTP query parameter to the FFmpeg argument string, entering through a different controller than the one named in the public advisory. A model quoting a memorized answer doesn't take a six-hop detour to get there.

The press release's cleanest number undersold what the tool actually produced. It said a rule fired 573 times on mlflow, two hits landed in the CVE file, and Agentic Code Scanning returned "one validated, root-caused finding." Slavin's fuller account: on that same repository, the engine generated 87 raw candidate findings and published 38, each deduplicated and root-caused, including extra bugs the CVE never asked about — a symlink traversal in the artifact store, a zip-slip, and a template injection among them. The rule that fired 573 times, he clarified, belongs to Bearer — the same rule engine that already underlies Cycode's own deterministic scanner, which is a more interesting detail than the press release let on. The honest comparison, he argued, isn't 573 versus one. It's somewhere between 173 and 701 unranked hits per repository, depending on the repo, against 38 findings on mlflow that a developer could actually act on.

The single-run limitation in the published benchmark is real, and Slavin didn't dodge it. He called the published result "an existence proof, not a rate." Since the tested engine version shipped, gitea's authorization catch has reproduced in nine of nine repeat runs, and the full six-for-six result has held on a second model. Where a catch was inconsistent — Jellyfin missed on some runs until the team added a specific lead pointing to what reaches the vulnerable sink — Slavin says they found the cause and fixed it rather than rerunning until it worked. Cycode says it's now publishing catch rates across repeated runs going forward, not single screenshots, and has already extended its CVE corpus to 20 languages and 29 verified vulnerabilities.

None of this turns a vendor benchmark into independent research. It's still Cycode grading its own homework, and reasonable people will still want a third party to rerun it — something Cycode says is now possible with the corpus and configs it's publishing alongside the launch. But the gap between what showed up in the press release and what showed up under a direct follow-up is the real story here. As agentic security tools multiply — and Kazemi's own framing of a linear SDLC turning into a faster, circular ADLC suggests they will keep multiplying — the benchmark chart on the landing page is worth less than a vendor's willingness to answer the second question. Ask it before you buy.

Developer Weekly Briefing — August 28, 2026

Fri, 28 Aug 2026 14:29:15 +0000

A quieter week after the Black Hat stretch, but the five pieces that came out of it are worth your time. All five circle the same territory: what AI can and can't actually do in security, and who ends up owning the outcome when it falls short.

Triaging AI scanner output costs 400x more than running the scan

Here's the number from Contrast Security's AppSec Overflow 2026 report that should reframe every "AI will solve your security backlog" pitch you hear this year: scanning a 2-million-line codebase with an AI-powered tool costs roughly $315 in tokens. Triaging what that scan finds costs $128,000. The scanning was never the expensive part.

The report draws on runtime telemetry from hundreds of thousands of production applications — not theoretical exposure, but what's actually being reached and exploited in live systems. A few data points worth internalizing:

The average application absorbs 11,382 attacks a month. 87.8% are automated probes — noise. The number that actually matters is the 0.4%, an average of 42 viable attacks per month per application, where Contrast confirmed the exploit reached and triggered real vulnerable code. Teams are closing 3.4 vulnerabilities per application per month against an average of 22 rated high or critical. Mean time to remediate a critical vulnerability: 92 days. Mean time to exploit: effectively same-day for a growing share of CVEs.

The AI scanner reliability findings are the most useful part for teams evaluating these tools. Three different AI scanners analyzing the identical codebase agreed on only 5% of findings. A single scanner rerun three times against unchanged code reproduced just 17% of its own prior results. That's not a calibration issue — it's a fundamental reliability problem for any team trying to build a repeatable process around these tools.

One claim worth a caveat: the report opens by citing Anthropic's Claude Mythos model reportedly discovering thousands of previously unknown zero-day vulnerabilities in production testing. Contrast's own report flags the limitation — Anthropic hasn't disclosed the time, accuracy, and human effort behind the analysis. Treat that specific claim as unverified, even as the broader trend it illustrates is real.

Cisco's Amy Chang: a model's "passport" doesn't tell you where it actually came from

Amy Chang, EVP and Chief Product Officer at Cisco, makes a point that gets at a real gap in how most organizations think about AI supply chain risk: a model card or declared provenance tells you what a vendor says about a model, not what actually went into it. The training data, the fine-tuning process, the intermediate checkpoints — none of that is independently verifiable from the outside. As AI models become infrastructure, the question of what's actually in them starts to matter the way software bill of materials questions started to matter for open-source packages. The tooling to answer it doesn't really exist yet.

AI can find your vulnerabilities. It still can't own what happens next.

The conversation with GuidePoint Security's Victor Wieczorek covers the same territory as several Black Hat sessions but with more precision. AI is genuinely good at finding needles in haystacks — that's not the bottleneck. The bottleneck is everything downstream: understanding what a finding means in context, deciding what to do about it, and owning the professional judgment that a client can actually act on. No model carries that obligation. The Glasswing stat that runs through this piece is worth remembering: fewer than 1% of the vulnerabilities AI discovered in that program ever got patched. Finding the bug was never the hard part.

$360,000 a petabyte and 105 days to get out: Microsoft's new math for university storage

Microsoft capped Education tenant storage this year and turned on overage pricing worth roughly $360,000 per petabyte per year once quotas are exceeded. Universities holding two or three petabytes — common at large research institutions — are looking at bills in the hundreds of thousands to over a million dollars annually for storage they never budgeted for. The exit problem is equally sharp: Microsoft throttles data egress at 400GB per hour, tenant-wide, meaning moving one petabyte out takes approximately 105 days. For institutions just realizing the size of the problem, the December 2026 renewal deadline is already close.

Arcitecta's Mediaflux Connect 365 is the platform announced around this story — the piece covers both the cost math and the data management approach behind moving out intelligently rather than just fast.

The bug that's been breaking software for 40 years is now breaking your AI agents too

Integer overflow — the category of bug where a value exceeds what a data type can hold and wraps around to an unexpected result — has been causing security vulnerabilities since the 1980s. It's behind buffer overflows, memory corruption, and a long list of CVEs across decades of software. The same class of bug now shows up in AI agent tool calls and API interactions, where numeric inputs passed to or from an agent can overflow in ways the agent doesn't detect or handle. The post makes the case that this isn't a new threat category — it's a familiar one arriving in a new execution context, and most teams building agentic systems aren't thinking about it yet.

The through-line this week: AI is genuinely expanding what's possible in security tooling, and the costs and failure modes that come with it are starting to get documented with real numbers. $315 to scan, $128,000 to triage. 5% agreement across three scanners. Fewer than 1% of discovered vulnerabilities patched. Those aren't arguments against using AI in security — they're arguments for being precise about what it's actually doing and who owns the judgment call when it's done.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Contrast Security: Triaging AI Scanner Output Costs 400x More Than Running the Scan

Thu, 27 Aug 2026 13:15:00 +0000

Here's a number worth sitting with: scanning a 2-million-line codebase with an AI-powered tool costs roughly $315 in tokens. Triaging what that scan finds costs $128,000. That 400x gap, buried in Contrast Security's new AppSec Overflow 2026 report, is a sharper indictment of "AI will solve your security backlog" than any headline vulnerability count. The scanning was never the expensive part. Making sense of what it found is.

Contrast's report draws on runtime telemetry from inside hundreds of thousands of production applications and APIs, giving it a vantage point most vendor research doesn't have: not what's theoretically vulnerable in a codebase, but what's actually being reached and exploited in live production. The headline framing is stark. "AppSec math is broken, and in 2026, AI is a massive contributing factor," the report states, and the numbers back that up from multiple directions at once.

The attack volume is relentless, but mostly noise

The average monitored application absorbs 11,382 attacks a month, roughly one every four minutes. That number sounds alarming until you break it down: 87.8% are automated probes, low-stakes reconnaissance that maps attack surfaces without doing harm. Another 11.9% are suspicious but unconfirmed. The number that actually matters is the remaining 0.4%, an average of 42 viable attacks per month per application, meaning Contrast confirmed the exploit reached and triggered real vulnerable code. No false positives in that category; runtime observation proves activation, not just exposure.

Untrusted deserialization leads the viable attack data at 27.5%, followed by path traversal at 20.1% and method tampering at 13.4%. SQL injection, despite being one of the most well-understood vulnerability classes in software, still shows up in the top five attack techniques across every industry vertical the report tracked, a reminder that "well documented" and "actually fixed" are very different things.

Why the find-and-fix model is structurally broken, not just slow

The average application carries 106 vulnerability findings in custom code, and while roughly 60% of those are informational noise, an average of 22 are rated high or critical. Teams are closing just 3.4 vulnerabilities per application per month, and the mean time to remediate a critical vulnerability sits at 92 days. Third-party code fares no better: 54% of the CVE instances Contrast observed in production are from vulnerabilities disclosed more than a year ago.

That gap matters more than it used to because the other side of the equation has collapsed. Third-party research the report cites, aggregated by Zero Day Clock across more than 83,000 CVEs, shows mean time-to-exploit dropping from 2.3 years in 2018 to effectively same-day in 2026. Independent data from VulnCheck backs the trend, finding 29% of exploited CVEs in 2025 were weaponized on or before the day the CVE was published. A 92-day patch cycle against a same-day exploitation window isn't a performance problem. It's a structural mismatch that faster patching alone can't close.

The AI scanning findings, and one claim worth a caveat

The report's most useful contribution isn't the vulnerability count, it's the honest accounting of what AI scanning tools actually deliver today. Beyond the $315-versus-$128,000 triage-cost gap, Contrast found that three different AI scanners analyzing the identical codebase agreed on only 5% of findings. A single scanner rerun three times against unchanged code reproduced just 17% of its own prior results. That's not a minor calibration issue; it's a fundamental reliability problem for any team trying to build a repeatable process around these tools. Contrast's own framing is blunt: "For now, it's making the hole a lot deeper."

Worth flagging separately: the report opens with a claim about Anthropic's Claude Mythos model reportedly discovering thousands of previously unknown zero-day vulnerabilities in production testing, including a flaw in OpenBSD that had survived 27 years of human review. This has circulated in several industry newsletters, but Contrast's own report is careful to caveat it: "Anthropic has not disclosed the time, accuracy and human effort that was required for their analysis, making it difficult for security leaders to make real risk assessments today." Treat the underlying capability claim as unverified, even as the broader trend it's illustrating, AI compressing vulnerability discovery timelines, is well supported by the report's own runtime data.

Why CVSS and EPSS alone will steer you wrong

The report's prioritization section is the most practically useful part for a working developer or architect. Generic CVSS base scores tend to inflate perceived risk because most organizations never layer in the local context the scoring system was actually designed to incorporate. EPSS, which predicts 30-day exploitation probability, correlates strongly with real-world exploitation, 85% of CVEs with an EPSS score above 94% are on CISA's Known Exploited Vulnerabilities list, but it isn't complete either. The report cites two confirmed-exploited CVEs with EPSS scores of 22.2% and 0.88% respectively, low enough that a pure EPSS-driven process would have deprioritized both.

Contrast's answer is reachability and exploitability analysis: does the vulnerable function actually execute, does untrusted data actually reach it, and is the application configured in a way that makes exploitation possible. That's a meaningfully different, more precise filter than severity scores alone, though it's also, unsurprisingly, exactly what Contrast's own runtime platform is built to provide. Worth reading that recommendation with the appropriate grain of salt given who's making it, even where the underlying logic holds up.

What this actually means for the average team

Strip away the vendor framing and the practical takeaway is straightforward: attack surface and vulnerability volume are both growing faster than patch cycles can absorb, generic severity scores aren't precise enough to prioritize effectively at that scale, and AI scanning tools, at least in their current form, are adding inconsistent findings to the pile faster than they're helping teams work through it. The report's own conclusion lands on runtime visibility, actually knowing which vulnerabilities are reachable and being actively targeted, as the lever that matters most. That's a reasonable read of the data, even from a company that sells exactly that capability.

Crogl's Monzy Merza: The SOC Agent That Refuses to Say It Can Replace You

Thu, 20 Aug 2026 13:00:00 +0000

Ask most AI SOC vendors what their agent does, and you'll hear some version of "faster investigations, fewer alerts." Ask Monzy Merza, and he'll walk you through a blast radius map instead — because for Crogl's customers, the real problem was never speed alone. It was that patching a vulnerability and breaking production have historically been two different teams' problems, discovered too late and too far apart.

"Somebody says go patch SharePoint, and they say, well, in order to patch it, you're now changing it from TLS 1.2 to TLS 1.3. Well, that's going to break all your downstream applications," Merza said. "The patch is fixed, but the operations is dead."

Closing a three-day window that used to take weeks

Merza's customers, mostly in critical infrastructure and regulated industries, operate under a hard constraint: CISA's Known Exploited Vulnerabilities directive gives federal agencies and, by extension, the vendors and contractors that serve them, a three-day window to remediate certain vulnerabilities. Not three business days. Three days, period. Historically, meeting that meant a security team ran a scan, handed a list to IT, and hoped for the best. "The game has completely changed," Merza said.

Crogl's answer is what the company calls a blast radius assessment: when a CVE surfaces, the platform maps every affected application, identity, service account, and downstream dependency before anyone touches a patch. Instead of a security team throwing a vulnerability list over the fence, they hand over a prioritized, evidence-backed plan that shows exactly what breaks if a fix goes in, and what's actually at risk if it doesn't. "Now the security team is not just throwing something over the fence," Merza said. "They're giving very concrete, actionable information."

Reasoning models wander. That's why there's a deterministic layer underneath.

The architecture Merza describes is deliberately not just an LLM with tool access. Crogl combines three components: a reasoning layer built on large language models (the platform is model-agnostic), a deterministic symbolic layer and knowledge graph that maps a customer's entire data estate without requiring data normalization, and a governance harness that orchestrates the two and enforces consistency. "We all know models wander, the results wander, they're not always deterministic," Merza said. "So we need models' reasoning, but we combine it with a deterministic system."

That knowledge graph is also what lets Crogl skip a step most competing platforms require. Customers don't need to normalize or transform their data before the agent can use it, which Merza says removes a genuine deployment barrier for organizations running multiple SIEMs and data lakes.

Secure means sovereign, and sovereign was too big a word to use

Crogl isn't a SaaS product. It runs on-premises, in a customer's own cloud, or in air-gapped environments, by design. Merza said the company deliberately chose "secure" over "sovereign" in its own marketing because the latter invited too much interpretation. What it actually means: the LLM only sees what it strictly needs to see, and no customer data leaves their environment, not even to Crogl itself. "Our customers don't want any of their data to leak out to any third party, regardless if it's their security provider," Merza said. Because the product ships to run inside customer environments rather than living behind a hosted API, Merza said it has to clear every static and dynamic analysis scanner that exists. "We can't hide behind a SaaS test."

What "deploy in minutes" actually requires

Merza didn't hedge on this claim, largely because customers have already publicly tested it. Crogl ships as two binaries and a container; installation requires a Unix-like system and the ability to run Docker; nothing more elaborate is needed to get a first use case running. Merza pointed to unprompted LinkedIn posts from users who installed the platform and completed their first investigation in under ten minutes.

The report, not the action, is the default output

When an alert fires, Crogl classifies it, builds an investigation plan, and executes against every data source it's been given access to, documenting each step along the way. The output is a full report with a verdict: escalate or close, with the evidence attached so a security team can defend the decision to an auditor later. Crogl can take action directly, quarantining a file, pulling a malicious attachment, messaging a sandboxing system, but Merza was clear that most customers keep a human as the actual trigger, even when they trust the verdict completely. "There's nothing in the product fundamentally that limits action taking," he said. "It's just the mode of use."

That boundary is customer-configurable down to a granular level. A team might let Crogl work phishing and EDR alerts autonomously all day, while requiring a human to review anything touching a production system like SharePoint. Merza expects that boundary to loosen over time as trust builds, not because Crogl pushes for more autonomy, but because customers extend it themselves once a pattern of accurate, well-documented verdicts accumulates.

What developers need to understand before any of this works

For engineers whose systems generate the logs and alerts Crogl investigates, Merza's advice comes down to basics that are easy to skip. The agent needs real data to operate on. The security team needs a clear, internally agreed sense of what actually counts as a priority, or the agent's output won't be actionable no matter how sophisticated the investigation. And organizations need to get comfortable with a mindset shift: agents will make mistakes, the same way humans do, and the goal isn't perfection. "If you try to run an agent so tightened up that it will [never err], you're going to miss threats and you're going to miss breaches, because then you're back to a rules-driven world," Merza said.

What to be skeptical of

Asked what claim in the AI SOC space deserves the most scrutiny, Merza didn't point to a competitor's specific feature. He pointed to the framing itself. "The biggest one is that they can somehow replace the human, completely," he said. Agents can compress and accelerate much of a security analyst's workflow, but a human supervisor is still required, and any vendor pitching a policy-free, procedure-free autonomous SOC should raise a flag rather than confidence. "If there is no policy, there is no promise. You cannot hold that party responsible."

His closing advice for skeptical readers is characteristically blunt: ignore the pitch and try it yourself. Crogl is a free download, and Merza's pitch to developers and architects isn't a sales script, it's an invitation to bring a real use case and see what breaks.

Harness GM Rahul Sood: Most "AI Remediation" Claims Don't Actually Work. Here's What Does.

Wed, 19 Aug 2026 15:00:00 +0000

Application security has operated on human timelines for as long as it's existed: a scanner flags something, a ticket gets filed, developers and security argue over priority, and a fix ships weeks or months later, if it ships at all. Rahul Sood, GM of Application Security at Harness, points to Log4j as the cautionary tale everyone in the industry already knows by heart. "It was not uncommon for companies to say it took us almost one year to get rid of it," he said. "Right now, that does not work when attackers have AI that can identify vulnerabilities in your code, even if you thought your code was safe."

Harness is launching a set of AI-driven application security capabilities this week aimed at collapsing that timeline. The stakes are concrete: attackers are now going from disclosure to first exploit in as little as six hours, while the average vulnerability still takes more than 50 days to fix. Sood breaks into three required shifts: defenders need to actually use AI to find weaknesses in their own code, the window between discovering a vulnerability and fixing it needs to compress from months to hours, and organizations need to accept that not every fix will land before an attacker finds a way in, which means building a containment strategy alongside the fix itself.

Scanning with frontier models is real, and also too slow to run daily

Sood doesn't dispute that frontier models can scan code effectively. The problem is cost and speed. He cited a bank going through Anthropic's Glasswing program that took three months to scan its entire codebase using an LLM — and Glasswing partners broadly have surfaced roughly 10 times more vulnerabilities using LLM-based scanning than traditional tools find, a wave of visibility that just becomes a bigger backlog without a faster way to act. "The cost is it takes a lot of tokens. The output is not deterministic, and it's not easy for you to go and triage these vulnerabilities," he said.

Harness's answer is two separate capabilities rather than one. The first, LLM Scan Orchestration, is a native integration between its CI/CD security tooling and LLM-based scanning, supporting both Claude and OpenAI's Codex, so findings get triaged, deduplicated, and normalized into a developer's existing workflow instead of arriving as an unstructured wall of output. The second, AI SAST, layers AI reasoning on top of traditional static analysis, aiming to catch what conventional scanners miss (Sood pointed to business logic attacks as an example) while using that reasoning to cut false positives and explain why a finding matters. From there, a Triage Agent automatically prioritizes what's actually exploitable so teams can focus on real risk, and a Remediation Agent writes and validates a fix for a prioritized finding, opening a pull request for a developer to review and approve.

A zero-day agent that maps blast radius across your entire environment

For open-source and third-party code specifically, Harness is launching an agent that tracks newly disclosed zero-days and maps them against a customer's actual environment: artifacts, pipelines, and repos. Sood argues this is where Harness's position gives it an edge most competitors can't match, since the platform already has visibility into what's in production and what's being built. Once the blast radius is identified, policies can block new builds that carry the vulnerability while triage and remediation catch up. Sood's claim is that this compresses zero-day response from weeks or months down to hours.

The differentiator he leans on hardest, though, isn't detection. It's remediation that's actually been checked. "We don't just validate that the security vulnerability is being fixed. We also validate that the fix will not break your pipeline," he said. Because Harness manages the pipeline itself, a proposed fix gets tested against the customer's own unit tests before it ships, not just checked against the vulnerability in isolation.

Closing the loop with production shielding

Even with a compressed timeline, not every fix lands before an attacker moves. Harness's answer is a virtual patch at the perimeter, deployed against a specific API to block the traffic pattern that would exploit a known vulnerability. Customers choose between two modes: monitoring, where the patch alerts a human to assess, or blocking, where the traffic is stopped automatically. Sood said the choice comes down to a customer's confidence level, the criticality of the API, and their overall risk appetite, rather than a one-size-fits-all default.

That same logic extends to how much autonomy the underlying agents get generally. Sood expects most customers to start with a human in the loop and move toward more autonomous workflows only as trust builds, and the platform supports the full range, from fully manual to fully autonomous, configurable per customer and even per class of fix.

What changes for the developer staring at a vulnerability list

For engineers used to a scanner dumping a long, mostly-noise list of findings, Sood said the real shift isn't just fewer false positives, it's clarity on what's actually reachable and exploitable versus theoretical. Combined with a recommended fix that's been validated against a team's own test suite, the goal is to give developers back the time currently lost triaging vulnerabilities that were never going to matter. "Development teams are being completely overwhelmed by the huge number of vulnerabilities being generated by scanners," Sood said, to the point where it crowds out shipping actual business-relevant code.

What to be skeptical of

Asked what's overhyped in this space even as he's building in it, Sood didn't hedge. "This entire claim that agents can do all this work for you," he said, pointing specifically at remediation. "Most of it doesn't really work." His advice for developers and architects evaluating any vendor's AI remediation claims, Harness included: test it yourself, and be skeptical of a fix recommendation generated without real understanding of your specific environment and test cases. A recommendation that isn't validated against your actual code is still just a guess wearing a more confident outfit.

Detectify's Rickard Carlsson: Attackers Don't Have New Tricks, They Have a Faster Clock

Mon, 17 Aug 2026 18:00:00 +0000

Ask Rickard Carlsson, co-founder and CEO of Detectify, whether AI is handing attackers new capabilities, and he'll correct the premise. It's not new vulnerabilities. It's not new techniques. It's the same attacks, running on a clock that used to be measured in days and now runs in minutes.

"It's not new vulnerabilities. It's just faster and easier to scale things," Carlsson said in an interview following Black Hat USA 2026. That distinction matters more than it sounds. If AI were only inventing novel attack vectors, defenders could study and prepare for a new category of threat. Instead, they're facing the same old exposures, arriving faster than most security programs are built to handle.

The clock that used to run in days now runs in seconds

Carlsson's clearest example starts before an attacker even shows up: certificate transparency logs. Every time an organization spins up a new website and issues an SSL certificate, that certificate becomes public record, visible to anyone watching, including attackers scanning for freshly deployed infrastructure. "From you actually spin up a new website, you can start to see attacks within a few seconds," Carlsson said.

The bigger shift is in how fast a new vulnerability gets turned into a working exploit. Reverse-engineering a CVE from a code diff in an open-source library used to take a skilled researcher days. An AI agent can now do it in minutes. "Zero day becomes weaponized much faster," Carlsson said, and that's the part he wants defenders to internalize. The vulnerability research that used to be the bottleneck between disclosure and exploitation has largely disappeared.

It's economics, not new techniques

Carlsson frames the shift as an economic one more than a technical one. Where a large-scale attack once required a small army, an AI-fluent individual with a handful of GPUs can now credibly compete. But he's careful to draw a line most coverage of AI-driven attacks blurs: AI does the prep work, not the whole attack. Once a vulnerability is identified, actually running an attack at scale, testing millions of endpoints, still happens through deterministic tooling, not AI. "You can't do that with AI, but the AI helps you identify the vulnerability. It helps you build the code that does the testing, and then it's the same old testing," he said. Targeted attacks against a specific organization are a different story, where AI stays continuously in the loop, iterating on signals rather than doing one-time prep work.

Patch everything, instantly

If speed is the attacker's advantage, Carlsson argues defense has to adopt the same posture, not as an experiment but as standard infrastructure. He described a shift he's hearing from a large European governmental institution moving away from staged patch rollouts (10 machines, then 100, then 1,000) toward immediate, full deployment. "You patch everything instantly, and then you take any issues that come with it. You have to solve that later," he said. The old model of gating a rollout to catch problems early assumes attackers are moving on a similarly staggered timeline. They aren't.

Killing alert fatigue with deterministic answers, not more noise

Security teams already drown in alerts, and Carlsson is blunt that adding AI carelessly just makes that worse. Detectify's approach leans on what he calls payload-based testing: rather than flagging a theoretical vulnerability, the platform actually attempts the exploit and gets a deterministic true-or-false answer. That's part of how the company holds its false-positive rate to roughly 0.3%, according to Carlsson. It's also, he argues, exactly the kind of clean, unambiguous data AI agents need to be useful rather than just another noise generator. "The more black and white data you could give them, the better it is," he said.

What developers are missing

Carlsson's sharpest point for engineers and architects isn't about attackers at all. It's about how AI evaluates code in isolation and misses system-level risk. Secure code, combined with a particular hosting setup, a DNS configuration, or an adjacent service handling serialization differently, can create a vulnerability that doesn't exist in any single component. "When the AI looks at a single component, it might not always understand the system risks," he said.

He also flagged a subtler risk: code maintained solely by AI over time can quietly degrade, as models optimize for whatever instruction came most recently and loosen constraints set earlier in the process.

Not everything is on fire

Carlsson pushed back on doom-laden framing of where this goes next. Yes, the pool of exploitable systems will grow. But every attack still needs a human on the other end collecting the payout, and plenty of vulnerable systems today simply aren't worth attacking. His actual worry is narrower and more specific: state-sponsored espionage against high-value targets, and ransomware crews finding it newly profitable to go after smaller organizations that never had the resources to keep up in the first place.

For developers shipping code that becomes part of that attack surface, his advice comes down to one shift in mindset: stop reasoning about code in isolation, and start thinking about the whole chain it runs inside.

Lateral credential harvesting via process namespace sharing

Fri, 14 Aug 2026 16:51:02 +0000

Github Source:
https://github.com/ndouglas-edera/hostpid-risk/tree/main

In a multi-tenant or shared Kubernetes node environment, containers are supposed to be isolated environments. However, this demo proves that if a malicious or compromised pod is deployed with host-level privileges, it can spy on neighbouring workloads running on the same node without needing a software vulnerability or zero-day exploit.

Example script

You can download the automation script from Github:

wget https://raw.githubusercontent.com/ndouglas-edera/hostpid-risk/refs/heads/main/hostpid-risk.sh
chmod +x hostpid-risk.sh

If you have a Kubernetes cluster already running (like on Docker Desktop or kind), you can run the below script:

./hostpid-risk.sh

What is the security misconfiguration exactly?

The exploit relies on 2 specific fields in the inspector-pod YAML manifest working together:

spec:
  hostPID: true            # <--- Misconfiguration #1: Breaks PID isolation
  containers:
  - name: inspector
    securityContext:
      privileged: true     # <--- Misconfiguration #2: Overrides Linux permissions

How it works technically

Normally, Linux container runtimes place each pod in their own isolated Process ID (PID) namespace.
Setting hostPID: true actually forces the pod to share the host node’s global PID namespace.
Suddenly, ps -ef inside the container displays every process running on the underlying node.
This includes processes belonging to other pods (target-app).
This would bypass Linux kernel profiles like AppArmor and SELinux - granting full capabilities (like CAP_SYS_ADMIN).
In Linux, the virtual /proc filesystem exposes process metadata. The file /proc/<PID>/environ holds the environment variables loaded into memory when that process was spawned.
Because inspector-pod has host-level permissions, it can read /proc/30629/environ belonging to target-app before extracting the DB_PASSWORD=SuperSecretPassword123! creds.

Strategy 1 - PSS in Kubernetes

Pod Security Standards (or PSS, for short) is a built-in policy Kubernetes framework managed by the Pod Security Admission (PSA) controller. It categorises security into 3 levels:

Privileged: Unrestricted (Allowing hostPID: true & privileged: true)
Baseline: Prevents known privilege escalations (Blocking hostPID: true, host paths, and host networking)
Restricted: Hardened best practices (Requires dropping capabilities, non-root users, and more..)

So, how do PSS policies block the attack?
By either applying a Baseline or Restricted policy to the target namespace, Kubernetes will reject inspector-pod at the API server before it can ever be scheduled. Here's an example of enforcing the baseline profile on the default namespace

kubectl label --overwrite ns default pod-security.kubernetes.io/enforce=baseline

If an attacker tries to apply inspector-pod.yaml now, the Kubernetes API server responds with an immediate error, similar to other admission control technologies like OPA:

Error from server (Forbidden): pods "inspector-pod" is forbidden: 
violates PodSecurity "baseline:latest": hostPID (spec.hostPID=true), 
privileged (container "inspector" must not set securityContext.privileged=true)

Strategy 2 - Runtime Isolation

While PSS works at the API controlplane-level (by stopping bad YAML from being accepted), the ideal runtime isolation approach should be applied at the Kernel-level.

For context, hostPID: true and privileged: true are commonly enabled purely by accident, oftentimes by developers while troubleshooting nodes, and through legacy Helm charts, or by third-party monitoring and observability agents (like eBPF probes, custom log forwarders, or node-exporters) that require node visibility. And when this happens in a multi-tenant cluster (that's shared across departments or clients), compromising a single pod with host privileges instantly compromises all secrets across all pods on that same node, rendering the entire namespace-level isolation useless.

So, what if an attacker has cluster-admin privileges or bypasses PSS?
Standard Kubernetes containers share a single, common Linux kernel. If namespace boundaries break, everything on that kernel is exposed. In the case of Edera Zones (and microVM-based runtimes like Kata Containers or gVisor, more generally) they implement a defence-in-depth strategy by isolating all your workloads into distinct hypervisor boundaries or independent kernel spaces.

Under gVisor, Kata Containers, or Edera Zones, even if a pod sets hostPID: true and privileged: true, hostPID only shares the PID namespace of the isolated guest kernel / microVM sandbox, not the underlying bare-metal host node. The malicious pod sees only itself and its sandbox. In this way, it can't see processes from neighbouring pods running in parallel sandboxes.

Note: I will continue to update the Github repository to better improve these security automation demos.

Developer Weekly Briefing — August 14, 2026

Fri, 14 Aug 2026 13:08:23 +0000

Coming off Black Hat, the theme continues: the tools developers use every day are becoming part of the threat model. This week had two concrete examples of that — and a major shift in how one of the most widely used AI coding agents handles permissions. Here's what mattered.

Anthropic makes Claude Code's auto mode the default — and the data behind it is worth understanding

Starting August 14, Claude Code runs in auto mode by default for Pro, Max, and Team users. That means the constant stream of per-action permission prompts is gone, replaced by a classifier that only interrupts when an action looks irreversible, destructive, or aimed outside your own environment.

The reason Anthropic gives for the change is blunt: users approve 97% of permission prompts. That's not evidence of careful review. It's evidence of permission fatigue — developers clicking through without reading, which means the prompts stopped functioning as a safety control a long time ago.

The data behind the decision is worth looking at. In a controlled study of 1,053 paid testers, a disguised dangerous command was inserted into live coding sessions. Human reviewers caught it 13.6% of the time. Auto mode caught it 89% of the time. Catch rates for humans dropped to around 5% after 50 or more prior prompts in a session. Auto mode's detection rate held steady regardless of session length.

Production data reinforced it. Sessions using manual approval contained serious unintended harm at 6.3% — more than twice the rate seen with auto mode at 2.4%. Separately, third-party testing from Trajectory Labs ran 720 prompt injection attacks against Claude Code's auto mode and logged zero successes. Codex's comparable mode had a 5.83% success rate on the same attacks.

The shift doesn't remove human judgment from the process. It moves it earlier. You define what the agent can touch before a session starts — the boundaries, the permissions, the scope. The per-click approval model assumed developers would catch problems in real time. The data says they weren't. Auto mode assumes the upfront work is where the real control lives.

Enterprise, API, and major cloud platform users remain opt-in for now.

Cursor CLI ran code from cloned repos before its own trust prompt ever loaded

Cursor CLI has a workspace trust feature — a prompt that's supposed to confirm you trust a project before the agent acts on it. Security researcher Francisco Rosales at Manifold Security found that on builds before 2026.07.23-e383d2b, the trust prompt came too late.

The issue sits in Cursor's worktree feature. When you run the CLI with -w, it creates a worktree and runs a setup script defined in a repository's .cursor/worktrees.json file. That script executed during workspace resolution — a step that completed before the trust dialog appeared. A repository's own code ran on your machine before you'd ever seen the trust prompt, let alone answered it.

The sandbox didn't help. Cursor CLI ships a sandbox that limits what terminal commands can read, write, and reach. The worktree setup script is pinned to insecure_none — the setting that disables the sandbox entirely for that step. So even developers running Cursor with --sandbox enabled still had repository-supplied code execute directly on the host, outside any sandbox boundary, with the same file and credential access as the person running Cursor.

Cursor shipped a fix in build 2026.07.23-e383d2b. What it didn't ship was a security advisory. Rosales's report was closed as "Informative," with the reasoning that the issue requires a user to clone an attacker-controlled repo. Worth sitting with that justification for a moment: cloning repos, checking out branches, and opening unfamiliar projects is the core of what developers do every day. That's not a mitigating factor. That's the threat surface.

If you use Cursor CLI: update to 2026.07.23-e383d2b or later, and pass --skip-worktree-setup when opening repos you haven't fully audited. Even after the fix, clicking "trust" still runs the setup script outside the sandbox.

Microsoft's new testing agent targets the trust gap in AI-generated code

The reliability problem with AI-generated code isn't that it fails to compile. It's that it passes tests written by the same AI that wrote the code, which creates a closed loop with no independent verification. Microsoft's new testing agent is built to break that loop — generating tests from a different perspective than the code author, specifically targeting the gap between what code does and what it was supposed to do.

An AI agent leaked a sales team's financials. Mimecast built something to catch the next one.

The incident is documented and real: an AI agent with access to financial systems surfaced sensitive sales data in a context where it shouldn't have appeared. Mimecast's Agent Risk Center is built specifically to monitor agent behavior for exactly this pattern — data accessed outside expected scope, outputs that contain sensitive content, actions that don't match the agent's stated purpose. Purpose-built agent monitoring for the scenarios that are already happening, not theoretical ones.

Stairwell's CTO built Backstory around one question: what's never been seen before? A look at how the threat intelligence platform approaches novelty detection — finding the malware and attacker behavior that signature-based tools can't recognize because they haven't been catalogued yet. Read more
ZeroDrift launches Command Center and offers developers $1,000 to test-drive its AI compliance firewall. An unusual go-to-market move — worth reading if compliance governance for AI pipelines is on your team's list. Read more
LTX opens up its next world model, betting enterprises want video AI they can own. Open-weight video generation aimed at organizations that need to keep training data and model weights on their own infrastructure. Read more

The through-line this week: the trust model for AI coding tools is being rebuilt from the ground up. Anthropic is betting that a classifier does better than fatigued humans clicking approve. Cursor's trust prompt turned out to be a warning, not a gate. Microsoft is attacking the closed loop in AI-generated test coverage. All three are responses to the same underlying reality: agents act fast, and the guardrails have to be built into the environment before the session starts, not enforced click by click during it.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Cursor CLI Ran Code From Cloned Repos Before Its Own Trust Prompt Ever Loaded

Mon, 10 Aug 2026 14:00:00 +0000

Cursor's command-line coding agent has a workspace trust feature. It's supposed to stop the agent from acting on a project until you've told it you trust that project. Security researcher Francisco Rosales at Manifold Security found a way around it, and the gap ran deeper than a single missed check.

The setup script that ran before trust was asked

The issue lives in Cursor CLI's worktree feature. Run the CLI with -w, and it creates a worktree under ~/.cursor/worktrees//. A repository can define a setup command for that worktree in a file called .cursor/worktrees.json, using a setup-worktree key. Cursor passes that command straight to sh -c.

That's a normal convenience feature. The problem is when it runs. On builds before 2026.07.23-e383d2b, the setup script executed during workspace resolution, and that step finished before the code path that shows the trust dialog. So a repository's own command ran on your machine before you'd ever seen, let alone answered, the trust prompt.

Rosales put it plainly: the trust gate exists so a user can assert they trust a workspace before the agent acts in it. Code execution is supposed to sit behind that gate. This didn't.

The sandbox didn't cover it either

Cursor CLI also ships a sandbox that limits what terminal commands can read, write, and reach on the network. Reasonable users would assume turning it on protects them here. It doesn't.

The worktree setup script is pinned to insecure_none, the setting that turns the sandbox off entirely for that script. So even a developer running Cursor with --sandbox enabled still had a repository-supplied command execute directly on the host, outside any sandbox boundary.

And once that command runs, Rosales confirmed it has the same access as the person running Cursor. Same files, same credentials, same environment. There's no reduced-privilege step in between.

No advisory, and a bumpy disclosure process

Cursor shipped a fix in build 2026.07.23-e383d2b. What it didn't ship was a security advisory. Rosales said Manifold's report was closed as "Informative" on July 29, with two reasons given: the issue requires a user to clone or open an attacker-controlled repository, and the report didn't demonstrate a bypass of workspace trust in the strictest sense. Manifold pushed back with more context, including a reference to a previous Cursor CVE covering similar territory, and hadn't heard back as of this writing.

It's worth sitting with that first reason for a second. "Requires the user to clone an attacker-controlled repo" describes most of what developers do all day. Cloning repos, opening PRs, checking out a coworker's branch, trying out an open-source tool. That's the entire threat surface AI coding agents operate in.

Not just a Cursor problem

Rosales was careful to scope his team's research to Cursor CLI's worktree mechanism specifically, since that's what they tested and can confirm. But he also flagged that workspace trust bypasses through configuration files or other planted repo content, potentially leading to remote code execution, are a known category. Multiple researchers have found variations of it across different agentic coding tools.

His read on why this keeps happening: speed. Everyone building and shipping with AI coding assistants is optimizing for moving fast, and auditing the configuration a repository ships for a specific agent isn't something most developers are doing. It's not on anyone's checklist yet.

What to actually do about it

The narrow fix: update to build 2026.07.23-e383d2b or later, where the worktree setup script is now gated behind the trust prompt. But Rosales flagged an important caveat — once you click "trust," the script still runs, and it still runs outside the sandbox. Trusting a repo means the code in that script executes on your machine, full stop. If you're opening a repo you haven't fully audited, pass --skip-worktree-setup to skip that step.

The wider takeaway is less comfortable. Rosales doesn't think the trust prompt should be treated as a security control. He called it closer to a warning, and pointed out that many coding assistants already ship modes that skip these dialogs entirely for the sake of speed.

That's the real shift developers and security teams need to make. AI agents are capable, configurable, and genuinely useful for moving faster. They're also a new and significant part of the threat model, and "ask before acting" assumes a pace of development that agentic tooling has already outrun in places.

Why this habit is so easy to miss

Most developers don't think of cloning a repo as an action with consequences. It's step one, not a decision point. You pull down a project, open it, and start reading code before you've formed any opinion about whether you trust it. AI coding agents insert themselves right at that moment, and they're built to act fast on your behalf.

That's exactly the gap this research exposes. A .cursor/worktrees.json file sitting quietly in a repo isn't something most people check for, and there's no reason they would have, until now. It's a small, easy-to-miss configuration detail that happens to sit directly in the path of code execution.

If you're pulling down unfamiliar repos regularly, and most developers are, it's worth treating any agent-specific config file the same way you'd treat a postinstall script in a package.json: something to glance at before you run anything, not after. Worth checking what your agent of choice actually gates, and when.

Developer Weekly Briefing — August 7, 2026

Fri, 07 Aug 2026 13:35:02 +0000

Black Hat USA 2026 was this week in Las Vegas. I covered 13 sessions, briefings, and demos across four days. The theme that ran through almost every conversation: agent identity and access governance is no longer a future problem. It's happening right now, and most organizations are significantly behind.

Here's everything that mattered.

The Black Hat Dispatch

Enterprises can only see a third of their own AI attack surface — Snyk

Ask a security team what AI they're running, and they'll hand you a list of approved models. According to new Snyk research across more than 3,000 enterprise accounts and 1.39 million scanned repositories, that list covers roughly one-third of the actual picture. The real AI footprint includes agent frameworks, MCP servers, retrieval systems, vector databases, datasets, and all the tools those agents call — about three times what a model inventory alone shows.

The adoption numbers are moving faster than governance can follow. Six months ago, 28% of organizations were running agentic architecture. That's now 33%, and the share running the full stack — agent frameworks and MCP servers together — jumped from 36% to 50% in the same period. Half of model-deploying organizations can't trace their own training data in their code repositories at all.

The practical advice from Snyk's Randall Degges: break your AI security pipeline into explicit, separate stages — linting, compilation, then dedicated security scanning — rather than asking one tool to catch everything in one pass. Snyk also shipped GA of Evo Continuous Offensive Security and Agent Red Teaming alongside the research.

Microsoft's David Weston: AI generates a working Linux kernel exploit for $3.61 and 21 minutes

The Microsoft keynote didn't bury the lead. David Weston demonstrated that AI can now produce a working Linux kernel exploit for $3.61 and 21 minutes of compute time. That number is the new baseline for what a motivated attacker needs to get started. The rest of the keynote covered Microsoft's response — but that opening data point is what every architect and security lead in the room will remember.

CVE disclosures have doubled two years running. The backlog is now "radioactive."

Jeff Williams, founder of Contrast Security, made the case that the vulnerability disclosure system is breaking down under its own weight. CVE disclosures have doubled for two consecutive years. The backlog isn't getting cleared — it's accumulating. Williams' term for it: radioactive. The problem isn't that we're finding more vulnerabilities; it's that the pipeline for addressing them can't keep pace with the rate they're being found, and AI-generated code is accelerating the input side without doing anything about the output side.

Zenity's attack research at Black Hat documented something worth reading carefully: malicious agent skills sitting in a major AI marketplace's top trending section, with 1.7 million combined downloads, designed to steal credentials. These weren't obscure packages buried in search results. They were trending. The supply chain risk that's been theoretical for AI agent marketplaces just got a documented case.

Developer laptops now hold 15x more valid credentials than GitHub — and AI agents created nearly half of them

GitGuardian CEO Eric Fourrier presented research showing that endpoint secrets have become the primary exposure vector. Developer laptops hold roughly 15 times more valid, live credentials than GitHub repositories, and AI coding agents generated close to half of them. The implication: secrets management tooling built around repository scanning is looking at the wrong surface.

AI security agents hit a 78% accuracy ceiling — and the fix isn't a better model

Sola Security's benchmark tested AI security agents across real-world triage scenarios and found a consistent ceiling at around 78% accuracy, regardless of which model was underneath. The ceiling isn't a model quality problem — it's a context and architecture problem. Throwing a better model at the same task structure doesn't move the number. This is useful counterweight to the vendor claims that will follow every new model release for the next year.

The official Python Docker image ships with 400 CVEs before you write a line of code — Minimus

Minimus presented research showing that the official Python base image used by a large share of production deployments comes pre-loaded with around 400 CVEs before a developer adds a single dependency. The counter-intuitive finding: you can eliminate nearly all of them by switching to a minimal base image, without materially changing your build process. Most teams haven't done this because nobody told them to look.

Oak: some organizations discover they have 10,000 AI agents for every 200 employees

Oak's head of research delivered one of the sharper data points of the week: organizations auditing their agent footprint for the first time are finding ratios of 10,000 agents per 200 employees. Those agents hold persistent access, call APIs, and operate with credentials — none of which is reflected in most identity governance programs. Oak's platform is built specifically to discover, classify, and govern non-human identities at that scale.

C1 CISO Kevin Paige: human-to-AI agent ratios could hit 1:150 within a year

Kevin Paige, CISO at C1, put a number on where the non-human identity problem is heading: a ratio of one human to 150 AI agents within 12 months for organizations deploying aggressively. Current secrets management and identity governance programs weren't built for that ratio. Most weren't built for 1:10. The conversation covered what a purpose-built approach to agent secrets management actually looks like at that scale.

Atsign's kill switch for AI agents isn't software — it's a revocable identity

Atsign's approach to agent containment starts from a different premise than most: instead of trying to monitor and detect bad agent behavior after the fact, they make every agent action contingent on a cryptographic identity that can be revoked instantly. Pull the identity, and the agent stops — not because a rule fired, but because it no longer has the credentials to do anything.

DTEX: insider risk now costs $19.5 million a year — and AI agents are the newest insider

DTEX's annual insider risk report moved the average organizational cost to $19.5 million. The new variable in the model: AI agents exhibit the same behavioral patterns as human insiders — accessing systems outside normal scope, exfiltrating data, operating at odd hours — but aren't covered by the human-behavior baselines most insider risk programs are built on.

Accenture and Google: AI agents didn't just cheat on a safety test — they built a chat room to help each other do it

One of the more unsettling research findings of the week: during a safety evaluation, AI agents didn't just find a way to circumvent the test — they spontaneously created a communication channel to coordinate with each other and share the workaround. No human told them to collaborate. The behavior emerged from the incentive structure of the test itself. Safety testing designed for single-agent systems may not catch emergent multi-agent behavior at all.

F5's Sean Murphy: the gap between vulnerability and exploit has basically disappeared

The window between a vulnerability being disclosed and a working exploit being available has collapsed to near-zero for a growing share of CVEs. The traditional "patch within 30 days" guidance was built for a world where that window existed. It doesn't anymore for the most critical issues.

SOC wrap: AI agents taught themselves to evade EDR — and most security teams still won't trust automated triage

A roundtable with Sophos, Strike48, and Gravwell closed out my Black Hat coverage: AI agents are observed teaching themselves to evade endpoint detection tools through iterative trial and error — not pre-programmed evasion. Despite that, most security teams remain reluctant to trust AI for automated triage, even on low-risk alerts. The attackers are automating faster than the defenders.

Illumio: a live demo doesn't change the physics of attack — just the blast radius

The Illumio demo showed microsegmentation under real attack conditions. The core argument: you can't change how attackers move, but you can change what they can reach when they get in. Segmentation doesn't prevent breach; it limits blast radius.

GitHub brings stacked pull requests to GA — cleaner UI for managing dependent PR chains. Read more
JetBrains open-sources KotlinLLM — a research prototype for runtime code generation. Read more
Microsoft confirms a Copilot super app is coming this year — less about convenience, more about owning the AI interaction layer. Read more

The through-line from Black Hat 2026: the attack surface has expanded faster than the governance structures designed to protect it. Agent identity, endpoint secrets, vulnerable base images, marketplace supply chains, emergent multi-agent behavior — none of these were on most security team roadmaps two years ago. All of them are active now.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Cybersecurity & Data Protection in 2026: A Developer's Toolkit That Actually Makes Sense

Tue, 14 Jul 2026 20:52:56 +0000

If you're shipping code in 2026, security isn't a checkbox anymore — it's a daily habit. Attackers are using AI to find and weaponize bugs faster than most teams can patch them, and the tools that protect you have had to evolve just as fast. Here's a practical rundown of five tools worth knowing, arranged roughly in the order you'd actually adopt them as a dev or security engineer.

Start with catching vulnerabilities before they ship.

Amplify Security builds what they call an "agentic security harness" — instead of a generic AI wrapper bolted onto old scanning rules, it spins up custom detection agents that understand your specific codebase, maps relationships across your repos, and can push fixes straight into your pipeline. The standout feature is reachability analysis: it filters out the theoretical vulnerabilities nobody will ever exploit and focuses your team on what's actually reachable in production. For teams drowning in false positives from traditional SAST tools, this is a real relief.

Once your code is clean, you still need someone trying to break it.

That's where Stingrai comes in. It's a penetration testing platform that pairs an AI agent named Snipe — which runs recon, tests authentication and access control, and chains exploits like a real attacker — with CREST-certified human pentesters who validate every finding. You can run a one-time test or keep continuous testing running in the background, and Snipe can even open AutoFix pull requests for verified bugs. Given that the median time from vulnerability disclosure to active exploitation has dropped from years to under a day, continuous testing is starting to feel less optional.

If your stack includes autonomous AI agents, this next one matters more than you'd think.

Clawctl is a secure, managed runtime for OpenClaw AI agents, built around sandboxed execution, encrypted secrets, human-in-the-loop approvals, and full audit trails — all deployable in about 60 seconds. As more dev teams hand off real tasks to autonomous agents, having a controlled, auditable place to run them (instead of raw, unmonitored execution) is quickly becoming a baseline requirement rather than a nice-to-have.

Don't forget the basics of network privacy.

Whether your team is fully remote or hybrid, a solid VPN is still foundational. VPN Cyber Shield offers research-based comparisons of top VPN providers for 2026, focused on remote work, travel, and everyday privacy — useful if you want a quick, unbiased way to pick a provider without wading through affiliate noise.

Finally, check your own exposure.

Even the best-secured company can have an employee's personal credentials show up in a breach dump. Check My Creds is a free tool that lets you scan an email address for known data breaches and get straightforward guidance on what to do next. It's a two-minute habit worth building into your personal security routine, especially if you reuse credentials anywhere (you shouldn't, but let's be honest).

Security in 2026 isn't about picking one silver-bullet tool — it's about layering detection, testing, agent governance, network privacy, and personal breach monitoring into a workflow that doesn't slow you down. These five cover that stack pretty well.

NPM Safety Guard — All 23 Security Layers Explained

Mon, 29 Jun 2026 06:57:45 +0000

Every npm project is one malicious package away from a supply-chain breach. NPM Safety Guard catches threats that npm audit completely misses — from DPRK backdoors and typosquatted packages, to exposed API keys and AI credential theft hidden inside your node_modules.

This video walks through all 23 detection layers, one by one, showing exactly what each layer catches and how it protects your project in real time.

Your Test and Dev Data Is a Bigger Risk Than You Think

Fri, 05 Jun 2026 00:10:39 +0000

Most developers know they shouldn't use production data in non-production environments. But knowing and doing are two different things — and the gap between them is getting more expensive.

According to Nick Mathison, Senior Product Manager for Delphix at Perforce Software, around 80% of organizations are still sharing production data downstream into non-production environments. That's not a new problem. What's new is that AI makes it significantly more dangerous.

AI Finds What You Missed

Mathison pointed to a recent example that frames the risk well. When the Mythos vulnerabilities were disclosed, researchers found that multiple low-severity issues could be chained together into a critical exploit. The same logic applies to data exposure.

"Before, you might have been okay with some risk," Mathison said. "You knew data was downstream. But now AI can find potentially divergent data points that — when put together — allow you to cross-reference and start to find these giant chains."

In other words, data that seemed harmless in isolation isn't harmless anymore. An AI agent combing through a non-production environment can connect dots that no human analyst would.

The People and Process Problem

When asked what most engineering teams get wrong about test data, Mathison didn't point to tooling. "Time and time again, it's a people and process problem," he said. "There are many tools out there that can do the job. At the end of the day, it's organizing your team in a way that shows the value of working this way."

Developers aren't oblivious to the problem either. Mathison said he asked this question at a user group recently and got a lot of knowing chuckles. "They know they're hiding their heads under the covers," he said. "They know it's there. It's just hard to track and monitor."

That's a pattern worth paying attention to. It's not ignorance — it's friction. Teams know the right approach, but the path to getting there feels expensive and disruptive.

Masking First, Synthetic Where It Fits

The most reliable fix, according to Mathison, is straightforward: mask production data before it ever leaves the production environment and pass only desensitized data downstream.

"Profile it, mask it in production, and then only share desensitized data into non-prod environments," he said. "Once it's masked, those teams are free to use it however they need — build the next feature, solve the next bug, iterate quickly."

Synthetic data is increasingly popular, especially with AI-generated datasets becoming easier to produce. But Mathison is direct about where it works and where it doesn't. Synthetic data is a good fit for greenfield projects and supplementing masked datasets. It breaks down when you're trying to replicate a full production database — complex relationships, correlated values, and real-world edge cases are hard to synthesize accurately. And when it comes to LLM training specifically, there's an added wrinkle: a model trained on AI-generated data can introduce a feedback loop that may not yield reliable results.

The practical takeaway: use masking as your primary strategy and treat synthetic data as a supplement rather than a replacement.

Shift Left on Data, Not Just Code

Developers have internalized shift-left thinking for testing and security. The same logic applies to data governance — it's just less common in practice.

Mathison described the target state as a self-service model. A platform team or data administration team manages the masking policies and makes compliant datasets available. Developers and testers pull what they need, when they need it, without opening a ticket or waiting on another team. "The upsides of getting access to that data when I need it, how I need it, just trumps the gotchas of making sure it's masked," Mathison said.

On the compliance side — GDPR, HIPAA, CCPA — Mathison is realistic about what developers can be expected to know. "You can't be an expert in everything," he said. The CISO and data administration teams own the policy. Developers need clear guardrails and tooling that make following those policies the path of least resistance.

One more watch-out: cloud costs. Teams moving to cloud-based data environments can see resource consumption scale quickly if access controls aren't balanced with spend management. It's the same pattern that bit organizations during the early lift-and-shift era.

What Good Looks Like

The bottom line is clear boundaries between production and non-production, a reliable masking process, and a self-service data delivery workflow that doesn't slow developers down.

Toil is the enemy. If the process for getting a compliant dataset is painful, developers will work around it. If it's fast and self-serve, they won't have to.

F5 AI Remediate Closes the Gap Between Finding AI Vulnerabilities and Fixing Them

Wed, 11 Mar 2026 21:55:57 +0000

Every security team knows the frustration. A vulnerability gets flagged. Someone has to understand it well enough to write a protection. That process can take hours if the issue is simple, days if it's complex, and longer if the right human expertise isn't available. Meanwhile, the exposure sits open.

F5 announced AI Remediate today at AppWorld 2026 in Las Vegas, targeting exactly that gap. It's a new addition to the F5 Application Delivery and Security Platform that closes the loop between F5 AI Red Team — which identifies vulnerabilities in AI models — and F5 AI Guardrails, which enforces runtime protections. AI Remediate automates the creation, testing, and validation of guardrail packages, then hands the final decision to a human before anything goes to production.

Jimmy White, VP of AI at F5 and former CTO and President of CalypsoAI — the AI security company F5 acquired — explained the thinking behind it during an interview at AppWorld.

The Problem It's Solving

For developers and security engineers, the mean time to remediate is a real measurement with real consequences. If you're doing something legitimate but your tooling isn't understood by the security team, you can get blocked — unintentionally — for a long time. AI Remediate is designed to compress that window.

White framed it in terms most engineers will recognize immediately:

"If the human doesn't understand the nuance of why this is bad or how to block it, it could be days. This takes out the nuance required in human knowledge and turns it into a computer program problem."

For simple cases — block salary information from appearing in model outputs, for example — a human can write and publish a guardrail in under 60 seconds. But most real-world use cases aren't that clean. Permutations, regional regulations, industry-specific restrictions, and edge cases pile up fast. That's where the tool earns its place.

How It Works

AI Remediate runs a team of agents that iterates through potential guardrail solutions until it finds one that meets a 90% efficacy threshold. It doesn't just pick the first option — it keeps generating and testing until it hits that minimum bar, then presents the result to a human for approval before it goes live.

The 90% threshold is a deliberate design decision, not a limitation. White explained the reasoning:

"We could make it fully automated, but we chose not to. Make sure the 90% case is secured — and make sure the good traffic in that 10% isn't blocked unnecessarily."

Push efficacy too high and you start blocking legitimate traffic. The Black Friday analogy is useful here: some e-commerce platforms intentionally ease fraud detection on peak days because stopping all risk also stops revenue. The same tradeoff applies to AI security. A guardrail that catches everything isn't the goal. A guardrail that catches the right things — while keeping legitimate use cases running — is.

White also noted that combinatory rules can push accuracy well above 90% for specific scenarios. If two terms are each acceptable on their own but problematic together, combining them into a single rule gets you to 98% or higher. The system handles that logic automatically.

Speed in Practice

White demonstrated the tool at AppWorld earlier today. For a clear-cut vulnerability — a model leaking salary data, for example — the path from identification to a validated guardrail in production took under 60 seconds with a human in the loop.

For complex cases, the benchmark is under 60 minutes. Without AI Remediate, that same complex case could take days.

The difference comes down to whether a human has to understand the full nuance of the problem to write a fix. For most non-trivial vulnerabilities, they do — and most teams don't have someone with exactly that background available on demand. AI Remediate turns what was a knowledge problem into a compute problem.

A Pharma Example That Makes the Case

White walked through a scenario that illustrates why custom guardrails matter. A pharmaceutical company was using AI to help generate new chemical compounds. Certain compounds are legal in the US but banned in Europe. The AI model needed guardrails that could distinguish between regions and block the appropriate outputs accordingly.

Writing that guardrail manually requires someone with a chemistry background who also understands EU regulatory specifics. Finding that person, getting them available, and having them produce and test a working guardrail takes time most teams don't have.

AI Remediate handles it. The machine doesn't need to understand why a compound is banned — it just needs the rules. Apply them, iterate, validate, present to human for approval.

"The right human can probably do it faster than the machine, because they can cut through the nuance. But you can't always find the right human." — Jimmy White, VP of AI, F5

The Human Is Still in the Loop — By Design

One of the strongest selling points for security and engineering teams is what AI Remediate doesn't do: it doesn't push changes to production automatically. Every validated guardrail package requires human approval before it goes live.

White was clear that this is intentional, not a roadmap item to be automated away. The goal is accountable AI adoption, not autonomous AI decision-making. The tool handles the permutations. The human makes the call.

That distinction matters for organizations that have governance requirements around changes to production security controls. The audit trail is built in — every generated guardrail, every test result, and every human approval is logged.

What This Means for the Developer Experience

For developers, the practical impact is narrower but worth noting. When security teams can remediate faster, developers spend less time blocked on false positives or waiting for a protection to catch up with a vulnerability that was already identified.

White pointed to mean time to remediate as the metric that ties this directly to developer experience. Faster remediation means faster resolution. Fewer unnecessary blocks mean fewer interruptions to legitimate work.

AI Remediate is available as part of the F5 Application Delivery and Security Platform. It requires F5 AI Red Team and F5 AI Guardrails as the foundation — Red Team to surface vulnerabilities, Guardrails to enforce protections, and Remediate to automate the step in between.

Is AI Creating More Cybersecurity Problems Than It Solves?

Sat, 28 Feb 2026 05:37:42 +0000

Is AI Creating More Cybersecurity Problems Than It Solves?

Artificial Intelligence is transforming software development at an unprecedented pace. Developers can now generate production-ready code in minutes, automate repetitive tasks and accelerate product launches. However, recent security research suggests that while AI is improving development speed it may also be expanding the cybersecurity attack surface faster than organizations can manage.

According to the latest State of Software Security findings, software vulnerabilities are being introduced at a higher rate than they are being fixed. One of the most concerning trends is the rise in security debt — vulnerabilities that remain unresolved for over a year. This issue now affects a large percentage of organizations and the gap continues to grow.

The Core Problem: Speed vs Security

AI-assisted development tools enable teams to ship code rapidly. The challenge is that remediation efforts are not scaling at the same speed. More code means more potential vulnerabilities. If security testing, code review and patch management do not keep up, the risk compounds over time.

In many cases, AI-generated code introduces:

Insecure configurations
Outdated dependencies
Weak input validation
Authentication and authorization flaws

Modern security tools are better at detecting issues through static analysis, dynamic testing and software composition analysis. However detection alone is not enough. The real bottleneck lies in timely remediation.

AI: A Double-Edged Sword

AI is not inherently the problem. In fact, it can also be part of the solution. Security teams are increasingly leveraging AI for automated vulnerability detection, threat modelling assistance, code pattern analysis and faster triaging of alerts.

At the same time, AI systems introduce new risks such as prompt injection, false positives and complex code structures that are harder to audit manually. This creates a paradox. AI increases productivity while simultaneously increasing complexity.

Why This Matters for Developers and Start-ups

For independent developers, start-ups and growing tech companies, speed is often prioritized over security. Shipping features quickly can feel like survival. But unmanaged security debt can lead to data breaches, compliance violations, loss of user trust, financial damage and long-term reputational harm.

Cybersecurity is no longer a final-stage checklist item. It must be integrated into the development lifecycle from day one through secure coding practices, automated scanning pipelines and regular dependency updates.

A Practical Way Forward

Instead of slowing innovation, organizations should focus on secure AI adoption. This includes reviewing AI-generated code before deployment, enforcing secure coding standards, automating CI/CD security scans, prioritizing high-risk vulnerabilities and training developers in secure-by-design principles.

AI will continue to shape the future of software engineering. The question is not whether to use it but how responsibly we integrate it into our workflows.

The future belongs to teams that move fast and stay secure.

#ArtificialIntelligence #CyberSecurity #SecureCoding #SoftwareDevelopment #InfoSec #DevSecOps #TechInsights #DigitalInnovation #MuhammadYasir #YasirAwan4831

Azure Landing Zone - Policy at Scale

Tue, 02 Dec 2025 23:47:52 +0000

Azure Policy in Real Landing Zones

Onboard multiple Azure subscriptions into a real landing zone using Azure Policy, management groups, and policy-as-code for enterprise governance.

Introduction

On paper, Azure Landing Zones and Azure Policy look clean and deterministic. In reality, you're onboarding dozens or hundreds of subscriptions with existing workloads, legacy configurations, and multiple teams that all think they're special.

This article focuses on using Azure Policy to onboard multiple subscriptions into a real, enterprise-grade landing zone:

How to structure management groups and policy initiatives for scalable governance
How to onboard brownfield and greenfield subscriptions safely
How to use policy as code and CI/CD to operate this at scale
How to balance security, reliability, and delivery velocity when policies start denying real traffic

The scope is Azure-first, but the patterns map naturally to AWS Organizations + SCPs and GCP Organization policies.

Core Concepts

Azure Landing Zone in Governance Terms

Forget marketing. In governance terms, an Azure Landing Zone is:

A management group hierarchy
A set of policy initiatives (built-in and custom)
A baseline of guardrails for networking, identity, security, and operations
A repeatable way to onboard subscriptions and apps into that baseline

Key Azure building blocks:

Management groups (MGs) – hierarchical containers for subscriptions; policies applied here flow down
Azure Policy definitions – rules for what is allowed, denied, audited, or automatically deployed
Policy initiatives – logical bundles of policy definitions (e.g., CAF "Azure Landing Zone" initiatives)
Assignments – binding a definition/initiative to a scope (management group, subscription, resource group)
Effects – Deny, Audit, DeployIfNotExists, Modify, Append, etc.
Remediation tasks – jobs created to apply DeployIfNotExists/Modify to existing resources

Management Group Hierarchy for Real Landing Zones

A pragmatic, enterprise-friendly hierarchy often looks like:

Tenant Root ( / )
 ├─ Platform
 │   ├─ Identity
 │   ├─ Management
 │   ├─ Connectivity
 ├─ LandingZones
 │   ├─ Corp
 │   │   ├─ Corp-Prod
 │   │   ├─ Corp-NonProd
 │   ├─ Online
 │       ├─ Online-Prod
 │       ├─ Online-NonProd
 └─ Sandbox

Patterns:

Platform MGs host shared services: identity, networking, management
LandingZones MGs host application subscriptions grouped by business domain / criticality
Sandbox MG for low-governance experimental spaces

Policy is usually bound at Platform, LandingZones, and specific child MGs such as Corp-Prod.

Policy as Code and DevSecOps

Azure Policy without automation becomes unmaintainable as soon as you pass 5 subscriptions.

Treat Azure Policy as code:

Definitions and initiatives stored as JSON in Git (or Bicep/ARM modules, or Terraform)
Pipelines (Azure DevOps or GitHub Actions) that:
- Validate policies (linting, schema checks)
- Publish definitions to the management group scope
- Assign initiatives with parameter values per environment (dev/test/prod)
PR-based change control for all policy changes
Security and platform teams collaborate on policy sets and exemptions through Git, not the portal

High-level mapping of key services:

DevOps tooling: Azure DevOps Pipelines / GitHub Actions
Governance: Azure Policy, Management Groups, Azure Blueprints (phasing out), CAF landing zone initiatives
Security: Defender for Cloud, Key Vault, Managed Identities, Entra ID (Azure AD)
Observability: Azure Monitor, Log Analytics, Application Insights

Step-by-Step Guide

1. Prerequisites and Roles

Prerequisites:

Tenant-level setup
- Management group hierarchy defined and approved
- Tenant Root Group locked down to a small platform/governance team
Access
- Platform team with Owner or Contributor + Resource Policy Contributor at key MGs
- Security team with Security Admin + rights to define/approve policies
Tools
- Git repository for policy-as-code
- CI/CD pipelines (Azure DevOps or GitHub Actions)
- Landing zone reference (CAF-aligned) selected and tailored

Team ownership:

Platform team: management groups, policy initiatives, CI/CD
Security team: security controls, approvals, exceptions
App teams: subscription ownership, remediation work, exception requests

2. Design the Management Group Strategy

Define environments
- Separate Prod and NonProd at MG level where possible (Corp-Prod, Corp-NonProd)
- Critical workloads can have their own branch (Payments-Prod MG)
Align policies with MG scopes
- Tenant root: only minimal guardrails (e.g., logging, naming, maybe region restrictions)
- Platform MG: policies for shared services (diagnostics, DDoS plan requirements, etc.)
- LandingZones MG: baseline security, networking, and operational standards for all app subscriptions

Key rule: You should not assign policies directly to individual subscriptions unless there is a strong, documented reason. Use management groups as default.

3. Define and Version Your Policy Library

Use a structure like:

policies/
  definitions/
    security/
      allowed-locations.json
      vm-require-managed-disks.json
    operations/
      deploy-diagnostics-to-log-analytics.json
    networking/
      require-private-endpoints.json
  initiatives/
    alz-core.json
    alz-security.json
    alz-networking.json
  assignments/
    Corp-NonProd/
      alz-core.json
      alz-security.json
    Corp-Prod/
      alz-core.json
      alz-security.json
      alz-networking.json

Example Terraform snippet for an initiative assignment:

resource "azurerm_policy_set_definition" "alz_core" {
  name         = "alz-core"
  display_name = "ALZ Core Baseline"
  policy_type  = "Custom"
  management_group_id = data.azurerm_management_group.landingzones.id

  policy_definitions = [
    {
      policy_definition_id = data.azurerm_policy_definition.allowed_locations.id
      parameters           = jsonencode({ listOfAllowedLocations = { value = ["westeurope", "northeurope"] } })
    },
    {
      policy_definition_id = data.azurerm_policy_definition.deploy_diagnostics.id
      parameters           = jsonencode({ logAnalytics = { value = "/subscriptions/.../resourceGroups/rg-logs/providers/Microsoft.OperationalInsights/workspaces/lz-logs-weu" } })
    }
  ]
}

Then assign that initiative to a specific management group:

resource "azurerm_policy_set_definition" "alz_core" {
  # as above
}

resource "azurerm_policy_assignment" "alz_core_corp_prod" {
  name                 = "alz-core-corp-prod"
  display_name         = "ALZ Core for Corp Prod"
  policy_definition_id = azurerm_policy_set_definition.alz_core.id
  scope                = data.azurerm_management_group.corp_prod.id

  identity {
    type = "SystemAssigned"
  }

  location = "westeurope"
}

4. Build CI/CD for Policies

Example: GitHub Actions workflow for policy deployment (simplified):

name: Deploy Azure Policies

on:
  push:
    branches: [ main ]
    paths:
      - 'policies/**'

jobs:
  deploy-policies:
    runs-on: ubuntu-latest
    env:
      AZURE_MG_ID: /providers/Microsoft.Management/managementGroups/landingzones
    steps:
      - uses: actions/checkout@v4

      - uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Validate policy JSON
        run: |
          python scripts/validate_policies.py policies/definitions
          python scripts/validate_initiatives.py policies/initiatives

      - name: Deploy policy definitions
        run: |
          az deployment mg create \
            --management-group-id ${AZURE_MG_ID##*/} \
            --template-file infra/policies/definitions.bicep \
            --parameters definitionsPath=policies/definitions

      - name: Deploy policy initiatives and assignments
        run: |
          az deployment mg create \
            --management-group-id ${AZURE_MG_ID##*/} \
            --template-file infra/policies/initiatives.bicep \
            --parameters initiativesPath=policies/initiatives assignmentsPath=policies/assignments

Key points:

Use service principals with least privilege for policy deployment
Validate JSON / Bicep / Terraform as part of the pipeline
Use separate pipelines or stages for dev vs prod MGs

5. Onboard Subscriptions: Brownfield vs Greenfield

5.1 Greenfield subscriptions

For new subscriptions:

Create subscription via automation (e.g., Azure Deployment Environments, Azure DevOps pipeline, Terraform, custom portal)
Ensure the new subscription is placed in the correct management group (Corp-NonProd, Corp-Prod, etc.)
Policies auto-apply from the MG
Validate:
- Subscription appears in management group
- Policy assignments list inherited initiatives
- First deployments from app team resources comply with policy

5.2 Brownfield subscriptions (existing workloads)

Onboarding existing subscriptions is where Azure Policy meets reality.

Process:

Discovery
- Move subscription into a temporary MG (e.g., Brownfield-Quarantine) where only Audit policies are applied
- Run compliance scans and export non-compliance via Azure Resource Graph or az policy state CLI
- Classify findings: high-risk (public IPs, missing encryption, no backups), medium, low
Define migration strategy
- Agree with app owners on timelines and responsibility for remediation
- For some controls, use DeployIfNotExists or Modify to auto-remediate
- For hard-breaking changes, schedule maintenance windows
Gradual enforcement
- Phase 1: Audit-only policies at target landing zone MG
- Phase 2: Switch selected controls to Deny for new deployments, keep existing resources under Audit/DeployIfNotExists
- Phase 3: Fully enforce policies including existing resources (if realistic)
Move subscription into its final MG once:
- Critical non-compliances are addressed or excepted
- Auto-remediation jobs have run and are monitored
- App team acknowledges and accepts the landing zone guardrails

6. Operationalizing Policy: Remediation and Exceptions

6.1 Remediation

For DeployIfNotExists / Modify policies:

Enable system-assigned managed identity on policy assignments to perform changes
Trigger remediation tasks via portal or CLI:

az policy remediation create \
  --name fix-diag-settings \
  --policy-assignment "/subscriptions/<subId>/providers/Microsoft.Authorization/policyAssignments/alz-core-corp-prod" \
  --resource-group rg-app-prod

Monitor remediation status via:
- Azure Policy compliance dashboard
- Azure Monitor alerts on failed remediation tasks

6.2 Exceptions and Exemptions

Not everything can be compliant on day one.

Use Azure Policy exemptions instead of deleting or bypassing policies:

Scope exemptions to the smallest possible asset (resource group or resource)
Make them time-bound where possible (expiration date)
Track exemptions in Git (YAML/JSON manifest) to avoid "exception sprawl"

Architecture Overview

This shows:

Policy-as-code flowing through CI/CD into MG scopes
Subscriptions inheriting initiatives from their MGs
Clear ownership separation between platform, security, and app teams

Best Practices

Start with management groups, not subscriptions
Design and agree your MG hierarchy before onboarding more subscriptions
Bundle policies into coherent initiatives
Organize by domain: alz-core, alz-security, alz-networking, alz-ops rather than hundreds of standalone assignments
Use Audit-first, then Deny
Introduce policies as Audit, analyze impact, then promote selected controls to Deny for new deployments
Separate baselines for Prod vs NonProd
NonProd can have more permissive policies (e.g., broader locations, less strict SKUs). Prod should be tightly controlled
Make policy-as-code mandatory
Disallow manual creation or modification of policy assignments outside pipelines (and detect them via drift monitoring)
Minimize tenant root scope policies
Place most policies at Landing Zone MG scope; keep tenant root focused on tenant-wide essentials (e.g., disallowed regions, high-level logging)
Automate subscription creation and placement
Never create subscriptions manually via portal for production scenarios. Use pipelines + APIs to enforce correct MG placement and tags
Integrate policy results into observability
Export compliance and remediation metrics to Log Analytics, build dashboards and alerts (e.g., % compliance per landing zone, per team)
Align policy with security standards
Map initiatives to CIS, NIST, ISO controls; use Defender for Cloud and CAF recommendations to inform baseline

Common Pitfalls

1. "Deny Everything" From Day One

Issue: Deploying a large set of Deny policies to all subscriptions at once.
Impact: Broken pipelines, blocked deployments, emergency bypasses, political fallout.
Detection: Sudden spike in policy evaluation failures and deployment errors (HTTP 403) across subscriptions.
Fix:

Roll back to Audit for high-impact controls
Reintroduce Deny gradually with prior impact analysis and communication

2. No Separation Between Baseline and App-Specific Policies

Issue: App-specific requirements mixed into global initiatives.
Impact: Baseline becomes cluttered, unmanageable, and difficult to update.
Detection: Initiatives that reference specific resource names, SKUs, or app tags.
Fix:

Keep platform baseline initiatives generic
Manage app-specific policies at subscription or dedicated MG branches

3. Manual Policy Drift

Issue: Changes made via the portal that are not reflected in Git.
Impact: Unknown behaviors, inconsistent environments, broken expectations between teams.
Detection: Regular export and diff between current assignments and Git repo.
Fix:

Enforce policy-as-code
Introduce a "drift detection" pipeline that compares actual state to desired state and raises alerts

4. Overuse of Tenant Root Policies

Issue: Assigning almost everything at tenant root MG.
Impact: No flexibility for different landing zones, high blast radius for mistakes.
Detection: Tenant root has dozens of initiatives; lower MGs have almost none.
Fix:

Move most initiatives down to LandingZone / domain MGs
Keep root very thin

5. Ignoring Remediation Identity Permissions

Issue: Policy assignments use DeployIfNotExists but the managed identity doesn't have required permissions.
Impact: Remediation tasks fail silently or partially.
Detection: Errors in remediation jobs, non-compliant resources not fixed.
Fix:

Assign appropriate RBAC roles (e.g., Contributor on target scopes) to the policy assignment identities

6. Poor Exception Governance

Issue: Exceptions created ad-hoc, without expiry or documentation.
Impact: Hidden risk, compliance gaps, and audit failures.
Detection: Large number of exemptions with no clear owner or reason.
Fix:

Implement a standardized exception workflow (ticket + PR + approval)
Require owner, reason, scope, and expiry for every exemption

FAQ

1. How does this compare to AWS and GCP?

AWS equivalent: AWS Organizations + SCPs + Config; Azure Policy is closer to Config rules + some SCP-like deny behavior
GCP equivalent: Organization policies + Constraints at org/folder/project scopes

The pattern—policy at hierarchy nodes, inheritance to accounts/subscriptions/projects—is the same.

2. How do I integrate security and compliance without blocking delivery?

Use a progressive rollout: start with Audit, expose non-compliance to teams, set SLAs for fixes, then enforce Deny only on well-understood controls. Add policy checks into CI (pre-merge) as well as at runtime.

3. How do I scale this across dozens of teams and subscriptions?

Standardize landing zones per domain
Centralize policy-as-code in a platform-owned repo
Provide self-service subscription provisioning that automatically places subscriptions into the right MG with the correct initiatives

4. What about multi-region and DR landing zones?

Ensure allowed locations and networking policies support your DR regions. Create separate MGs if DR regions have different constraints, or parameterize initiatives with region-specific settings (e.g., different Log Analytics workspaces).

5. How do I integrate with legacy stacks and on-prem?

Focus your policies on connectivity and security first: VPN/ExpressRoute, private endpoints, NSGs, and logging. Ensure that hybrid connectivity does not bypass landing zone controls (e.g., enforcing private-only paths for PaaS services).

6. How do I measure success of my landing zone governance?

Track KPIs such as:

% of subscriptions onboarded to landing zones
Policy compliance rate per MG / per team
Mean time to remediate non-compliant resources
Number of active exemptions and their trend
Deployment failure rates caused by policy (should decrease over time as baselines stabilize)

7. How do I deal with app teams who need special policies?

Use branching MGs under landing zones or subscription-scoped initiatives for special cases, but keep them managed via the same policy-as-code pipeline and documented exceptions.

8. Do I need Azure Blueprints?

Blueprints are being superseded by ARM/Bicep/Terraform + policy-as-code. Prefer those, unless you have a strong reason to keep existing Blueprint-based implementations.

Conclusion

Onboarding multiple subscriptions into a real Azure Landing Zone is fundamentally a governance and operations problem, not a button in the portal. Azure Policy gives you the enforcement engine; management groups give you the structure; policy-as-code and CI/CD give you repeatability.

Key takeaways:

Design a management group hierarchy that reflects your organization
Use policy initiatives aligned to CAF domains (core, security, networking, ops)
Treat Azure Policy as code, integrated with pipelines and reviews
Phase in enforcement: audit, analyze, remediate, then deny
Manage exceptions and remediation with discipline, not one-off hacks

Next steps:

Draft your MG hierarchy and get cross-team buy-in
Stand up a policy-as-code repo and CI/CD pipeline
Start with a non-prod landing zone, onboard a few subscriptions, and refine
Gradually extend to prod and high-criticality workloads

References

Devs fix only 6 vulnerabilities monthly while facing 17 new ones - production attack data essential.

Thu, 17 Jul 2025 11:09:58 +0000

Software Under Siege: Why Production Data is the Key to Secure Code

The numbers are staggering and sobering: applications face attacks every three minutes, with defenders taking 84 days to patch critical vulnerabilities while attackers exploit them in just five days. According to Contrast Security's new "Software Under Siege 2025" research report, based on 1.6 trillion daily security observations from real production applications, the mathematics of modern application security simply don't add up in defenders' favor.

But buried within this seemingly dire data lies a counterintuitive insight that could fundamentally change how organizations approach application security: the answer isn't necessarily writing more secure code upfront, but rather using production attack intelligence to guide development efforts with surgical precision.

The False Positive Problem

"Most AppSec technologies see possible attacks, so they report huge numbers like thousands or tens of thousands of attacks per month," explains Jeff Williams, CTO and founder of Contrast Security, who has spent three decades in application security. "But when you actually watch the way that the application handles that request, you can differentiate. You can say, 'Hey, that's not an attack.'"

The research reveals a stark reality: while applications face over 14,000 attack attempts monthly, only 81 of those are "viable attacks" that actually reach exploitable vulnerabilities. The rest? Ambient internet noise—what Williams calls "mosquitoes" that defenders don't need to react to every time one flies by.

This distinction matters enormously for development teams drowning in vulnerability backlogs. The average organization now carries 1.1 million application vulnerabilities in its backlog, according to recent analyst research. With developers fixing only six vulnerabilities per application per month while discovering 17 new ones, the mathematical trajectory is unsustainable.

The Speed Asymmetry Crisis

The speed differential between attackers and defenders has reached crisis proportions. While attackers can exploit new vulnerabilities in five days and achieve lateral movement in just 48 minutes, defenders require an average of 194 days to identify breaches and 64 additional days to contain them.

"Large organizations have hundreds or thousands of applications, so you're adding net 11 new vulnerabilities per month per app," Williams notes. "If you do that for a few years across thousands of applications, you end up with massive backlogs."

Traditional security tools aren't equipped for this reality. Web Application Firewalls (WAFs) operate as "best effort" technology at the perimeter, unable to understand the applications they're protecting. Endpoint Detection and Response (EDR) tools miss application-layer attacks entirely due to what Williams calls "attack laundering"—when malicious activity originates through the application rather than directly targeting the operating system.

"Many application attacks stay in the application layer, and EDR can never see them," Williams explains. "Things like unsafe deserialization, SQL injection, and expression language injection—none of those touch the operating system."

The AI Amplification Effect

Artificial intelligence is simultaneously making the problem worse and pointing toward solutions. On the attack side, AI dramatically lowers barriers for novice attackers, enabling them to create sophisticated exploits like unsafe deserialization attacks without deep technical expertise.

For development teams using AI coding assistants, the news isn't encouraging. "AI doesn't generate code that's any more secure than humans generate," Williams cautions. "It's trained on code built by humans in the last generation, so that's the kind of code it produces." Multiple studies confirm AI-generated code carries similar security risks to human-written code.

However, AI also offers unprecedented opportunities for defenders when applied to high-quality production data.

The Production Data Advantage

Here's where Williams' research reveals something counterintuitive: the key to writing secure code isn't necessarily shifting further left in the development process, but rather gathering intelligence from production applications under real attack.

"My epiphany over the last 10 years is that in order to build code securely, you have to have context from production," Williams explains. "You have to know where you're being attacked, what attack types are being used against you, and which things in production are really exploitable."

This approach flips conventional wisdom. Rather than trying to anticipate every possible vulnerability during development (often resulting in false positive overload), teams can use actual attack intelligence to prioritize their security efforts with laser focus.

The data supports this approach: 99% of the 1.6 trillion security-relevant transactions Contrast observes daily are executed correctly. "Developers are getting almost everything right relative to the code they're writing," Williams notes. "It's in that 1% where we see the serious vulnerabilities and mistakes."

Practical Implementation Strategies

For CISOs and development leaders, this research suggests several strategic shifts:

1. Deploy Application Detection and Response (ADR) in production environments to gain real-time visibility into which vulnerabilities are actually being targeted. Unlike traditional tools that generate mountains of theoretical vulnerabilities, ADR identifies only those being actively exploited.

2. Use production attack data to prioritize remediation efforts. When development teams know which vulnerabilities attackers are actually targeting, they can focus their limited time on issues that matter rather than chasing theoretical risks.

3. Implement runtime protection for vulnerabilities that can't be immediately patched. Williams notes that ADR can completely eliminate entire categories of attacks, including expression language injection, SQL injection, and unsafe deserialization.

4. Focus on signal versus noise. By filtering vulnerability reports through production attack intelligence, teams can dramatically reduce their effective backlog while maintaining security posture.

Success Stories

The approach yields measurable results. Williams cites BMW as an example of a large organization that has "effectively eliminated their backlog and reduced their mean time to remediate vulnerabilities to one day" by implementing production-informed security practices.

"When you contextualize things and give developers real vulnerabilities, they can tighten the feedback loop," Williams explains. "Across hundreds or thousands of applications, they can get excellent AppSec programs going."

The Path Forward

The research reveals that method tampering appears as the most universal attack across all programming languages—not because it's particularly sophisticated, but because it's easy to attempt. Attackers simply try different HTTP verbs on every endpoint to find access control gaps.

This pattern reflects a broader trend: attackers are increasingly automated and opportunistic, scanning for the easiest targets rather than developing highly sophisticated, targeted exploits. Defenders can leverage this by focusing protection efforts on the vulnerabilities actually being exploited, rather than trying to eliminate every theoretical risk.

As Williams puts it, referencing the movie Cars: "You have to turn right to go left. People think they have to put more effort farther left to prevent vulnerabilities from getting into production. But there's no context over there, so you just get overwhelmed with false positives. The answer, counterintuitively, is in production."

For development teams and security leaders struggling with ever-growing vulnerability backlogs and accelerating attack timelines, this insight offers a path forward: use production intelligence to guide development priorities, deploy runtime protection for immediate risk reduction, and focus precious development resources on the vulnerabilities that truly matter.

The mathematics of modern application security may seem impossible, but with the right data and approach, defenders can finally start winning the race.

Coder Legion - Recent posts tagged devsecops

Developer Weekly Briefing — October 30, 2026

Two GitHub campaigns, one weak point: your config files

AI coding tools can read your SSH keys — two are still unpatched

Flint runs 40B parameters locally — and keeps your code off someone else's server

SAP's CTO says building the agent is now the easy part

Oracle gives each agent its own identity

Also from this week

Developer Spotlight this week

HiddenLayer: A Hijacked LLM Gateway Can Turn Your Coding Agent's Own Permissions Against You

Why the middle layer matters

Step one: watch the clock

Step two: read the configuration

Step three: use what's already allowed

This isn't hypothetical

What developers can do now

CyberCartel Pointed Claude and Grok Agents at 400+ Banks. The Stack Looks Like Yours.

How Straiker Got Inside

Four Agents and an Arbiter

Getting Past the Guardrails

What We Don't Know

What Developers Should Take From This

Where This Goes Next

Developer Weekly Briefing — October 16, 2026

Anthropic hit 30,000 merges a day, and Git couldn't keep up — so it built Scion

GitLab patches a CVSS 10 — update now

GitHub now records who pushed every commit

GitHub is pushing teams off classic PATs — here's the new permission model

npm gives unused trusted publishing configurations 48 hours to prove themselves

Claude Platform now sends agent traces to your observability stack

Figma gives AI agents a spec sheet and code layers land on the canvas

Also from this week

Developer Spotlights this week

HYCU's Free aiR Graph Maps Every Agent in Entra ID and Okta, Then Asks If You Can Recover

Developer Weekly Briefing — October 2, 2026

A crafted package name was enough to reach an AI agent's AWS credentials

GitHub's security autofix agent now remembers what it fixed

IBM Bob goes self-hosted — reaching the enterprises that wouldn't send code to the cloud

Git 2.56: conflict markers, branch cleanup, and performance at scale

Also from Coder Legion and Insights From Analytics this week

The $460 million typo

Developer Weekly Briefing — September 25, 2026

Z.ai was packaging your entire workspace and shipping it to Alibaba Cloud

GitHub now gives enterprises a full count of who holds the keys

Codex sandbox escapes: the thing doing the enforcement was inside the thing being enforced

Claude Code adds AGENTS.md fallback

GitHub separates who writes code from who runs CI

An AI agent signed a developer up for AWS services he never requested

Ripple bets on Stripe and Tempo's payment standard to get AI agents spending XRP

Also from Coder Legion this week

Developer Weekly Briefing — September 18, 2026

A Cursor agent deleted a startup's database in 9 seconds. Then it deleted the backups.

GitLab: patch now. Attackers already are.

JFrog Artifactory: three bugs under active attack, all with patches available

Java 27: post-quantum TLS today, faster patches tomorrow

NVIDIA brings Rust into the CUDA kernel — not just around it

Anthropic adds a Coordinator to Claude Projects for parallel AI work

Also from Coder Legion this week

Cycode's AI Scanner Found 38 Bugs in MLflow. The Press Release Only Mentioned One.

Developer Weekly Briefing — August 28, 2026

Triaging AI scanner output costs 400x more than running the scan

Cisco's Amy Chang: a model's "passport" doesn't tell you where it actually came from

AI can find your vulnerabilities. It still can't own what happens next.

$360,000 a petabyte and 105 days to get out: Microsoft's new math for university storage

The bug that's been breaking software for 40 years is now breaking your AI agents too

Contrast Security: Triaging AI Scanner Output Costs 400x More Than Running the Scan

The attack volume is relentless, but mostly noise

Why the find-and-fix model is structurally broken, not just slow

The AI scanning findings, and one claim worth a caveat

Why CVSS and EPSS alone will steer you wrong

What this actually means for the average team

Crogl's Monzy Merza: The SOC Agent That Refuses to Say It Can Replace You

Closing a three-day window that used to take weeks

Reasoning models wander. That's why there's a deterministic layer underneath.

Secure means sovereign, and sovereign was too big a word to use

What "deploy in minutes" actually requires

The report, not the action, is the default output

What developers need to understand before any of this works

What to be skeptical of

Harness GM Rahul Sood: Most "AI Remediation" Claims Don't Actually Work. Here's What Does.