Notifications
Clear all
Topic starter
12/06/2026 9:50 pm
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.
NHIMG editorial — based on content published by Orca Security: Open Source Application Security Tools and How to Use Them
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map each tool to a distinct control layer Separate dependency scanning, secret detection, SAST, and runtime testing into different decision points in the SDLC.
- Tie secret findings to identity ownership When a secret is detected, assign an owner for revocation, rotation, and downstream access review.
- 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.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Tool-by-tool coverage boundaries for dependency scanning, secret scanning, SAST, DAST, and penetration testing.
- Specific integration patterns for CI/CD, including where each tool fits in pull requests, build stages, and staging validation.
- Operational examples of how runtime context changes which findings are actually exploitable in production.
- Orca Security's approach to correlating application findings with cloud exposure and attack paths.
👉 Read Orca Security's guide to open source application security tools →
AppSec tool coverage gaps: what IAM and security teams miss?
Explore further
13/06/2026 12:10 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Open source application security tools still miss production risk
