Who should be accountable for making application security usable for developers?

Accountability should sit with both security and engineering leadership, because usable application security depends on process, tooling, and workflow design. Security teams define risk policy and prioritisation, while engineering leaders ensure the controls fit delivery practices. If the workflow is too cumbersome, adoption drops and the organisation loses both speed and assurance.

Why This Matters for Security Teams

Making application security usable is not a tooling problem alone. It is an accountability problem, because developers will route around controls that slow delivery, break workflows, or create unclear exceptions. Security leadership must own risk policy and guardrails, while engineering leadership must own how those guardrails fit the delivery pipeline. That split matters most when teams are trying to prevent leaks, misconfigurations, and privilege sprawl across code, pipelines, and secrets.

This is especially visible in incidents where small friction points become systemic failures. NHIMG research on The State of Secrets in AppSec shows only 44% of developers are reported to follow security best practices for secrets management, which is a workflow adoption problem as much as a policy problem. NIST guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that controls only work when they are operationally implemented, not merely documented. In practice, many security teams encounter noncompliance only after a leaked secret, broken build, or delayed release has already happened, rather than through intentional feedback loops.

How It Works in Practice

Usable application security works best when accountability is shared but explicit. Security sets the rules for what must be protected, how exceptions are approved, and what risks cannot be accepted. Engineering leaders then translate those requirements into developer-friendly workflows, such as pre-commit checks, CI/CD gates, dependency scanning, secret detection, and ticketing that is tied to sprint planning rather than ad hoc remediation.

In practical terms, this means security owns the policy and the thresholds, while engineering owns adoption and fit. The best implementations use guardrails that are close to the developer workflow, so controls appear where work already happens instead of forcing people into separate systems. That includes:

• Embedding checks in source control and build pipelines instead of waiting for manual review.
• Using clear severity and exception paths so developers know what blocks release and what can be temporarily waived.
• Automating evidence collection so developers are not asked to document the same control repeatedly.
• Measuring friction, such as false positives, cycle time, and override rates, alongside security outcomes.

NHIMG research on the State of Non-Human Identity Security shows how weak operational fit turns into real exposure, with lack of credential rotation cited as the top cause of NHI-related attacks by 45% of organisations. That pattern is a useful proxy for appsec too: if a control is hard to use, teams delay it, dilute it, or skip it. Current guidance from NIST and security standards bodies suggests controls should be measurable and repeatable, but there is no universal standard for exactly how much developer friction is acceptable. These controls tend to break down in fast-moving CI/CD environments with many repositories and frequent releases because manual review cannot keep pace with delivery volume.

Common Variations and Edge Cases

Tighter security controls often increase delivery friction, requiring organisations to balance stronger assurance against developer throughput and cognitive load. That tradeoff becomes sharper in startups, platform engineering teams, and large enterprises with many autonomous squads, where one size of workflow rarely fits all.

Some organisations try to put accountability entirely on security, but that usually leads to unusable controls that developers quietly ignore. Others leave it entirely to engineering, which often produces inconsistent policy enforcement and risk drift. The more sustainable model is joint accountability with a clear owner for each layer: security for risk decisions, engineering for workflow integration, and platform teams for shared tooling.

Edge cases matter. Highly regulated environments may require more formal approval steps, but even there the workflow should be as automated as possible. Conversely, teams shipping internal tools may accept lighter controls, but only if they still maintain visibility into secrets, dependencies, and exceptions. For implementation detail, the Google Firebase misconfiguration breach is a useful reminder that usability failures often show up as configuration mistakes, not just code defects. Best practice is evolving, but the core principle is stable: if developers cannot use the control quickly and correctly, it is not accountable security, it is aspirational policy.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Who should be accountable for user access decisions when security, GRC, and auditors need the same evidence?
• Who is accountable when inappropriate data access is detected in an identity security program?
• How should security teams handle stale user and application records in SaaS governance programs?