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.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Building Application Security from the Ground Up: An Organizational Approach”.
By the numbers:
- 85% of organisations have plaintext secrets embedded in their source code repositories.
Key questions
A: Start with security by design, then define standards, workflows, testing, and review loops that fit how applications are built and released.
Q: Why do application security tools fail when organisations already have scanners and dashboards?
A: Tools fail when they are asked to solve accountability and workflow problems.
Q: What are the signs that an AppSec programme is not embedded in the workflow?
A: Findings sit in separate portals, developers keep asking the same questions, remediation tickets are created manually, and security teams become a queue rather than a partner.
Practitioner guidance
- Build a security champions network Start with a small set of trusted developers in different teams, give them practical AppSec training, and create a repeatable channel for questions, feedback, and triage.
- Embed security into developer workflows Push findings into pull requests, CI/CD pipelines, IDEs, and issue trackers so remediation happens where developers already work.
- Rewrite policies for implementability Replace vague guidance with concrete requirements for secure coding, authentication, authorization, dependency management, and exception handling.
Bottom line: Application security fails fastest when ownership, process, and developer context are left undefined, even if tooling coverage is broad.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 5:53 am
AppSec fails when ownership is absent before automation is introduced. The article’s core lesson is that technology cannot compensate for undefined accountability, unclear review paths, or teams that do not feel responsible for findings. Security findings without an owner become backlog artefacts rather than risk reduction. For practitioners, the real programme question is who is accountable for fixing what, and at what point in the workflow that accountability becomes real.
A question worth separating out:
Q: What is the difference between security champions and a central AppSec team?
A: A central AppSec team sets standards, interprets risk, and provides specialist support. Security champions distribute that capability into delivery teams so security decisions happen closer to the code. The two roles are complementary, but champions solve scale and context that central review alone cannot.
👉 Read our full editorial: Application security programs fail when people and process come last
This post was modified 1 day ago by NHI Mgmt Group