Notifications
Clear all
Topic starter
07/09/2026 4:38 pm
TL;DR: When AI writes code from tickets, PRDs, and design docs, the spec becomes the primary security artifact and the attack surface shifts to whatever was never explicitly decided, according to Pixee. That changes how teams review intent, regenerate threat models, and catch assumption drift before it ships.
NHIMG editorial — based on content published by Pixee: The Spec Is the New Attack Surface
By the numbers:
- 90% of developers report using AI coding tools daily.
- Critical vulnerabilities rose about 37.6% after five rounds of iterative AI code generation.
- On BaxBench, secure and correct backends were produced only about 37% of the time.
Questions worth separating out
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Q: Why do AI coding tools create a security risk even when code looks correct?
A: They optimise for syntax and pattern completion, not contextual security reasoning.
Q: What are the signs that a specification has drifted away from the security it promised?
A: Look for shipped features that expose more data than the ticket named, broaden roles beyond the original intent, or omit audit events that the design assumed would exist.
Practitioner guidance
- Review specifications for security decisions before code generation Treat tickets, PRDs, and design docs as security artefacts.
- Add identity review to design-time workflows Bring IAM or security architecture into the first review of new features that touch permissions, export functions, or privileged workflows.
- Compare shipped behaviour against approved intent Create a control that reconciles the final implementation with the approved specification so that missing tenant checks, broader data exposure, or absent audit events surface as findings instead of incidents.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- The concrete Foresight workflow for reading PRDs, tickets, and diff descriptions before code exists
- Examples of how design-time threat models are generated from the live codebase and kept current
- The way Pixee connects reactive triage with design-stage review in a single context graph
- The CSV export example showing which questions the source article uses to surface hidden assumptions
👉 Read Pixee's analysis of spec-driven development security and AI-generated code →
Spec-driven development security: what IAM and AppSec teams miss?
Explore further
07/09/2026 4:38 pm
Spec-driven development security is now a governance discipline, not just an AppSec concern. When AI turns intent documents into code, the specification inherits the burden of defining access, data handling, and audit expectations. That makes the spec a control surface that belongs in both secure development and identity governance conversations. Teams that only validate delivered code are reviewing the wrong artefact. The practitioner conclusion is clear: govern the intent layer or keep discovering policy drift after release.
A question worth separating out:
Q: How do identity and AppSec teams share accountability for spec-driven development security?
A: AppSec owns the control checks on the implementation, but identity teams own the correctness of role and access assumptions embedded in the design. The strongest model is shared accountability at design time, where entitlement scope, privileged workflows, and data exposure are reviewed together. That prevents access decisions from being hidden inside a development ticket.
👉 Read our full editorial: Spec-driven development security is now the new attack surface
