Veracode’s 2025 GenAI Code Security report found that AI coding tools produce insecure code nearly half (45%) of the time.
Risk velocity and the new accounting for security debt
AI has accelerated the pace of software creation. The op-ed argues that the central security metric must shift from discovery to "risk velocity": how quickly new software risks are created and how quickly they are reduced or eliminated. When code generation outstrips the capacity to review, test, and remediate, "security debt accumulates faster." In short, risk now enters the enterprise at machine speed while many organizations still manage it with human-scale processes — and the result is a growing backlog of unresolved vulnerabilities that can eventually constrain the business.
Familiar failure modes amplified by AI
AI coding tools can reproduce insecure patterns found in their training data: weak input validation, unsafe authentication flows, insecure direct object references, hard-coded secrets, and vulnerable dependency choices. The op-ed also highlights how AI can miss the runtime and organizational context that makes code secure or not — authorization models, tenant boundaries, data sensitivity, production configurations, and how services interact in a real application. There is a human factor too: under deadline pressure developers may accept code that "works" without fully understanding it. The piece warns that "Code compiles, tests pass, features ship, and hidden risk enters the system," producing misplaced confidence.
Supply-chain risk: bigger than the code itself
Modern applications are assembled from open-source components, frameworks, plugins, containers, APIs, and cloud services — and AI tools can recommend outdated packages, vulnerable libraries, or nonexistent dependencies. The report points to a realistic attack vector: an "amusing hallucination" becomes dangerous if an attacker registers a malicious package with a similar name and waits for developers or automated tools to pull it in. The op-ed frames this as a supply-chain exposure that can convert a coding shortcut into a producible compromise.
"Shift Left" needs an enforcement layer — secure-by-design as infrastructure
The industry has spent years moving security earlier in the development lifecycle, but the op-ed says many organizations moved findings closer to developers without also moving ownership, automation, and remediation capacity. As software output increases, security "cannot remain a checkpoint near the end of the process. It must become a continuous control system built into the way software is created, tested, approved, and deployed."
To make "secure-by-design" practical, the piece prescribes engineering environments where unsafe choices are harder to make: approved frameworks, secure defaults, reference architectures, dependency controls, automated testing, and policy enforcement embedded directly into developer workflows and CI/CD pipelines. It argues remediation must be proximal to creation — ideally an inline fix proposed, validated, and governed as part of the normal development process — but notes a counterintuitive impediment: many developers "don’t trust AI to automatically remediate code without human review," which slows fixes back to human speed.
What this means for CISOs, boards, and engineering leaders
- For CISOs and engineering leaders: treat AI-generated code as untrusted until proven safe; require automated testing before release; enforce dependency controls; prioritize remediation by exploitability and business impact; and measure success by how quickly critical risk is reduced.
- For boards and organizational policymakers: demand demonstrable governance of AI-assisted software before deployment. The op-ed specifies the key evidence boards should ask for — the policies applied, the tests performed, the vulnerabilities remediated, the risks accepted, and the approvals recorded.
- For procurement and operations teams: track where AI-generated code enters the environment and document the policies and tests applied. The piece warns that while many organizations can track tool outputs today, few can demonstrate how that output was secured, reviewed, and governed prior to production.
AI is changing the tempo at which software risk moves through enterprises. The op-ed's closing prescription is direct: security must keep pace by embedding governance, remediation, and proof into the software delivery pipeline so that machine-speed creation is met with machine-speed controls. The challenge is operational and evidentiary — can organizations show not just that they use AI tools, but that the outputs were tested, governed, and accepted in accordance with policy before deployment?
