App attacks surged to 83% as AI-assisted malware expands

At a glance

What this is: Arxan Technologies says app attacks rose to 83% in January 2025, driven by AI-assisted malware and more accessible attack methods.

Why it matters: This matters because application security teams now need to defend apps outside the corporate perimeter while also accounting for identity, secrets, and trust controls that attackers increasingly target.

By the numbers:

• App attacks surged to 83% in January 2025, up from 65% in 2024.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Arxan Technologies' 2025 Application Security Threat Report

Context

Application attacks are no longer a narrow perimeter problem. When attacks climb while development speeds up, the practical gap is not just detection, but the ability to harden applications, govern embedded secrets, and maintain identity-aware controls across web, mobile, and desktop environments.

The article frames app security as a response to changing attacker economics, especially AI-assisted malware and easier attack tooling. That intersects with identity governance where application trust depends on credentials, tokens, and service identities that can be copied, reused, or abused outside traditional network boundaries.

Key questions

Q: What breaks when application secrets are not governed like identities?

A: Application secrets become durable access paths instead of controlled credentials. If they are embedded in code, shared across environments, or left unrotated, a single compromise can turn into persistent backend access. The failure is usually not discovery alone. It is the absence of ownership, expiry, and revocation discipline for credentials that function like non-human identities.

Q: Why do AI-assisted attacks increase application risk so quickly?

A: AI-assisted tooling reduces the effort required to find exposed endpoints, vary payloads, and test credentials at scale. That means the same weakness can be exploited faster and more repeatedly, even if the underlying vulnerability is familiar. Teams should assume that attack volume and speed will rise before their detection and response processes are fully adapted.

Q: How do security teams know if application hardening is keeping pace with attackers?

A: Measure the time from publication to hostile contact, the percentage of apps with embedded secrets, and the speed of revocation after exposure. If any of those metrics drift upward, attackers are gaining operational advantage faster than defenders are closing it.

Q: Who is accountable when an application credential is exposed and reused?

A: Accountability should sit with both the application owner and the team responsible for credential governance, because the failure spans software design and identity control. If the organisation cannot name an owner for each secret, it cannot reliably rotate, revoke, or offboard it. That gap becomes a governance issue, not just a security incident.

Technical breakdown

Why application attacks scale faster than perimeter controls

Modern application estates extend across cloud services, mobile builds, packaged desktop software, and third-party dependencies. That gives attackers more entry points than a firewall-centric model can realistically absorb. When development velocity rises, security teams often inherit faster release cycles, more exposed interfaces, and less time for hardening. The control problem is not just blocking traffic. It is maintaining secure defaults, tamper resistance, and telemetry across the full application lifecycle.

Practical implication: align application hardening and runtime monitoring to release velocity, not quarterly review cycles.

How AI-assisted malware changes the attack economics

AI-assisted malware lowers the skill and time required for reconnaissance, payload variation, and evasive behaviour. That does not create entirely new attack classes, but it does make existing ones cheaper, faster, and more scalable. For defenders, the main shift is that attack frequency can rise even when individual techniques stay familiar. Security teams should expect more rapid experimentation against app surfaces, especially where authentication, embedded secrets, or exposed APIs are poorly governed.

Practical implication: tune detection and response for volume and speed, not only for novel techniques.

Why secrets and app identities remain a hidden exposure layer

Applications depend on secrets, service accounts, API tokens, and certificates to authenticate to data stores, cloud services, and other apps. When these credentials are embedded in code, copied across environments, or left unrotated, attackers can move from application compromise to downstream access very quickly. This is where application security and identity governance intersect. The app may be the entry point, but the credential is the durable asset that preserves access.

Practical implication: treat application credentials as governed identities, not just development artefacts.

Threat narrative

Attacker objective: The attacker aims to turn application compromise into broader backend access, data theft, or service abuse by exploiting trusted application credentials.

1. Entry begins with attacker access to exposed application surfaces, vulnerable dependencies, or poorly protected application endpoints.
2. Escalation follows when AI-assisted tooling helps automate discovery of reusable secrets, tokens, or privileged application paths.
3. Impact occurs when those credentials are used to pivot into backend services, data stores, or connected systems with trusted application access.

NHI Mgmt Group analysis

Application attack frequency is becoming a governance problem, not only a tooling problem. When attacks rise as development accelerates, teams cannot rely on perimeter-era assumptions about where risk lives. The operational question becomes whether application identities, embedded secrets, and release pipelines are governed as part of the same control plane. That is where NHI governance intersects with app security: service credentials that live inside software behave like identities, not static code artefacts. Practitioner conclusion: treat application trust as an identity lifecycle issue.

