7 Application Security Trends

Application security is shifting toward a continuous, layered approach. Developers need support that protects application design, validates AI-generated and third-party code, and integrates directly into build pipelines. Such solutions must be suitable for deployed software and provide strong runtime defenses. 

In this guide, we explore emerging application security trends, their risks, and how to respond effectively.

---

Application security trends at a glance

Trend	Primary Risk	Recommended Action
AI-generated code	Code may contain insecure patterns.	Do a thorough review of generated code before deploying it into a codebase.
Software supply chain security	Third-party dependencies may have unknown security vulnerabilities.	Maintain a log of an application’s dependencies, libraries, and other third-party components. Update components when necessary and remove them when a third-party stops providing support.
Secure by Design	Failure to implement security throughout the build process may result in weaknesses.	Define application security requirements from the beginning and implement them into the development process.
Runtime application protection	Attackers reverse engineer or tamper with apps for their own benefit.	Implement runtime security tools that detect and block tampering and debugging tools.
Faster vulnerability exploitation	Bad actors uncover exploits before software teams do, resulting in a data breach.	Have a multi-layered security strategy that includes risk modeling, automated testing, and steps to quickly address threats.
API, mobile, and client-side security	Attackers seize on API, mobile, or client-side vulnerabilities to exploit an application.	Track API use and employ proper authorization controls to prevent attacks.
Security consolidation and automation	Alert fatigue causes teams to overlook critical security alerts.	Use a single platform to combine security alerts from multiple sources. Prioritize alerts based on potential risk and assign them for prompt remediation.

1. AI-generated code increases security review demands

According to a 2026 report on AI Coding Assistants and New Security Challenges from Salt Security, 67% of respondents say that AI coding assistants are widely deployed among development teams. These assistants can generate code in seconds, enabling teams to increase development speed. However, there are several worrisome downsides.

Not all AI-generated code is secure by design. There’s a risk that generated code may contain insecure, outdated, or inappropriate patterns. To protect against flaws, AI-generated code must be thoroughly reviewed and tested before submission into production.

Of the leaders surveyed in the Salt Security report, 90% cited concerns about AI-generated code security. They worry that testing isn’t complete, or that it doesn’t align with internal security policies. To combat this risk, organizations must implement strong governance, with a list of tools that are approved for use, review and testing requirements, and accountability when AI-generated code goes wrong. A manual review process must be part of development, especially in scenarios involving sensitive logic.

2. Software supply chain security expands beyond open-source dependencies

Supply chain security vulnerabilities exist wherever there’s a dependency on a third-party vendor, open-source package, or tool. As many software applications rely on third-party components for feature extension and usability, vulnerabilities pose a considerable risk. The Open Worldwide Application Security Project (OWASP) lists software supply chain failures as A03 in the OWASP Top 10:2025 for web application security risks. 

Checking libraries for known vulnerabilities isn’t enough to curtail the dangers of a supply chain breakdown. Instead, organizations must take a comprehensive approach to managing third-party dependencies. Application security best practices include:

• Track versions used for open-source and third-party dependencies. Make sure to only use package repositories and third-party tools that are regularly updated with security patches.
• Create a Software Bill of Materials (SBOM) for your entire application. An SBOM helps teams monitor third-party dependencies and track versions and updates.
• Regularly update the software used in CI/CD workflows.

Apply a clear change management process across the supply chain that tracks changes to the code repository, infrastructure, container images, and artifacts. Integrating artifact signing can help verify that changes are authentic and retain their integrity.

3. Secure by Design replaces bolt-on security

Instead of treating security as the final step before product deployment, teams are integrating it throughout the build process. This approach follows recommendations by the National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA).

Under CISA guidelines, Secure by Design requires an investment of resources in each stage of the development process, instead of “bolting” them on later. Under this policy, security is prioritized as a must-have, even if its features aren’t obvious to customers.

NIST includes several techniques in its Secure Software Development Framework (SSDF) Version 1.1 that teams can implement for a Secure by Design approach. They include:

• Defining and documenting an application’s security requirements during the planning phase
• Securing the development environment and its endpoints with default configurations that protect against unauthorized or unnecessary access
• Using risk modeling techniques, such as threat or attack modeling, to understand the security risks of an application
• Incorporating automated testing to catch vulnerabilities throughout the development process
• Performing dependency and code analysis to identify potential issues that may affect an application’s security
• Regularly monitoring and maintaining an application for security vulnerabilities after its release

A Secure by Design approach can’t protect against every cyber threat, but it does reduce the likelihood of a successful attack. 

4. Runtime application protection closes the post-deployment gap

Applications that pass security testing still face risks, particularly when they’re run in environments outside a software provider’s control. Potential threats include:

• Reverse engineering: Inspecting compiled code, bytecode, APKs, JavaScript bundles, or packaged artifacts to understand how an application works and potentially replicate or abuse its logic.
• Decompiled or inspected application logic: Reveals code logic and algorithms that can help threat actors identify security vulnerabilities
• Code tampering and repackaging: Allows hackers to reverse engineer an app and recompile it to steal user data or spread malware
• Unauthorized debugging: Used to inspect or tamper with an application to gain access to sensitive user or business data
• Extraction of sensitive strings: Gives hackers access to valuable assets, such as encryption keys and APIs
• AI-assisted analysis: Leverages AI tools to detect an application’s security vulnerabilities

Avoiding these risks requires layered application hardening, which includes: 

• Code obfuscation: Transforms shipped code into a harder-to-understand format while preserving intended application behavior.
• Control-flow transformations: Shifts code structure during execution, making it harder for attackers to follow its logic
• String and resource protection: Makes embedded strings, configuration details, and application resources harder to extract. Secrets such as passwords, private API keys, and signing keys should still be managed outside client-side or distributed application code whenever possible.
• Runtime application self-protection: Detects and blocks tampering and debugging attempts while a program is executed
• Runtime environment checks: Verifies that an application is running in an approved environment

