Application security programs fail when people and process come last

At a glance

What this is: This is an analysis of why application security programs stall when tools are deployed before people, process, and workflow integration are in place.

Why it matters: It matters because IAM and security teams increasingly manage app teams, secrets, and pipeline access through the same governance model, and weak operational design leaves human, NHI, and automated controls ineffective.

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.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Orca Security's analysis of how to build an effective AppSec program

Context

Application security is not just a tooling problem. It is a governance problem that spans developers, security champions, workflows, and the controls that keep secrets and code changes from turning into persistent exposure.

The article argues that appsec works best when people come first, process comes second, and technology amplifies both. That sequence matters for identity security too, because the same operating model shapes how teams govern human access, service accounts, and automation in delivery pipelines.

Key questions

Q: How should security teams implement application security without slowing developers down?

A: Put controls inside the normal delivery workflow. Run scans in pull requests and CI/CD, route findings into the tools developers already use, and give security champions enough context to explain issues quickly. When teams can fix problems where they work, security stops being a separate approval step and becomes part of engineering execution.

Q: Why do plaintext secrets keep showing up in code repositories?

A: Because detection without ownership does not change behaviour. Teams often find secrets after they have already been committed, but the real issue is weak secret governance across development, code review, and pipeline practices. When secrets live in code, config files, or CI tools, they become persistent access material rather than temporary mistakes.

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. High finding counts can reflect better detection, not better security. The more useful signals are time to remediate, closure rates, and whether teams are fixing issues in the workflow that produced them.

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.

Technical breakdown

Security champions as control translators

Security champions are embedded developers who translate security requirements into the language of their own teams. They reduce queue-based bottlenecks by answering questions in context, reviewing code earlier, and making findings easier to act on. In practice, they function as distributed governance nodes, not replacement security staff. The model works because trust and proximity lower friction, while central security teams keep policy and standards consistent across teams.

Practical implication: formalise champions in each delivery team so security guidance reaches developers before issues harden into repeated pipeline defects.

Workflow-integrated policy and shift-left enforcement

A useful appsec policy is specific enough to drive action but flexible enough to fit different teams. The article’s process model places controls inside the workflow: scans in pull requests, findings in issue trackers, and remediation tied to the build cycle. That is the essence of shift-left. The technical value comes from reducing handoffs, which lowers the chance that findings are ignored, delayed, or separated from the code change that created them.

Practical implication: move security checks into the tools developers already use so remediation happens in the same workflow as the change.

Cloud-to-dev tracing and secrets detection

The article describes a control pattern that connects runtime cloud findings back to the code commit that introduced them. That traceability matters because it converts a production symptom into an origin point, which is far easier to fix and govern. Secrets detection, dependency scanning, IaC analysis, and container scanning all serve the same purpose when they are linked to developer context: they identify where a control failure entered the system, not just where it was discovered.

Practical implication: require origin tracing for high-risk findings so teams can remediate at source instead of repeatedly patching symptoms in production.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

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.

Security champions are the organisational equivalent of distributed identity control points. They create local accountability, translate policy into practice, and reduce the gap between central standards and team-level reality. In identity programmes, the same pattern shows why role-aware governance scales better than a single central review function. Practitioners should treat champions as a mechanism for control adoption, not as a communication program.

Workflow-native enforcement: security controls only work when they appear where work already happens. Pull-request comments, CI feedback, and issue-tracked remediation create a control surface that developers can actually use. Without that embedding, even accurate findings become background noise. The practitioner takeaway is clear: if a control requires a separate habit, adoption will lag behind risk.

Secrets exposure is the named failure mode that connects appsec to NHI governance. The article’s 85% plaintext-secrets figure is not just a code hygiene issue, it is a standing-credential problem that turns source control into an access store. That is why application security and NHI governance converge at the same weak point. Practitioners should treat secret handling as lifecycle governance, not only as developer hygiene.

From our research:

• 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.
• Follow the lifecycle guidance in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs to connect detection, rotation, and offboarding.

What this signals

Secrets handling is where appsec and NHI governance now overlap most visibly. With 96% of organisations storing secrets outside dedicated managers, the operational problem is no longer isolated to code quality. The governance gap is lifecycle control, because credentials in repositories, config files, and pipelines behave like durable access rather than disposable artefacts.

Security champions will matter more as delivery teams absorb more control responsibility. The model reduces friction, but only if organisations give champions enough authority to translate policy into action. That same pattern is emerging in NHI programmes, where local ownership beats central queueing when access decisions need to happen at the speed of development.

The programme signal is clear: appsec teams should align policy, workflow, and telemetry before they expand tooling. For identity teams, that means treating pipeline access, secrets, and deployment permissions as part of the same governance surface, not separate operational domains.

For practitioners

• 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. Give them a direct channel to security engineers so findings move in context rather than through a generic queue.
• 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. Pair each finding with clear remediation guidance and track closure in the same workflow that created the issue.
• 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. That prevents repeated patching of the same control failure in production.
• Measure remediation speed, not finding volume Track time to fix, time to detect, and the percentage of findings closed within agreed service levels. Avoid scorekeeping that rewards more alerts, because that encourages noise rather than reduction in exposure.

Key takeaways

• Application security breaks down when organisations treat tooling as the starting point instead of the outcome of a working operating model.
• Secrets exposure remains a recurring control failure, and it is also a lifecycle governance problem because exposed credentials behave like persistent access.
• Teams that embed controls into developer workflows, measure remediation, and assign local security ownership are better positioned to reduce exposure at source.

Key terms

• Security Champion: A security champion is a team member inside a delivery group who helps translate security requirements into day-to-day engineering practice. The role reduces bottlenecks by giving teams a trusted local guide, while central security keeps policy, standards, and escalation paths consistent.
• Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
• Cloud-to-Dev tracing: Cloud-to-Dev tracing is the practice of linking a runtime security finding back to the code commit, template, or configuration that introduced it. It helps teams fix the origin of a problem instead of repeatedly patching the production symptom.
• Secrets detection: Secrets detection is the identification of credentials such as API keys, tokens, certificates, and passwords in code, configuration files, or pipelines. In mature programmes, detection is paired with rotation, revocation, and ownership so exposed secrets do not remain usable.

Deepen your knowledge

Application security program design and secrets governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building control ownership across pipelines and code repositories, it is worth exploring.

This post draws on content published by Orca Security: building an effective application security program. Read the original.