Topic starter
24/10/2026 8:50 pm
TL;DR: Machine-generated code and faster attack automation widen the gap between code creation and protection, according to Armis. AppSec needs earlier controls that cut exposure before flaws spread through pipelines or reach production.
Editorial analysis by NHI Mgmt Group, based on content published by Armis: “Application Security Was Built for a World That No Longer Exists”.
Key questions
Q: Why do model-generated code changes increase AppSec risk so quickly?
A: Model-generated code increases risk because it can introduce insecure patterns at a speed that outpaces manual review and creates repeated defects across many files or services.
Q: What are the signs that backlog-driven application security is failing?
A: Common signs include growing unresolved findings, repeated late discovery of the same classes of issues, and a widening gap between code creation and remediation.
Q: What breaks when AppSec is treated as a late-stage scan?
A: Late-stage scanning misses the point where insecure code, hardcoded secrets, and risky dependencies enter the system.
Practitioner guidance
- Embed security at code creation Move policy checks, analysis, and guardrails into authoring and build workflows so insecure code is intercepted before it enters the backlog.
- Redefine security success metrics Track the share of risky code prevented from reaching production, not only the number of vulnerabilities found or closed.
- Prioritise contextual code analysis Use controls that reason about intent and behaviour, especially where generative tools or agentic workflows create code paths that templates do not anticipate.
Bottom line: Application security built around late-stage detection cannot keep pace with machine-generated code and automated attackers.
Glossary terms: Shift Zero, Prompt Exposure Gap, Machine-Speed Security, Contextual Static Analysis
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:12 am
Shift zero is a governance problem, not just a tooling problem. The article correctly identifies that security built around delayed review assumes a human pacing model that no longer exists. Once code is created continuously, the real control question becomes where prevention sits in the delivery chain. Practitioners should treat this as a workflow governance issue, not a scanning-speed issue.
A question worth separating out:
A: DevOps teams should treat security and developer experience as shared delivery goals, not competing functions. The practical approach is to define clear production access rules, use break glass procedures where needed, and preserve a single operating language with security. If controls make ordinary work slow or opaque, MTTR and time to value suffer, which can hurt both reliability and business outcomes.
👉 Read our full editorial: Shift zero changes application security for machine-speed code
This post was modified 6 days ago by NHI Mgmt Group