Application security tools still fail where identity and secrets do

At a glance

What this is: This is a StackHawk overview of application security tools, with the key finding that effective AppSec still depends on continuous testing, secrets detection, and integration across the SDLC.

Why it matters: It matters to IAM and NHI practitioners because application security failures often start with exposed credentials, insecure access controls, and weak lifecycle governance rather than code flaws alone.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

👉 Read StackHawk's guide to the best application security tools

Context

Application security is the control layer that finds and blocks flaws before they become exploitable paths into software, APIs, and cloud-native services. The problem is that most programmes still treat scanning as the endpoint, when the harder governance issue is what happens after a hardcoded secret, broken authentication path, or unsafe configuration is discovered. That is where application security meets IAM, PAM, and NHI governance, because exposed credentials and over-privileged service access are identity problems as much as code problems.

StackHawk’s article is a useful reminder that the appsec market is crowded with tools that solve different slices of the problem. DAST, SAST, SCA, secrets detection, and WAFs all reduce risk in different ways, but none of them replaces lifecycle controls for credentials, access, and developer workflow discipline. For teams running cloud applications, APIs, and CI/CD pipelines, the operational question is not whether to scan, but how to connect findings to access control and remediation ownership.

Key questions

Q: How should security teams handle secrets found in application code?

A: Treat every secret in code as a governance issue, not just a coding mistake. Security teams should identify whether the secret is still valid, what systems it can reach, and whether it has been used elsewhere. Then rotate or revoke it, remove it from source control, and add build-time scanning so the same exposure does not recur.

Q: Why do hardcoded API keys create more risk than ordinary code flaws?

A: Because a hardcoded key can become reusable access outside the application boundary. A vulnerability may expose a function, but a secret exposes identity and privilege. Once the key is copied, the attacker does not need to keep exploiting the code path. The risk is persistence, lateral use, and incomplete revocation across systems.

Q: What do security teams get wrong about secret management?

A: Teams often treat secret storage as if it were the same as access governance. Storage protects the credential at rest, but it does not answer whether the requester was trusted, whether the release was justified, or whether the downstream privilege was still appropriate. Those are separate controls and should be reviewed separately.

Q: How can organisations measure whether AppSec controls are working?

A: They should look for fewer repeat vulnerabilities, lower false-positive burden, faster developer adoption, and measurable reduction in high-risk bug classes. A healthy AppSec programme changes the shape of risk, not just the number of alerts. If findings remain high but exposure does not fall, the control model is not scaling.

Technical breakdown

Why appsec tools split across code, runtime, and dependency layers

Application security tooling works because different flaw classes appear at different stages of the SDLC. SAST looks for insecure patterns in source code, DAST exercises live applications to find runtime issues, and SCA checks third-party components for known weaknesses. Secrets detection is a separate category because credentials can bypass application logic entirely once exposed. The architectural lesson is that no single control sees the whole attack surface, especially in modern web apps and APIs where code, configuration, and identity data are tightly coupled.

Practical implication: map each control to the failure mode it can actually detect, then route findings into the right remediation owner.

Why secrets detection is an identity control, not just a code scan

Hardcoded API keys, tokens, and passwords are not just code hygiene issues. They are portable identity artifacts that can be reused outside the application boundary if they are committed to repositories, copied into tickets, or left in build logs. Once a secret is exposed, the real risk becomes standing access and unclear ownership across environments. That is why secrets detection belongs in the same governance conversation as NHI lifecycle management, rotation, and offboarding. The detection layer finds the problem, but identity controls determine whether it can be reused.

Practical implication: treat every discovered secret as an access object with an owner, expiry, and revocation path.

How CI/CD integration changes the control model for developers

When appsec tools are embedded in CI/CD, security moves closer to the point where code is created and merged. That reduces latency between introducing a flaw and finding it, but it also changes the governance burden. Teams need policy thresholds, exception handling, and evidence that findings were actually remediated rather than ignored. This is the difference between signal and control. In practice, the best-integrated tool is the one that produces actionable feedback without creating unreviewed bypass channels in the delivery pipeline.

Practical implication: enforce policy gates and exception review so pipeline integration does not become a bypass route.

Threat narrative

Attacker objective: The attacker’s objective is to convert exposed application secrets into durable access that can be used for data theft, service abuse, or privilege escalation.

1. Entry begins when a hardcoded API key, token, or password is committed into source control or exposed in a build artifact.
2. Escalation follows when the exposed secret is reused for application, cloud, or API access beyond the original developer context.
3. Impact occurs when the attacker uses the credential to reach sensitive data, privileged functions, or production systems.

NHI Mgmt Group analysis

