Notifications
Clear all
Topic starter
10/06/2026 11:36 pm
TL;DR: Application security often fails not because tools are absent, but because people and process are underbuilt: according to Orca Security, 85% of organisations have plaintext secrets embedded in source code repositories, showing that visibility alone does not prevent exposure. The real control is organisational, not just technical, and automation only helps after workflow and ownership are established.
NHIMG editorial — based on content published by Orca Security: building an effective application security program
By the numbers:
- 85% of organizations have plaintext secrets embedded in their source code repositories.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams implement application security without slowing developers down?
A: Put controls inside the normal delivery workflow.
Q: Why do plaintext secrets keep showing up in code repositories?
A: Because detection without ownership does not change behaviour.
Q: What do security teams get wrong about appsec metrics?
A: They often measure the number of vulnerabilities found instead of the speed and consistency of remediation.
Practitioner guidance
- Embed security champions in delivery teams Select volunteers who already influence code reviews and incident triage, then train them on secure coding, secrets handling, and your escalation path.
- Move security checks into pull requests and CI/CD Configure scans to run automatically on commits, pull requests, and build steps so findings appear where developers can act immediately.
- Trace runtime findings back to code origin Require source-to-runtime traceability for high-risk misconfigurations, secrets exposure, and dependency issues so teams can fix the commit or template that introduced the problem.
What's in the full article
Orca Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How the Security Champions program is structured across teams and how volunteers are selected
- Specific workflow integrations for GitHub, GitLab, Bitbucket, Jenkins, and related delivery tools
- The article's examples of code origin tracing from cloud findings back to the commit that introduced them
- The broader AppSec capability map covering SAST, SCA, IaC security, container scanning, and secrets detection
👉 Read Orca Security's analysis of how to build an effective AppSec program →
AppSec programs: why people and process still decide outcomes?
Explore further
12/06/2026 5:53 am
AppSec fails first as an operating-model problem, not a tooling problem. The article shows that advanced scanners do not matter if developers ignore them and security teams become a separate queue. That is the same failure pattern NHI programmes see when controls exist outside the delivery workflow. The implication is that governance has to be designed into execution paths, not layered on after the fact.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do organisations keep appsec policies from becoming shelfware?
A: Write policies that are specific enough to guide action and then embed them in operational procedures. If the policy does not connect to pull requests, dependency checks, exception handling, and review ownership, developers will work around it. Policies become usable when they are tied to the way teams already ship software.
👉 Read our full editorial: Application security programs fail when people and process come last
