Topic starter
25/06/2026 10:24 pm
TL;DR: The 2026 State of Application Security Report says 78% of organisations are running production applications with critical vulnerabilities, nearly 50% still have Log4Shell-exposed systems, and 43% have exposed AI/ML credentials, according to Orca Security. The real problem is not AI itself but the speed gap between code flow and governance controls, which now leaves hygiene measures struggling to keep up.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “2026 State of Application Security Report Recap: What the Data Says and What Security Teams Should Do About It”.
By the numbers:
- 78% of organisations are running production applications with critical vulnerabilities.
- Nearly 50% still have Log4Shell-exposed systems.
- 43% of organisations have exposed AI/ML credentials like API keys and tokens.
Key questions
Q: What should teams do first when AI-assisted delivery is outrunning code review?
A: Start by restoring non-negotiable approval gates on the path to production.
Q: Why do vulnerability findings often remain open for weeks after discovery?
A: Vulnerability findings linger when security and development operate as separate groups with different incentives and weak feedback loops.
Q: How should security teams handle exposed secrets in AI-driven environments?
A: Security teams should treat exposed secrets as active access paths and respond as though misuse can begin immediately.
Practitioner guidance
- Enforce code-review and branch-protection gates Require human approval before production promotion, including for AI-assisted changes and automated pull requests.
- Classify AI credentials as a distinct secret tier Separate model-hosting keys, inference tokens, and ML platform credentials from standard cloud secrets so detection, rotation, and revocation can be tuned to their specific blast radius.
- Map dependency blast radius before remediation Document which services, containers, and IaC modules depend on each vulnerable component before fixing it, so patching does not become a blind break-fix exercise.
Bottom line: The article shows that AppSec risk is being amplified by delivery velocity, not by AI alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:54 pm
Velocity, not AI, is the governing variable now: this article shows that the control problem is no longer whether organisations understand AppSec hygiene, but whether their delivery speed has outgrown the governance cadence that makes hygiene enforceable. Branch protection, code review, and CI/CD gating only work when they are actually present in the path to production. The practitioner conclusion is that speed has become a control design constraint, not merely an operational preference.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What happens when a malicious package lands in a trusted build path?
A: Its impact can spread far beyond the initial component. If the package is executed in CI/CD, a base image, or an IaC module, the attacker benefits from the organisation’s own replication machinery and can turn one compromise into repeated exposure across many deployments.
👉 Read our full editorial: AI appsec velocity is widening vulnerability and secrets risk