DAY 05 · Fortify
Fortify — Defend Against AI-Introduced Risk at AI Velocity
A stolen Nx token turned developers' own AI agents into an exfiltration engine — 2,349 secrets from 1,079 machines. The velocity your engineers adopted AI to gain is the exact velocity the attacker borrowed.
The attack that turned your AI agent against you
On 26 August 2025, the s1ngularity attack hit the Nx ecosystem. A stolen publish token let attackers ship malicious versions of Nx — a build tool inside millions of projects. The payload wasn't a conventional infostealer. It was a post-install script that found the AI coding CLIs already sitting on developers' machines — Claude, Gemini, Q — and invoked them with --dangerously-skip-permissions, instructing them to crawl the filesystem for credentials and exfiltrate everything through the gh CLI to a public GitHub repository.
2,349 secrets. 1,079 developer machines. The first documented case of AI coding agents weaponised as an exfiltration engine.
Read the shape of it. Nobody's AI wrote insecure code here. The AI was the attack surface — a trusted, autonomous tool with broad filesystem access and a permission flag that turned off the one thing standing between an instruction and the whole disk. This is what the Fortify practice defends against. And in 2026, defending against it stopped being optional.
Why AI multiplies risk at generation speed
Every practice before this one — Curate, Refine, Architect — sets the substrate, the specs, and the patterns. Fortify is what protects them from AI-introduced risk: vulnerable code, poisoned dependencies, prompt injection, and compliance failures, all arriving at the speed AI generates.
The core insight is uncomfortable. 45% of AI-generated code fails security tests, and for Java specifically the failure rate is 72% (Veracode 2025 GenAI Code Security Report). That is not a rounding error introduced by a few careless teams. It is the baseline behaviour of the tools your engineers are using right now.
Human-pace security review cannot keep up with machine-pace generation. When an agent produces a thousand lines in a minute and your SAST scan takes thirty, the scan is not a gate — it is a suggestion your developers context-switch past. And they do: 80% of developers bypass their organisation's AI code-security policies (Snyk 2025). Then 2026 changed the stakes — two clocks turned Fortify from an engineering preference into a board-level liability.
The five sub-practices of Fortify
What it looks like when Fortify is missing
Two named incidents from the record. Neither is a story about AI being bad. Both are stories about an organisation-scale activity performed without an organisation-scale defense.
The uncomfortable truth
45% of AI-generated code fails security tests (Veracode 2025). That figure applies to your codebase too. And 80% of developers bypass their organisation's AI code-security policies (Snyk 2025).
Sit those two numbers next to each other. Nearly half of what AI writes is insecure, and four out of five of your engineers are routing around the controls you already put in place to catch it. The paradox that makes this durable: roughly 80% of developers believe AI generates more secure code (Snyk 2025). The confidence is inversely correlated with the reality.
You cannot close that gap with a policy paragraph on a Confluence page. A gap between machine-speed generation and human-speed review only closes with machine-speed defense.
If you answered A or B to any of those, you are somewhere in the first three Fortify archetypes — the honest, expected starting point, not a judgment. The ladder runs: The Blind Shippers (no scanning, no provenance) → The Manual Checkers (review too slow for AI velocity) → The Partial Scanners (automated scanning but inconsistent gates, holding AI code to the same standard as human code) → The Defense-Hardened Org → The Security-Native Org (AI code held to a higher bar, compliance automated, recurrence driven toward zero).
The tools that close this gap already exist — sub-minute SAST/DAST/SCA, dependency allowlists, AIBOMs, policy-as-code, closed-loop remediation. What's missing is the practice that organises them into the development loop so defense runs at the same speed as generation. The single highest-leverage first move: put sub-minute scanning and a dependency allowlist in the pipeline — because Article 12 logging is architectural and you cannot retrofit it after 2 August 2026.
- A - In a quarter, when it surfaces in production — or when someone exploits it.
- B - In the next scheduled scan or manual review, whenever that runs.
- C - In under a minute, at the PR gate, before it merges.
- A - Nothing automatic. We trust the developer to notice.
- B - Lockfiles, but no policy on AI-suggested dependencies specifically.
- C - An enforced allowlist that gates every install against registry and reputation checks before it lands.
- A - Nothing we could produce without reconstructing it after the fact — which the Act doesn't allow.
- B - Partial records, assembled manually under pressure.
- C - A one-click evidence package. The logging is architectural and has been running since before the deadline.
The question is not whether your engineers are shipping AI code faster than you can defend it. They are. The question is whether you know where you stand — precisely, per sub-practice — before the clock runs out. Take the Free CRAFT Scorecard at craftmethod.co/scorecard/free. — Luis