Application-hardening tools may offer desktop and server application protection. For example, PreEmptive provides support for .NET, JavaScript, and Java applications with its portfolio of tools.

Keep in mind that application hardening complements other security measures, including vulnerability scanning, access controls, secure coding practices, and patching. It’s still critical to apply these practices throughout the software development life cycle.

5. Faster exploitation increases pressure on vulnerability response

The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation is now the leading access vector for data breaches, accounting for 31% of attacks. Hackers are taking advantage of application security vulnerabilities to steal user information and sensitive business data.

The rise in vulnerability exploitation makes it critical for teams to find security flaws, prioritize fixes, and implement patches before a bad actor can take advantage of them. Methods that can assist in this process include:

• Retaining an up-to-date inventory of an application and its components
• Prioritizing vulnerabilities according to their potential business impact and susceptibility to exploitation
• Identifying known and previously exploited vulnerabilities in an application and its third-party components
• Creating a rapid workflow for patching vulnerabilities
• Applying a defense-in-depth strategy with multi-layered security controls
• Continuing to monitor software for vulnerabilities after its release

Application hardening acts as a single layer in a comprehensive security strategy. It won’t eliminate the need to patch vulnerabilities or fix vulnerable source code. However, it does act as a key deterrent against hackers that seek to inspect or tamper with a deployed application.

6. APIs, mobile apps, and client-side code require specialized controls

APIs are integral to many mobile and web apps. They extend an application’s functionality and deliver features that users want. However, they’re also a frequent target among bad actors seeking to compromise them for their own benefit.

The most recent OWASP API Security Top 10 lists several mobile application security risks that APIs carry:

• Inadequate API inventory management: Failing to document API use and currently deployed versions risks deprecated or buggy connections that hackers may exploit.
• Broken function-level authorization: Lack of clear separation between everyday users and administrative authorizations may allow hackers to access sensitive information. Similarly, improper implementation of authentication tools can enable hackers to compromise a user’s profile.
• Broken object-level authorization: APIs may expose the endpoints that handle an application’s object identifiers. To avoid exposure, teams must apply object-level checks in all functions that access data sources through a user’s profile.

Rate limiting is another concern. Without proper controls on API requests, bad actors may take an application offline by hijacking its infrastructure. This can lead to significant expenses and downtime. 

In mobile and client-side applications, attackers may access deployed code using special tools. Exposed JavaScript, .NET, Java, and MAUI applications can reveal sensitive information, including proprietary logic, security mechanisms, sensitive strings, API endpoints, credentials, and application workflows.

PreEmptive tools are not API security products, but they help protect the client-side and distributed application code that communicates with APIs. They should be used alongside API testing, access controls, API gateways, server-side authorization, and monitoring.

7. Security teams prioritize exploitable risk over finding volume

Security teams receive a barrage of daily security alerts. This can lead to alert fatigue, where alerts are left uninvestigated due to a team’s burnout or inability to respond. 

To combat this risk, organizations are adapting new ways to interpret alerts and prioritize them effectively, such as:

• Consolidating alerts from development and security tools into a single platform
• Minimizing duplicate and low-value alerts, and adding context to help security teams understand their business and runtime context
• Identifying and prioritizing vulnerabilities based on their susceptibility to exploitation
• Assigning a clear trail of ownership to fix outstanding vulnerabilities
• Integrating security controls into the CI/CD pipeline
• Automating repeatable and redundant security tasks while retaining human oversight

Clear insight into each security alert’s overall risk profile helps teams define a relevant action plan without overwhelm.

How teams can respond to these application security trends

Secure software development starts with a plan. Implement this checklist to enhance application security before and after deployment.

1. Create an inventory: Know which application dependencies, APIs, build systems, and deployed artifacts exist in the software. 
2. Define security requirements: Determine what security features and threat models are necessary before beginning the development process. 
3. Test, test, test: Evaluate first- and third-party code throughout the development life cycle.
4. Implement application hardening: Protect high-value software with application-hardening tools.
5. Make security part of your workflow: Automate security testing and protection in CI/CD pipelines.
6. Use ongoing monitoring: Track the application’s behavior in production and runtime.
7. Thoroughly evaluate AI-generated code: Review AI-generated code under the same or stronger standards as human-written code.
8. Review and reassess: Introduce new controls whenever application architecture, dependencies, or threats change.

How PreEmptive supports layered application security

PreEmptive provides application-hardening tools that add build-time and runtime protection to deployed software, making it harder for attackers to reverse engineer, tamper with, or debug applications after release.

Our tools add build-time and runtime protection to deployed software, making it harder for attackers to reverse engineer, tamper, or debug the applications your team works so hard to build.

We offer a range of products for different platforms. They include:

• Dotfuscator: Hardens .NET and .NET MAUI applications using a multi-layer defense strategy
• DashO: Guards Android, Java, and Kotlin applications against reverse engineering and code tampering
• JSDefender: Protects client-side JavaScript applications against reverse engineering, tampering, and unauthorized analysis.

Each of our products uses a layered defense to protect your codebase from attacks. Code obfuscation converts codebases into an unreadable format, while string and resource protection can make embedded strings and resources harder to extract or interpret, reducing the value of static inspection.

PreEmptive products include runtime environment checks that identify when a user is operating your application in an unauthorized environment. Also included are anti-tampering and anti-debugging tools that detect and block attacks according to your settings. Our tools integrate with standard CI/CD workflows, making them easy to implement into your software development process.

To explore PreEmptive’s application protection options, start your free trial today.

---

Frequently asked questions