TL;DR: Open source application security tools help find vulnerable dependencies, exposed secrets, and unsafe code earlier in the SDLC, but they still leave a gap between detection and production risk, according to Orca Security. Coverage boundaries matter because exploitability depends on runtime context, deployment exposure, and adjacent identity controls, not scanning alone.
At a glance
What this is: This is an analysis of open source AppSec tools and the article’s key finding that scanning code and secrets is not enough to judge production risk.
Why it matters: It matters because IAM, PAM, and security teams need production context to decide which application findings are actually exploitable and which are only theoretical.
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.
Context
Open source application security tools are designed to find issues in code, dependencies, secrets, and running applications before attackers can turn them into access paths. The governance gap is that these tools often stop at detection, while production risk depends on whether a finding is reachable, exposed, and connected to real identity and data paths.
In practice, that means a vulnerability scan or secret scan can be technically correct and still fail to answer the operational question that matters: can this issue be used in the environment where the application actually runs? For IAM teams, the missing piece is the link between application findings, deployment context, and adjacent access controls.
Orca Security uses this article to argue that coverage boundaries matter as much as detection quality. That is a typical problem in modern cloud environments, where code, pipelines, identities, and runtime exposure move faster than standalone scanners can keep up.
Key questions
Q: What breaks when AppSec tools only scan after commit?
A: Post-commit scanning misses the moment when a risky change can still be prevented. In fast pipelines, that means weak dependencies, leaked secrets, and unsafe IaC can already be on the path to release before analysts see the alert. Once the control point is too late, remediation becomes slower, noisier, and more expensive.
Q: Why do exposed secrets and vulnerable dependencies create access risk for security teams?
A: Because they turn code into a credential distribution channel. A hardcoded key, compromised package, or weak build pipeline can expose service accounts, tokens, and downstream systems long before traditional security review catches the issue. That makes vulnerability management, IAM, and NHI governance part of the same control problem.
Q: What are the signs that AppSec prioritisation is missing runtime context?
A: You will see low-value findings dominating remediation queues while internet-facing services and live credentials are delayed. Another signal is when teams cannot explain which identity, endpoint, or data path makes a vulnerability exploitable in the deployed environment.
Q: How should teams combine AppSec and identity controls to reduce production risk?
A: Use AppSec tools to find the issue, then use identity and deployment context to decide whether it matters. That means mapping findings to workload identity, access scope, and exposure so remediation focuses on the flaws that can be turned into access, not just the ones that look severe on paper.
Technical breakdown
Why code scanning misses production exploitability
Static analysis and software composition analysis are useful because they catch vulnerable code and libraries before release. But they do not tell you whether an issue is reachable from an internet-facing endpoint, protected behind authentication, or blocked by network segmentation. That distinction matters because exploitability depends on runtime placement, request paths, and what identity has to be abused to make the flaw matter. In other words, a finding is not yet a production risk until an attacker can actually reach it through the deployed architecture.
Practical implication: Treat code findings as candidates for triage, not proof of operational exposure.
Why secret scanning is only one layer of credential risk
Secret scanning looks for exposed API keys, tokens, private keys, and service account credentials in repositories and pipelines. That is a necessary control, but it does not cover every place secrets can leak, nor does it automatically tell you whether a detected credential is still active or what it can reach in production. A credential that is visible in code is already a governance issue; a credential that is both live and overprivileged becomes an access-path problem.
Practical implication: Pair secret detection with revocation, scope review, and workload context before you assume the risk is closed.
How runtime context changes application security prioritisation
Runtime context turns a long list of vulnerabilities into an attack path. If a SQL injection issue sits behind authentication, or a dependency flaw exists in a service with no inbound exposure, the remediation priority is different from a similar flaw in a public endpoint connected to sensitive data. This is where AppSec and identity governance meet: the value is not just in finding issues, but in knowing which identities, permissions, and exposure paths make those issues reachable.
Practical implication: Prioritise findings by exposure, identity scope, and data access instead of severity alone.
Threat narrative
Attacker objective: The attacker wants a code or secret finding to become a real production access path rather than a dead-end alert.
- Entry occurs when attackers exploit vulnerable software, exposed credentials, or insecure code that reaches production unnoticed.
- Escalation follows when a reachable flaw is combined with runtime exposure, adjacent privileges, or an active secret that can be abused.
- Impact is reached when the attacker uses that access path to gain initial access, move into sensitive systems, or extract data.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
- PyPI admin GitHub token leak 2024: A PyPI admin's GitHub token with admin rights over Python and PyPI repos sat in public Docker images for 15 months before JFrog found it.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Production risk is a context problem, not a scan problem. Open source AppSec tools can accurately identify vulnerable code, but exploitability is determined by runtime exposure, reachability, and the identities that can touch the affected component. That means the governance question is no longer whether a finding exists, but whether the finding can be turned into an access path. Practitioners should prioritise exposed, reachable, and identity-linked findings first.
Identity and AppSec now overlap at the prioritisation layer. A dependency flaw behind strong access controls is not the same risk as the same flaw on an internet-facing service with broad permissions. This is where access scope, workload identity, and deployment topology become part of application security triage. Teams that separate scanner output from IAM and cloud context will consistently overestimate low-reach findings and underestimate reachable ones.
Contextual risk scoring is the missing control plane for AppSec. The article points to a structural gap between finding vulnerabilities and deciding what matters in production. That gap is where production risk persists, because remediation queues are still built around severity labels that ignore exposure and privilege. Security programmes should treat context enrichment as part of governance, not as a reporting enhancement.
AppSec boundaries are now governance boundaries. Open source scanners stop at the codebase, but attackers do not. Once a flaw moves into a deployed service, the real question becomes which identities, endpoints, and data paths make it exploitable. Practitioners should align AppSec findings with cloud exposure and identity control ownership so that remediation lands with the team that can actually reduce blast radius.
Runtime awareness defines whether a tool reduces risk or just creates inventory. The article’s core lesson is that code, secrets, and dependency findings only become decision-grade when mapped to the live environment. That shifts the operating model from vulnerability counting to exploitability management. Security teams should measure whether their AppSec process can distinguish theoretical exposure from active production risk.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Runtime context is the difference between a finding and a risk. Open source scanners are useful, but they do not answer the governance question that matters most: which vulnerabilities are actually reachable in the live environment. Security teams should treat deployment exposure and identity scope as first-class triage inputs, not downstream metadata.
Code, secrets, and runtime controls now have to move together. A repository scan can find exposed credentials, but only identity governance tells you whether those credentials are still live and what they can touch. That makes secret hygiene, access scope, and workload placement part of the same control story.
Coverage boundaries create the new AppSec blind spot. The strongest programmes will not just increase scanning volume; they will enrich findings with runtime and cloud context before assigning ownership. That is the practical path to separating noise from exploitable production risk.
For practitioners
- Prioritise reachable findings first Rank AppSec issues by internet exposure, authentication boundary, and whether the affected service can be reached from an attacker-controlled path. Findings without reachability should not displace flaws that sit directly on public endpoints or exposed workloads.
- Join secret findings to revocation workflows When a scanner finds an exposed credential, require a linked revocation step and an owner check before the item is closed. Treat live secrets in repositories, pipelines, and build artifacts as active access paths, not as ordinary defects.
- Add workload context to AppSec triage Attach identity scope, network position, and data sensitivity to each vulnerability so teams can separate theoretical findings from exploitable ones in production. This is especially important when the same component appears in both internal and internet-facing deployments.
- Run SAST and SCA in pull requests Keep code and dependency scanning close to developer workflows so issues surface before merge, then reserve DAST and penetration validation for the runtime layer. That sequencing shortens remediation time without pretending that source scanning covers production behaviour.
Key takeaways
- Open source AppSec tools are valuable at detection, but they do not by themselves tell practitioners whether a finding can be exploited in production.
- The article ties this gap to real breach pressure, including a 31% share of confirmed breaches in which software vulnerability exploitation became the initial access vector.
- The control that changes the outcome is context enrichment: map findings to exposure, identity scope, and runtime reachability before deciding what to fix first.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article discusses exposed credentials in repositories and pipelines. |
| NHI-05 — Overprivileged NHI | Production risk rises when live credentials and workloads have broader access than they need. | |
| Recommendation — Scan repositories and pipelines for exposed NHI secrets and revoke any active credentials immediately. Reduce NHI blast radius by narrowing permissions on exposed or long-lived credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s central issue is whether exposed findings are actually reachable and authorised in production. |
| Recommendation — Map application findings to active permissions and entitlement scope before assigning remediation priority. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential exposure and active secrets are account management issues in the article’s threat model. |
| Recommendation — Track exposed secrets to owners and remove unused or stale accounts and credentials quickly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article repeatedly centers on exposed credentials and whether they remain valid. |
| Recommendation — Apply authenticator management to rotate, revoke, and monitor active secrets used by applications. | ||
Key terms
- Contextual Risk Scoring: A decision model that combines multiple signals, such as device integrity, app tamper evidence, location, and transaction value, to estimate the risk of a specific action. For mobile banking, it is more defensible than binary blocking because it evaluates the situation rather than only the device state.
- 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.
- Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
- Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org