When everyone can code: How AI breaks traditional software security

Most enterprise software governance frameworks rely on the assumption that software authorship can be reasonably bounded and clearly defined by role. AI code generation has quietly made that assumption obsolete.

Tools such as Codex and Claude Code have fundamentally changed the software development profession. The benefits are sometimes hyperbolic in their characterizations—no one is really becoming a “10X developer” through prompting today’s tools, even in concurrent workflows. But it’s undeniable that they are reshaping the way we specify, architect, refine and test code.

What’s more interesting is what’s happening at the margin, when companies extend these powerful tools to technical experts who are not professional software engineers. The extension of these technologies both enables more people to contribute software solutions to business problems and also creates unintended consequences across GRC and application security teams.

In most technology service providers, software is typically found in three places: a core software product, supporting CI/CD and infrastructure-as-code pipelines and a smattering of automation scripts that aid IT and other teams with bespoke business-process automation. Many companies define rigid software development lifecycle (SDLC) documents that state who writes software, how they do it and the quality assurances built around that workflow. This traditional model not only makes for happy auditors, with clearly defined processes, but also subtly reinforces the distinction that some people are developers and some are not.

Because I previously worked as a software engineer, I see this shift from both a development and security leadership perspective.

The Inventory Problem

In my role, I often ask, “Am I creating a problem here?” And perhaps, when I use coding agents in this way, I am. People who fit my profile—technicians at the margins who can be brought into coding—break down the key distinctions in SDLC documents. This creates a real control-attribution problem for companies: uncertainty about who is building software artifacts, which controls apply to them and when those artifacts transition into security-relevant systems.

While my initiative could unintentionally bypass governance designed for SDLC workflows, imagine the blast radius when the same tools fall into the hands of product managers, analysts or operations staff with no secure coding experience.

To be clear, enterprises have always lived with forms of “shadow software”: spreadsheets, scripts and low-code tools created outside formal development teams. What is different now is the speed, fidelity, variability and ease with which these artifacts cross into production-adjacent systems.

Unless we use draconian measures to stifle innovation and restrict code-generation tools to a predetermined subset of employees, we can no longer confidently categorize roles as “coder” or “non-coder.” Some governance and compliance regimes, such as PCI DSS 6.4, implicitly assume that software development occurs within clearly defined roles and workflows. This assumption becomes harder to validate as development capability diffuses across the organization.

It also creates ambiguity for security teams. We may not be identifying and training the right people about secure software design and defensive coding practices. An internal CLI tool to automate a process might not warrant the same secure developer training we deploy to professional software engineers today. However, as it comes easier and faster for a variety of roles to create and deploy AI-generated public-facing web applications, it would be negligent to forgo the necessary and relevant security training for those employees, too.

Another aspect of the inventory problem is that not only are we less clear about who is developing software, but we are also less confident about our total inventory of applications and data flows. Line-of-business applications that materialize in an afternoon are unlikely to be covered by role-based access controls, vulnerability scanners and other security assessment tooling.

In addition, while software engineers are often provisioned environments with security trade-offs—including elevated access, specialized compilers and local network configurations for testing—those same trade-offs can be a recipe for disaster for roles more likely to be targeted by malspam and ransomware operators. Trying to fit everyone into a traditional developer role so they can benefit from code generation ultimately undermines our ability to reason clearly about software risk. The result is that organizations may over-privilege more accounts, extend powerful capabilities without sufficient training or context and weaken governance across a growing surface area of software.

Modern Problems Require Modern Solutions

Just as traditional network security perimeters dissolved with the rise of cloud computing and fully remote workforces, so too are the binary distinctions that many software security and identity management models have relied on for decades. The idea that organizations can clearly separate “developers” from “non-developers” is no longer defensible in a world where capable software can be generated on demand by anyone with domain knowledge and access to an AI-assisted code generation tool.

If security teams are to remain credible enablers of the business, they must redesign controls for a world where code creation is ubiquitous, environments matter more than titles, and governance follows software artifacts rather than people. Organizations that adapt to this reality will safely unlock more innovation. Those that do not will find, often through incident, friction or audit, that their control frameworks are already obsolete.

Sean McElroy
Chief Risk Officer, Lumin Digital