By Ansgar Dodt, VP Product Management for Software Monetization at Thales
Not every piece of software is worth attacking.
Traditionally, that has offered software vendors a degree of protection. Reverse engineering takes time, specialist expertise and persistence, forcing attackers to weigh the potential reward against the effort involved. However, AI is beginning to change that trade-off.
Recent AI-powered security incidents, including cases disclosed by OpenAI and Anthropic, suggest this is not a one-off development but part of a wider trend. While much of the cybersecurity debate has focused on how AI is making attacks faster or more sophisticated, the bigger shift for software security may be an economic one. Reducing the time and human effort needed to identify and exploit potential flaws opens up more opportunities.
When attackers can afford to be less selective
Software that would never previously justified days of an expert’s time to reverse engineer may become worth investigating when AI can perform much of the initial work. Attackers no longer need to concentrate their time and resources solely on a handful of obvious, high-value targets when they can now seek a wider range of choices.
AI agents can increasingly interact with decompilers, debuggers and other security tools, interpret unfamiliar code and test different approaches. If one avenue proves unsuccessful, another can be explored with less continuous human involvement.
This doesn’t mean specialist expertise becomes irrelevant, or that an AI agent can instantly compromise any application. But it does allow attackers to investigate more potential targets with the same resources, making software they might previously have ignored worth a closer look.
When software leaves your control
Once software leaves a vendor’s environment, attackers have more opportunity to analyse it. Cloud-native applications can largely remain within environments controlled by their providers, but desktop applications, on-premise deployments, industrial equipment, connected devices and edge software create a different problem: executable code is placed directly into an environment the developer may no longer control.
From the moment someone obtains that binary, time is on their side. It can be examined privately and repeatedly for vulnerabilities, proprietary algorithms, cryptographic routines, privileged functionality or other valuable information. The consequences can extend well beyond the security team: exposing proprietary code or vulnerabilities can lead to intellectual property theft, operational disruption, regulatory consequences and loss of customer trust.
As automated analysis becomes more capable, vendors should increasingly assume that valuable software distributed outside their environment will eventually be subjected to AI-assisted analysis.
Security approaches therefore need to account not only for preventing unauthorised access to software, but also for what an attacker can learn once they have it.
Patching only works once you know the problem
The fundamentals of security hygiene endure, with secure development, vulnerability testing and rapid patching remaining fundamental. But a vulnerability cannot be fixed until it has been identified, and no development process can guarantee that every weakness will be discovered before software reaches customers.
As AI makes it easier to continuously probe deployed applications, defenders face increasing pressure to find and remediate weaknesses before an attacker does. Patching and application protection therefore need to work together: patching fixes known vulnerabilities, while application protection makes any weaknesses that remain harder for attackers to discover and exploit.
Making software harder to attack
The aim isn’t to make reverse engineering impossible. It is to make software harder and more time-consuming for an attacker to understand and take apart.
Different layers of protection can disguise how software works and make it harder to analyse, alter or copy. These include techniques that obscure code and data, detect attempts to tamper with an application, or protect it while it is running. Together, these measures create additional barriers an attacker must overcome.
In combination, their value is cumulative: each additional barrier forces an attacker to spend more time and computational resources analysing the software.
Thales recently tested this in practice. An autonomous AI reverse-engineering agent analysed two versions of the same application, each containing ten deliberately planted vulnerabilities. Against the unprotected binary, it identified eight in approximately three minutes. Against the protected version, it continued for more than six hours, consumed around 970 times as many tokens and stopped without identifying an actionable vulnerability.
Making vulnerabilities harder to discover can buy vendors time to identify weaknesses themselves, develop and validate patches and deploy updates before an issue can be weaponised at scale.
Changing the attacker’s calculation
AI will continue to reduce some of the constraints that have historically shaped software attacks. Organisations cannot control how quickly those capabilities improve or who gains access to them.
Nor can they stop AI from lowering the cost of analysing software. But they can change the economics of attacking their own applications by making them more difficult and resource-intensive to analyse. Eliminating vulnerabilities remains the priority, but so does increasing the time, compute and effort required to find and exploit those that inevitably remain.
If attackers increasingly have the resources to look everywhere, making your software a costly place to look may become a defence in itself.
