Open source application security tools still miss production risk

At a glance

What this is: This is an independent analysis of open source application security tools and the control boundaries that determine where they work and where they fail.

Why it matters: It matters because IAM, NHI, and application security teams need to understand how secrets, dependencies, and runtime exposure intersect before findings become exploitable risk.

By the numbers:

• The 2026 Verizon DBIR found that exploitation of software vulnerabilities became the leading initial access vector in confirmed breaches, accounting for 31% of incidents.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Orca Security's guide to open source application security tools

Context

Open source application security tools are designed to find vulnerable dependencies, insecure code, and exposed secrets before those weaknesses reach production. The primary problem is not lack of tooling, but lack of coverage across the software delivery chain, especially where code findings meet runtime exposure and identity-controlled access paths.

For IAM and NHI practitioners, this is also an identity problem. Secrets, service account credentials, and pipeline tokens can turn a code issue into an access issue, which means application security findings need to be interpreted alongside workload identity, privilege scope, and secret lifecycle controls.

Key questions

Q: How should security teams prioritise open source AppSec findings in production environments?

A: Prioritisation should start with reachability, exposure, and identity impact rather than raw scan volume. Findings that are internet-facing, authenticated by privileged credentials, or connected to sensitive data should rise first. Static severity alone is not enough because many code issues never become exploitable in the deployed environment.

Q: Why do application security tools need to be paired with IAM and NHI controls?

A: Because exposed secrets, service account tokens, and pipeline credentials turn application findings into access problems. IAM and NHI controls provide the ownership, privilege scope, and revocation path that AppSec tools do not cover. Without those controls, a code finding can persist as an active identity compromise.

Q: What do teams get wrong about secret scanning in CI/CD pipelines?

A: They often treat secret scanning as a detection task instead of a lifecycle control. The real issue is not just finding a token, but knowing who owns it, whether it is live, what it can access, and how quickly it can be revoked or rotated before abuse spreads.

Q: How do you know if runtime testing is actually improving application security?

A: Runtime testing is working when it changes remediation priorities. If DAST and penetration testing consistently confirm which findings are reachable, authenticated, or chained to sensitive systems, teams can stop treating all static alerts equally and focus effort on the paths that matter most.

Technical breakdown

Software composition analysis only sees known dependency risk

Software composition analysis, or SCA, compares package manifests and lock files against vulnerability databases to identify known issues in third-party components. It is effective for cataloguing exposure in dependencies, but it does not test whether a vulnerable component is reachable, whether the affected code path is used, or whether compensating controls reduce impact. That distinction matters because a library with a CVE is not always exploitable in the deployed application. SCA is therefore a discovery layer, not a full risk verdict.

Practical implication: treat SCA findings as input to prioritisation, then confirm reachability and exposure before assigning remediation urgency.

Secret scanning finds credential exposure, not entitlement context

Secret scanning looks for API keys, tokens, certificates, and other credentials in repositories and pipelines. Some tools verify whether a found secret is still live, which improves signal quality, but even verified exposure does not explain the credential's privilege, downstream access scope, or whether the secret was already used elsewhere. That is why secrets scanning must be paired with identity governance. A leaked token can be a low-value nuisance or a high-impact entry point depending on what it can reach.

Practical implication: pair secret detection with ownership, rotation, and access-scope review so exposed credentials are not handled as generic code hygiene issues.

Runtime-aware testing closes the gap between code and exploitability

DAST and penetration testing work against running applications, which lets teams observe behaviour that static tools cannot infer from source code alone. They can reveal authenticated paths, injection exposure, and misconfigurations that only appear under live traffic or real session state. This is the bridge between theoretical vulnerability and production exploitability. Without runtime awareness, teams often over-prioritise low-impact findings in code while missing the application paths that matter most in attack chains.

Practical implication: use runtime testing to validate which findings are actually reachable before release, especially for internet-facing systems and authenticated workflows.

Threat narrative

Attacker objective: The attacker’s objective is to convert a software weakness into exploitable application access, then use that access to reach data or connected systems.

1. Entry begins with an exposed secret, vulnerable dependency, or insecure code path that gives the attacker a foothold in the application delivery chain.
2. Escalation follows when that foothold is combined with runtime exposure or overprivileged access, allowing the attacker to move from a code-level issue to usable application access.
3. Impact occurs when the attacker reaches sensitive data, authenticated workflows, or downstream services through the application and its connected identity paths.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Coverage boundaries are the real control plane in application security. AppSec tools do not fail because they are absent from the stack. They fail when teams assume any one tool can see dependency risk, secret exposure, and runtime exploitability at the same time. The discipline here is less about tool count and more about knowing which layer each control actually observes. Practitioners should organise coverage by attack surface, not by vendor category.

