The New Attack Surface: Managing Risk in an AI and Open Source World

AI has changed how fast software gets written. What it hasn't changed is how fast organisations can find and fix what's wrong with it. This gap is the subject of a recent episode of the Security Strategist Podcast, hosted by Christopher Steffen, Vice President of Research at Enterprise Management Associates (EMA), with guests Chris Wysopal, Co-Founder and Chief Security Evangelist at Veracode, and Sohail Iqbal, the company’s Chief Information Security Officer. This conversation lands on a simple but uncomfortable idea that security teams don't have a detection problem anymore. They have a capacity problem, and it's getting worse every day as AI writes more of the code running in production.

AI Code Is Creating a Security Crisis

Wysopal opened the discussion by reframing the industry's biggest AI worry. Static analysis, fuzzing, and AI-assisted scanning already do a solid job of surfacing vulnerabilities, and humans still know how to fix what gets found. The real issue that has now been created is the volume. As Wysopal put it, the problem is one of capacity, not detection or fixing. He estimated that roughly half of new code committed daily is now AI-generated, a figure he expects to keep climbing.

Steffen pushed the point further, framing it as a maturity problem rather than a purely technical one. When a developer writes their own buggy code, they understand the context well enough to fix it. When AI generates that code, the organisation may not even know where to start looking for the flaw, let alone how to remediate it safely without breaking something else.

Iqbal agreed, describing it less as a capacity issue and more as a scale-and-velocity issue that has overwhelmed capacity that was already stretched thin. This is due to AI models which learn from existing code repositories and open-source projects. As a result, they tend to reproduce the same flaw density found in that training data. The models are just as capable of finding and exploiting those flaws, and Iqbal noted that the window between a vulnerability's disclosure and an active exploit has shrunk to somewhere between four and eight hours. Fixing code, he explained, requires understanding business context and dependencies, since a careless patch can break twenty other things just as easily as it fixes one.

Regulation Is Slowing AI Adoption

Highly regulated sectors such as banking, healthcare and government are the most cautious about AI-written code, and for good reason. Wysopal pointed out that regulations like Sarbanes-Oxley or HIPAA will definitely require a human to review every code change. Those review processes were built for the speed of human developers, not machines producing changes around the clock.

This mismatch can appear in unexpected places. Steffen recalled hearing CISOs at Black Hat explain that any vendor product with an AI component now has to undergo additional risk and governance reviews before it can be approved. While these checks are necessary, they also introduce another human checkpoint into the adoption process, potentially slowing how quickly organisations can put AI-enabled tools into production.

Iqbal said the bigger problem is that security rules and processes were designed for people, not AI systems that can develop software themselves. As companies increasingly use AI to write code, those rules are creating friction because it’s still unclear who is responsible when something goes wrong. If a human gives an AI a prompt and the system produces the code, who is ultimately accountable? Wysopal pointed to another challenge, which is visibility across the supply chain. Companies may rely on SaaS vendors that use AI to generate code, making it harder to know where the code came from and who is responsible for it.

Building Trust in the Software Supply Chain

If accountability is going to mean anything in an AI-driven pipeline, both guests agreed the industry needs to build assurance and trust directly into the development process. Iqbal said security is now paying more attention to the third part of the security triad: integrity. Companies have spent years protecting data from being exposed and keeping systems running. Now, they are focusing more on making sure data, transactions and code have not been changed or tampered with. On the defensive side, Wysopal was honest about the asymmetry security teams face. This means attackers can afford to break things while testing exploits, but defenders cannot. He pointed to an incident at Amazon where an AI-driven production fix caused a multi-hour outage as a cautionary example of why automated remediation in live environments still requires extreme care.

Their closing advice for security leaders was practical. Wysopal urged organisations to measure their actual remediation capacity, comparing bugs closed against bugs introduced, and to fund people and tooling accordingly, while moving security controls as close as possible to the moment code is generated. Iqbal emphasised breaking down tooling and telemetry silos so security teams can see risk in full business context rather than in isolated domains.

The takeaway from both guests is consistent: AI isn't going to slow down, and neither can the defences built around it. Organisations that treat security funding and remediation capacity as afterthoughts will find themselves falling further behind with every sprint. If you would like to find out more, follow Chris Wysopal and Sohail Iqbal on LinkedIn. Alternatively, visit Veracode for more information.

Takeaways

• AI's impact on development velocity and security.
• Capacity and maturity challenges in AI-generated code.
• Security risks and vulnerabilities from AI and open source.
• Regulatory and compliance hurdles in AI adoption.
• Accountability and data provenance in AI security.