AI Cyberattacks Are Changing the Economics of Software Security Testing
AI-powered cyberattacks are changing how attackers identify weaknesses, investigate systems, and target organizations. As some of the work involved in finding vulnerabilities becomes easier to automate, traditional software security testing needs to evolve. The goal should no longer be to produce more vulnerability reports, but to establish which weaknesses attackers can actually exploit and reduce the risks that matter most.
In October 2026, CrowdStrike reported on a campaign targeting South Korean financial organizations between late September and early October. According to its investigation, an unknown threat actor used ARTEX, an open-source AI-powered penetration testing tool developed in China, alongside Anthropic's Claude Code and AI models including DeepSeek, GLM, and Grok.
What matters isn't just how AI was used in this particular campaign. It's what the case suggests about the direction cyberattacks are taking.
How AI Is Changing the Economics of Cyberattacks
Sophisticated cyberattacks have traditionally required considerable technical expertise, time, and resources. Attackers needed to understand unfamiliar technologies, investigate potential weaknesses, and develop methods to exploit them.
All of that came at a cost.
AI is changing parts of that equation.
AI-powered tools can help attackers explore unfamiliar systems, identify potential vulnerabilities, and automate repetitive tasks. While these capabilities do not guarantee successful attacks, they can reduce the time and effort required for certain stages of an operation.
And when investigating potential targets becomes less expensive, more organizations may become attractive targets.
This is where I believe many businesses are making a dangerous assumption.
Small and midsize businesses have often assumed that sophisticated attackers have bigger targets to pursue. They may not hold as much customer data as a global bank or attract the same public attention as a major corporation.
But size alone offers little protection.
If attackers can investigate more organizations with less effort, a company doesn't have to be particularly large or well-known to become an opportunity. Small businesses, SaaS providers, and organizations with limited security teams may also have fewer resources to detect and respond to an attack.
Being a smaller target doesn't make you a harder target.
Why Traditional Software Security Testing Needs to Evolve
I've spent more than two decades working in technology and software security. One lesson I've learned is that the tools we use to solve a problem can become part of the problem when threats evolve but our methods don't.
I believe software security testing is approaching that point.
We've become good at finding vulnerabilities. We have automated scanners, security dashboards, testing frameworks, and reports filled with findings.
But a long vulnerability report isn't the same as a secure application.
Knowing that a weakness exists is also different from knowing whether an attacker can exploit it.
If attackers are becoming faster at investigating systems, defenders need to become better at determining which weaknesses present genuine risks and responding accordingly.
Simply generating more alerts isn't enough.
Here are five changes I believe matter most.
1. Prioritize Exploitability Over Vulnerability Counts
A security scanner identifies an exposed endpoint or an outdated software component. That's useful information.
But what can someone actually do with it?
That is the question security testing should answer.
Can the weakness be exploited under the application's actual operating conditions? What level of access could it provide? Which systems or sensitive information could an attacker reach?
These questions require more than identifying a known vulnerability or assigning a severity score.
Security teams need to distinguish between weaknesses that are theoretically concerning and those that create a credible path to compromise.
Without that context, organizations risk spending valuable time addressing findings that look serious on paper while more consequential weaknesses remain unresolved.
Vulnerability detection is the starting point, not the end goal.
2. Test Attack Paths, Not Just Individual Vulnerabilities
Real cyberattacks don't always depend on one critical vulnerability.
Sometimes, several relatively ordinary weaknesses become dangerous when combined.
Consider an exposed API, excessive user permissions, and broken authorization controls. Individually, each finding might appear manageable. Together, they could create a path to sensitive information that none of the findings fully explains on its own.
This is why software security testing needs to examine how weaknesses interact across an application.
AI-assisted penetration testing can help security teams investigate possible attack paths and identify combinations of vulnerabilities worth examining.
But there is an important distinction between identifying a plausible attack path and proving that it works.
Potential paths still need to be validated against actual application behavior, within an authorized testing environment.
The objective should be to understand what an attacker could realistically achieve, not simply what individual scanners detect.
3. Make Security Testing Continuous, Not a Pre-Release Exercise
Applications don't remain unchanged after passing a security assessment.
Developers release features. APIs evolve. Software dependencies receive updates.
Configurations change, sometimes without anyone immediately noticing the security implications.
A clean assessment last month cannot rule out a vulnerability introduced yesterday.
That is why security testing needs to extend across development, deployment, and ongoing operations.
Automated security checks can help identify regressions as applications change, while deeper assessments can investigate weaknesses that require additional context or validation.
The two approaches should complement each other.
Organizations that rely exclusively on occasional penetration tests may leave significant gaps between the introduction of a vulnerability and its discovery.
The objective should be to reduce that gap rather than accept it as an unavoidable part of software development.
4. Use AI to Improve Security Testing, Not Generate More Alerts
AI has considerable potential to improve software security testing.
It can help generate test cases, investigate application behavior, explore possible attack scenarios, and reduce the time spent on repetitive analysis.
These capabilities can be particularly valuable for security teams that lack the resources to investigate every potential weakness manually.
At ZeroThreat, which I co-founded, we focus on automated penetration testing and vulnerability validation for web applications and APIs. This work reflects a principle I consider essential: security testing should help organizations understand which vulnerabilities pose real risks, rather than simply generate more findings.
But AI introduces its own limitations.
AI systems can produce convincing conclusions that turn out to be incorrect. A suggested vulnerability may not exist under the application's actual conditions. A proposed attack path may fail when tested.
More AI-generated findings therefore do not automatically translate into better security.
I'd rather see AI help a team investigate fewer, more consequential questions thoroughly than generate hundreds of additional alerts that someone still needs to review.
Automation should help security teams move more efficiently from identifying a potential problem to understanding its implications.
It shouldn't simply relocate the bottleneck.
5. Measure Risk Reduction Instead of Completed Security Tasks
Security teams often measure progress through familiar metrics.
How many vulnerabilities were identified? How many tickets were closed? How quickly did developers resolve reported issues?
These numbers have their place.
But they don't necessarily tell us whether an organization is becoming more secure.
A vulnerability's severity score can inform prioritization, but it needs to be considered alongside exploitability, exposure, required privileges, accessible data, and the business functions that could be affected.
Security teams also need to verify that remediation measures actually close the identified weakness without introducing new problems.
This calls for a different way of evaluating security progress.
Instead of focusing exclusively on the number of findings resolved, organizations should examine whether those fixes have meaningfully reduced their exposure to realistic attacks.
The most important question isn't how much security work we've completed. It's how much risk we've actually removed.
What AI-Powered Cyberattacks Mean for Smaller Businesses
The shift toward AI-assisted cyberattacks has implications beyond large banks and multinational enterprises.
Smaller organizations also operate applications, APIs, customer databases, and business-critical services that attackers may find valuable.
They may face the same types of software vulnerabilities as larger companies without having comparable security budgets or dedicated response teams.
This makes prioritization especially important.
A smaller security team cannot investigate every finding with equal intensity. It needs reliable evidence to distinguish meaningful risks from less consequential alerts and focus its efforts where they can make the greatest difference.
AI-assisted testing may help with that process, provided its conclusions are validated rather than accepted automatically.
The broader challenge is to make security testing more effective, not merely more frequent.
The Future of Software Security Testing Is About Risk Removed
I don't believe the answer to AI-powered cyberattacks is simply to deploy more AI in cybersecurity.
That could mean repeating the same mistake at greater speed: generating more activity without necessarily improving the outcome.
What we need is security testing that can investigate vulnerabilities, validate whether they are exploitable, understand how weaknesses connect, and provide evidence that teams can act on.
AI can make parts of that process faster, but speed only matters when the results are reliable.
And this challenge isn't limited to major enterprises.
Smaller businesses have applications, APIs, sensitive information, and operational dependencies worth protecting. They cannot afford to assume their size makes them invisible or that a clean vulnerability scan guarantees their security.
The question I keep coming back to is this:
Are we measuring how much security work we're doing, or how much risk we're actually removing?
Those are not the same thing. And as AI changes the economics of attacking software, the difference will become increasingly important.