AI-assisted attack tooling compresses the defender response window. The article points to a market where attackers can scale attempts faster and with less skill, which changes the economics of detection. Static reviews and periodic hardening do not map well to environments where payload variation, credential discovery, and endpoint selection can be automated. The implication is stronger runtime visibility and faster credential invalidation, especially around application-to-application trust. Practitioner conclusion: shift from periodic inspection to continuous control verification.

Credential persistence window: the real risk is not just exposure, but how long a leaked application credential remains valid after discovery. The more applications authenticate through copied secrets, shared tokens, or long-lived service accounts, the longer attackers can exploit trusted access after the initial compromise. This is a governance failure because ownership, rotation, and offboarding often sit outside the application security team’s line of sight. Practitioner conclusion: shorten the lifespan of application credentials and assign clear ownership for every secret.

Attack democratization widens the gap between mature and immature application programmes. As offensive techniques become easier to access, the baseline required for attackers falls while the baseline required for defence rises. That pushes application security towards standardised controls, measurable hardening, and better integration with identity and secrets management. NIST CSF, MITRE ATT&CK, and OWASP NHI are relevant here because the issue spans detection, credential abuse, and application trust. Practitioner conclusion: measure whether app hardening is operationalised or merely documented.

What this signals

Application security teams should expect hardening, secrets management, and identity governance to converge more tightly over the next programme cycle. The practical signal is clear: if application credentials are not treated as governed identities, runtime controls will continue to lag behind attacker automation. Credential persistence window: the time between discovery and revocation will become a board-level risk signal, not just an operational metric.

The 44% developer best-practice figure from The State of Secrets in AppSec shows that behaviour, not policy language, is the limiting factor in many environments. Teams should look for evidence that secrets ownership, rotation, and offboarding are built into delivery workflows rather than bolted on afterward.

The most resilient programmes will connect application security telemetry to identity and access governance. That means linking exposed secrets, service account activity, and backend privilege paths into a single risk view. For practitioners, the priority is to shrink the gap between application compromise and durable access.

For practitioners

• Map application secrets to named owners Inventory API keys, tokens, certificates, and service accounts used by applications, then assign each one an accountable owner and expiry or rotation policy. Without explicit ownership, leaked credentials remain active far longer than teams expect.
• Reduce credential persistence windows Replace long-lived application secrets with shorter-lived credentials where possible, and rotate or revoke any secret that is embedded in code, build pipelines, or deployment templates. Prioritise the highest-privilege application-to-backend paths first.
• Add runtime detection around app-to-app trust Monitor for abnormal token use, unusual service account activity, and unexpected backend access from application workloads. Focus on detection signals that indicate a compromised application has begun using trusted credentials outside its normal pattern.
• Align app security with identity governance Bring application credentials into the same governance workflow used for human and non-human identities, including joiner-mover-leaver logic for service access, exception handling, and periodic access review.
• Use attacker behaviour to prioritise hardening Base hardening plans on the application surfaces most likely to be targeted by automated attack tooling, especially exposed APIs, dependency chains, and systems with direct secrets exposure.

Key takeaways

• Application attacks are rising faster than perimeter-era security models can absorb, which makes application hardening a governance issue as much as a technical one.
• Developer behaviour gaps and slow secret remediation show that exposed credentials remain a durable path from app compromise to backend access.
• The practical answer is to govern application credentials as identities, shorten their usable lifetime, and tie hardening to runtime detection.

Key terms

• Application Secret: A credential used by an application to authenticate to another system or service. This includes API keys, tokens, certificates, and similar authenticators that often persist outside normal human login workflows and can create durable access if exposed or reused.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Credential Persistence: Credential persistence is the ability of an attacker to keep access after the original secret is revoked or the initial malware is removed. In identity terms, it usually means a second credential, key, or token has been added to the account lifecycle and now survives the first response action.
• Application Hardening: The process of reducing an application’s attack surface by tightening configuration, authentication, dependencies, runtime behaviour, and monitoring. In mature programmes, hardening is continuous and linked to identity and secrets governance, not a one-time release activity.

What's in the full report

Arxan Technologies' full report covers the operational detail this post intentionally leaves for the source:

• Attack frequency breakdowns across Android, iOS, web, and desktop application targets
• The report's breakdown of how AI-assisted malware is changing attacker economics
• Industry-specific risk patterns that help teams prioritise application hardening work
• Proactive strategies for securing applications beyond the corporate firewall

👉 Arxan Technologies' full report covers the attack-frequency detail, threat drivers, and response priorities behind this app security shift.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It gives practitioners a practical framework for aligning application trust with broader identity security responsibilities.