AppSec is increasingly an identity problem disguised as a code problem. The article correctly frames application security as a set of controls across code, runtime, and dependencies, but the most operationally dangerous failures often come from exposed secrets and insecure access paths. That is where IAM, PAM, and NHI governance intersect with AppSec, because the compromise path is usually a credential or token, not the vulnerability scanner itself. Practitioners should therefore treat secrets detection as part of identity governance, not as a separate developer convenience layer.

Secrets sprawl is the named concept this category keeps reproducing. Hardcoded credentials, duplicated tokens, and fragmented secret stores create a control environment where visibility is partial and revocation is slow. The problem is not only that secrets exist, but that they are copied into many places and managed inconsistently across teams and tools. That is why identity lifecycle discipline, rotation, and offboarding must be connected to application security telemetry. Practitioners should assume the exposure path is broader than source control alone.

Detection without accountable remediation creates security theatre. Appsec tooling can surface XSS, SQL injection, and secrets exposure, but the article also hints at the real decision point: whether the organisation can act on those findings quickly and consistently. In practice, that means linking AppSec output to identity owners, build owners, and platform owners who can revoke access and verify closure. Without that ownership model, remediation latency becomes a governance failure rather than a tooling gap. Practitioners should measure closure speed, not scan volume.

Open source and commercial tool choices matter less than control coverage and evidence quality. The article presents a useful taxonomy, but tool form factor does not solve access governance, developer behaviour gaps, or delayed secret remediation. The programme question is whether the stack covers code, runtime, dependencies, and exposed credentials with enough fidelity to support decision-making. That is the standard practitioners should apply when rationalising an AppSec programme. The right outcome is defensible control coverage, not category completeness.

What this signals

Secrets remediation speed is becoming a governance signal, not a hygiene metric. When exposed credentials sit for weeks, the control failure is not only in detection but in the ownership chain that should revoke, rotate, and verify closure. That is why appsec programmes increasingly need linkage to IAM and NHI lifecycle processes, especially where exposed tokens can be reused across systems.

Secrets sprawl is now a measurable exposure pattern. Duplicated credentials, build artefacts, and developer workflow copies turn a single issue into a multi-system revocation problem. Practitioners should expect their appsec programme to answer not just what was found, but where the secret was copied, who owns it, and how quickly the live access path was removed.

AppSec teams should align more closely with identity governance than with vulnerability counting. The real operational question is whether a finding can be translated into removed access before it is reused. That makes lifecycle control, auditability, and evidence of closure the right next steps for programme owners.

For practitioners

• Bind secrets findings to identity revocation workflows Route every exposed API key, token, or password into an ownership workflow that includes revocation, rotation, and confirmation of downstream access removal. Use secrets detection as an input to IAM and NHI lifecycle processes, not as a standalone alert queue.
• Define remediation SLAs for exposed credentials Set a target response window for leaked secrets that is shorter than the average credential reuse window in your environment. Track time to revoke, time to rotate, and time to verify that the old credential no longer authenticates anywhere.
• Separate detection types by control owner Assign SAST, DAST, SCA, WAF, and secrets alerts to different remediation owners so findings do not disappear into a generic backlog. AppSec teams need a clear path from detection to fix, especially when a finding affects production access or developer tooling.
• Enforce pipeline gates for high-risk findings Block merges or deployments when secrets exposure, broken authentication, or critical access-control issues are detected, and require documented exceptions for any bypass. The goal is to prevent known issues from crossing the SDLC boundary untouched.

Key takeaways

• Application security tooling reduces exposure, but it does not replace identity governance for credentials, tokens, and access paths.
• Leaked secrets remain a slow-moving risk in practice, which makes remediation speed and ownership more important than scan coverage alone.
• The strongest AppSec programmes connect findings to revocation, rotation, and verified closure across the SDLC.

Key terms

• Secrets detection: Secrets detection is the identification of credentials such as API keys, tokens, certificates, and passwords in code, configuration files, or pipelines. In mature programmes, detection is paired with rotation, revocation, and ownership so exposed secrets do not remain usable.
• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

StackHawk's full article covers the operational detail this post intentionally leaves for the source:

• A category-by-category breakdown of DAST, SAST, IAST, SCA, secrets detection, and WAF use cases
• Vendor-specific feature comparisons for teams choosing between open source and commercial application security tools
• Implementation considerations for integrating appsec tooling into CI/CD pipelines and developer workflows
• Practical selection criteria across stack, team structure, and regulatory needs

👉 StackHawk's full article covers the tool categories, feature trade-offs, and selection criteria in more depth.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational realities of modern security programmes.