AI-assisted development is increasing the volume and speed of code moving toward production. Respondents to the Sembi Software Quality Pulse Report estimate that, on average, 53% of their organization’s code is now AI-generated or AI-assisted.¹ That puts more pressure on security processes already concentrated around the build and release stages.
Static analysis, code review, dependency scanning, and CI/CD checks help teams find vulnerabilities before software ships. These controls are essential, but they primarily answer one question: Is this code protected?
A different set of risks emerges after deployment. Once an application reaches a user-controlled device, browser, partner server, or other external environment, an attacker may have extensive time to inspect its logic, analyze its behavior, or attempt to modify it.
Post-deployment application security addresses the gap between securing code before release and protecting it once it is running outside the organization’s direct control.
According to the Sembi Software Quality Pulse Report, 32% of respondents selected AI- and LLM-related exploits as one of their top three security priorities.²
This is distinct from the risks associated with AI-generated code during development. The 32% finding focuses on how AI and LLMs can be used as part of an attack, including against applications that have already been released.
Attackers can use generative AI to accelerate parts of application analysis, such as interpreting decompiled code, explaining unfamiliar functions, tracing dependencies, and identifying logic or controls worth targeting. Work that once required more time, specialized expertise, and higher costs can now be accelerated or partially automated.
That changes the economics of post-release attacks. Attackers may be able to assess more code, test more potential attack paths, and refine their techniques faster than they could through manual analysis alone.
Build-time security can identify vulnerabilities before software ships, but it cannot prevent someone from obtaining a deployed application and attempting to analyze or modify it. As AI lowers the effort required to conduct post-release attacks, protecting applications after they leave the development pipeline becomes a more important part of the security strategy.
Most application security programs are strongest during development and release. Static analysis identifies vulnerable patterns in source code, code review catches logic and policy issues, dependency scanning finds known risks in third-party components, and CI/CD controls prevent builds with identified problems from moving forward.
These controls remain essential. Once an application is deployed, however, security becomes harder for the organization to control directly.
The software may be running on a user’s device, a partner’s server, or another environment outside the development team’s visibility. An attacker who obtains a copy of the application can work against it on their own time by decompiling it, tracing its logic, identifying exposed information, or testing ways to alter its behavior.
AI can accelerate much of that work. It can help explain decompiled functions, map relationships between application components, identify potentially valuable logic, and generate or refine scripts used during analysis. Tasks that once required more manual effort, specialized reverse-engineering expertise, and higher costs can now be completed faster and at greater scale.
Consider a mobile or desktop application that passed a SAST scan, dependency audit, and code review before release. Those checks reduce the likelihood that known vulnerabilities reach production, but they do not prevent an attacker from stepping through the deployed application in a debugger or examining its compiled logic.
That analysis may reveal hardcoded API keys, licensing controls, proprietary algorithms, or other valuable application behavior. Sensitive credentials should not be embedded in client-side code, but their presence in deployed applications remains a risk. With AI assisting the analysis, attackers may be able to interpret their findings and test potential bypasses more quickly than they could through manual investigation alone.
Attackers may also attempt to patch out a license check, disable a security control, insert malicious code, or redistribute a modified version under the original application’s name. These attacks do not always require a conventional vulnerability. In some cases, access to an insufficiently protected build is enough to begin.
The Sembi Software Quality Pulse Report found that 37% of respondents say their organization slightly or strongly favors delivery speed over risk management.³
Image: Sembi Software Quality Pulse Report, First Edition, 2026
That pressure makes it difficult to add more manual review every time development output increases. Teams can strengthen code review, scanning, and release gates, but those controls must still operate within delivery timelines that are already compressed.
Post-deployment protection gives teams another way to manage that tradeoff. Obfuscation, tamper protection, and runtime controls can be applied through the build and release process, extending protection into production without introducing another manual review checkpoint before every release.
This does not reduce the need for secure development, testing, or review. It allows teams to address a different category of risk without relying on people to manually anticipate every way an application could be analyzed or manipulated after release.
The goal is to make protection part of the delivery process so it can scale with the volume and pace of software being released.
Just over 9% of respondents report that their security tools are fully integrated with DevOps workflows.⁴ Most organizations have achieved some level of integration, but many still rely on partial connections, manual handoffs, separate tools, or delayed feedback between security and development.
Image: Sembi Software Quality Pulse Report, First Edition, 2026
This finding does not directly measure whether teams use post-deployment application protection. An organization can have a partially integrated toolchain and still use code obfuscation, tamper detection, or runtime controls. It does, however, show how difficult it can be to apply security consistently across the full application lifecycle when tools and workflows are not fully connected.
The report also found that 19% of respondents selected AI-generated code risk as one of their top three security priorities.⁵ This concern is separate from the 32% focused on AI- and LLM-related exploits. AI-generated code risk refers to insecure patterns, errors, or vulnerabilities introduced during development, while AI-assisted post-release attacks involve attackers using AI to inspect, understand, or manipulate an application after it has shipped.
Security teams need to prepare for both. Build-time tools help identify risks before release, while post-deployment controls help protect applications from reverse engineering, unauthorized modification, and runtime manipulation after they leave the development environment.
Addressing those post-release risks typically requires several controls working together.
Code obfuscation transforms an application’s structure before release, making its logic more difficult to understand after decompilation.
Depending on the application and platform, an obfuscation tool may rename classes and methods, change control flows, encrypt strings, remove useful metadata, or apply other transformations that increase the time and effort required to reverse engineer the software.
Obfuscation does not make analysis impossible. Its purpose is to prevent a deployed application from giving an attacker a clear and easily readable map of its internal logic.
Tamper detection helps an application recognize when its code, files, configuration, or execution state no longer match what was originally released. These controls can identify attempts to patch application logic, remove licensing checks, disable security functions, insert unauthorized code, or repackage and redistribute a modified build.
Once tampering is detected, teams can define how the application should respond based on the level of risk and the intended use case. That response may include logging the event, restricting certain functions, ending execution, or alerting another system.
Runtime application self-protection, or RASP, monitors the application while it is running and responds to suspicious activity or unexpected conditions. Depending on the application and implementation, runtime controls may detect debugger attachment, runtime hooking, rooted or jailbroken devices, unexpected execution environments, or attempts to interfere with application behavior.
These protections give teams visibility into activity that pre-release scans cannot observe because it occurs only after the application has been deployed.
Obfuscation, tamper detection, and runtime protection address different but related risks. They complement SAST, dependency scanning, code review, penetration testing, and other build-time security controls by extending protection into the part of the application lifecycle that begins after release.
Data breaches led the report’s security priority list, selected by 39% of respondents as one of their top three concerns for the next 12 months.⁶
Image: Sembi Software Quality Pulse Report, First Edition, 2026
Not every data breach begins with reverse engineering or application tampering. Weak protection after deployment can, however, give attackers another path to sensitive logic, data flows, application functions, or connected systems.
An attacker who can understand or modify an application may be able to bypass intended controls, misuse trusted functionality, expose sensitive information, or identify a path deeper into the organization’s environment. Those actions can contribute to a broader security incident.
This is why security cannot end with determining whether an application is safe to ship. Teams also need controls designed to protect the application once it is outside their direct control.
PreEmptive helps development and security teams protect .NET, Java and Android, and JavaScript applications after deployment through code obfuscation, tamper detection, and runtime application protection.
These controls are applied through existing build and release workflows, helping make deployed applications harder to understand, modify, and misuse. PreEmptive complements static analysis, dependency scanning, code review, and other pre-release security practices by extending protection into the part of the application lifecycle that begins after software ships.
See how PreEmptive approaches it.