Secret exposure is an identity event before it is a code event. Once an API key, token, or certificate appears in source control or CI, the problem crosses from application security into NHI governance. That is where lifecycle, ownership, and revocation discipline become decisive. The practical implication is that secrets scanning only becomes operationally useful when it is paired with access scope, rotation, and offboarding controls.

Runtime awareness turns AppSec from enumeration into prioritisation. Static findings describe possible weakness, but runtime context tells you whether that weakness is reachable, authenticated, internet-facing, or chained to higher-value assets. That makes the real governance question one of blast radius, not just detection volume. Practitioners should demand context before they decide what gets fixed first.

Identity and application security now share the same failure boundary. The most important AppSec failures are no longer isolated code defects. They are the points where exposed secrets, overprivileged service accounts, and deployed workloads connect. That means IAM, NHI, and AppSec teams need a common prioritisation model instead of separate queues. Practitioners should evaluate application findings through identity impact, not just vulnerability severity.

Identity blast radius: what matters is not whether a finding exists, but how far a compromised credential or vulnerable component can reach. This is the most useful named concept in modern AppSec governance because it joins code risk to access risk. A low-severity secret leak can exceed the impact of a high-severity CVE if it opens privileged cloud or pipeline access. Practitioners should rank issues by reachable identity blast radius, not just CVSS.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For the broader identity control picture, review Top 10 NHI Issues for how secret exposure and privilege scope combine into operational risk.

What this signals

Secret sprawl remains a governance problem, not just a detection problem: when remediation averages 27 days, the gap between discovery and revocation becomes the real risk window. That window is where NHI ownership, rotation, and access-scope decisions either contain impact or allow credential reuse to spread across environments.

AppSec programmes that do not link findings to identity controls will keep overvaluing alerts and undervaluing blast radius. The practical shift is to treat secrets, service accounts, and pipeline tokens as governed identities, then review them with the same discipline used for privileged human access.

The category is moving toward joined-up risk models in which code, credentials, and runtime exposure are assessed together. Teams that only separate SCA from SAST from DAST will continue to miss the most important question: how far can a compromised artefact actually reach?

For practitioners

• Map each tool to a distinct control layer Separate dependency scanning, secret detection, SAST, and runtime testing into different decision points in the SDLC. Require each team to document what the tool can see, what it cannot see, and what risk remains outside its boundary.
• Tie secret findings to identity ownership When a secret is detected, assign an owner for revocation, rotation, and downstream access review. Treat verified live secrets as identity incidents, not just code defects, because their impact depends on the privileges behind them.
• Use runtime validation before prioritising remediation Confirm whether a finding is reachable in the deployed environment, whether it sits behind authentication, and whether it connects to sensitive data or privileged services. This avoids wasting remediation cycles on low-impact theoretical exposure.
• Correlate AppSec and IAM queues for shared risk Review vulnerabilities alongside service accounts, pipeline tokens, and workload identity boundaries so the same attack path is not assessed in separate silos. Shared triage helps teams see when a code weakness becomes an identity compromise.

Key takeaways

• Open source AppSec tools are necessary, but they only become effective when teams understand the control boundary of each layer.
• Exposed secrets sit at the intersection of application security and identity governance, which makes ownership and revocation the decisive controls.
• Runtime context changes prioritisation because exploitable risk depends on reachability, privilege, and connected systems, not scan results alone.

Key terms

• Software Composition Analysis: Software Composition Analysis is the practice of inventorying third-party components in an application and checking them for known vulnerabilities or license risks. It helps teams see dependency exposure, but it does not determine whether a vulnerable component is reachable in the deployed environment.
• Secret Scanning: Secret scanning is the automated detection of credentials such as API keys, tokens, certificates, and private keys in source repositories and delivery pipelines. In practice, it is an identity control as much as a code control because the value of a secret depends on what it can access.
• Runtime Awareness: Runtime awareness is the ability to evaluate an application in its live environment rather than only from source code or manifests. It helps security teams distinguish theoretical defects from issues that are actually reachable, authenticated, or connected to sensitive systems.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream infrastructure that can be reached if a credential, token, or workload identity is abused. It is a practical way to prioritise risk because not all exposed identities create the same level of impact.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: Open Source Application Security Tools and How to Use Them. Read the original.