Who is accountable for fixing vulnerabilities found in application scans?

Accountability should sit with the application owner, supported by security, engineering, and platform teams. Security can identify and prioritise issues, but developers and service owners must remediate them in the codebase and deployment path. Clear ownership matters most when findings move through ticketing systems, because unresolved vulnerabilities otherwise linger across releases and create repeat exposure.

Why This Matters for Security Teams

Application scan findings are not security team “to-dos” by default. They are evidence that needs to be routed to the people who can change code, infrastructure, or deployment controls. If accountability is vague, findings get triaged, ticketed, and re-opened without remediation. That is especially costly for non-human identities, where mismanaged secrets and service accounts can persist far longer than expected. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 91.6% of secrets remain valid five days after notification, which illustrates how slow remediation can become when ownership is unclear.

This is why application scan governance should align with existing control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where continuous monitoring and corrective action are part of the operating model. Security teams can detect, validate, and prioritise, but they usually cannot safely accept ownership for code-level fixes unless they also own the application. In practice, many security teams encounter unresolved scan findings only after a release has already shipped and the same weakness has been reintroduced.

How It Works in Practice

The cleanest operating model assigns accountability by asset ownership. The application owner, product team, or service owner is responsible for remediation. Security owns the scan program, exception handling, and risk acceptance process. Platform and DevOps teams own shared controls such as base images, CI/CD templates, secret scanning, and deployment guardrails. That division avoids the common failure mode where security becomes the ticket queue without having authority to change the underlying system.

Good scan workflows include four steps: confirm the finding is real, classify its business and technical impact, assign it to the correct owner, and track closure with evidence. For vulnerabilities in code, the developer or engineering team must patch the source and verify the fix in a subsequent build. For issues in cloud or pipeline configuration, the platform owner usually remediates. For credentials exposed in repositories or build logs, the service owner must revoke and replace the secret immediately, then validate downstream integrations. The NHI Mgmt Group’s Ultimate Guide to NHIs also shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why secret-related findings need rapid owner response.

In control terms, this maps well to NIST SP 800-53 Rev 5 Security and Privacy Controls expectations around remediation and continuous monitoring: the control owner must be able to act, not just observe. A practical RACI should name the application owner as accountable, engineering as responsible for fix implementation, and security as consulted on prioritisation and closure criteria. These controls tend to break down when scans are run centrally but ownership is decentralised across legacy teams and outsourced delivery chains because ticket routing and code access do not match the real system boundaries.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance fast remediation against the need to avoid ticket churn and duplicate ownership. That tradeoff becomes visible in shared services, inherited code, and platform-managed vulnerabilities. Current guidance suggests there is no universal standard for this yet, but ownership should follow the team that can make the fix and prove it is effective.

One edge case is third-party or vendor-managed applications. If the internal team cannot patch the issue directly, accountability shifts to vendor management and the internal service owner still remains accountable for tracking risk, compensating controls, and escalation. Another edge case is accepted risk: security may document a temporary exception, but the application owner should still own the decision to defer or retire the finding. For recurring issues like hardcoded secrets, process fixes matter as much as patching. NHI Mgmt Group’s Ultimate Guide to NHIs highlights that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, so remediation often requires both a code fix and a pipeline control change.

Where teams already use NIST SP 800-53 Rev 5 Security and Privacy Controls as their baseline, the best outcome is to attach each scan finding to an accountable application or service owner, then enforce closure SLAs by severity. That keeps security in the oversight role without turning it into the system maintainer.

Related resources from NHI Mgmt Group

• Who is accountable for providing exploitability evidence to customers and regulators when a product ships software vulnerabilities?
• Who should be accountable for securing application secrets across development and cloud operations?
• Why do application testing tools matter for NHI governance?
• Who is accountable for fixing open redirect risk across application teams and authentication owners?