Who is accountable when application risk is not visible across the software lifecycle?

Accountability usually sits with both security and engineering leaders. Security teams define risk standards, visibility, and prioritisation rules, while engineering teams own code changes and fixes in the delivery pipeline. If application risk is not visible end to end, governance fails because no team can reliably prove what is exposed, what is being addressed, or what remains accepted.

Why This Matters for Security Teams

When application risk is not visible across the software lifecycle, accountability becomes fragmented and therefore weak. Security leaders are expected to define risk standards, while engineering leaders are expected to ship fixes, but neither group can govern what it cannot see. That gap shows up in missed vulnerable components, delayed remediation, and acceptance decisions made on partial evidence rather than current exposure. NIST’s Cybersecurity Framework 2.0 treats visibility and governance as prerequisites, not afterthoughts.

For NHI-adjacent application risk, the problem is usually not a lack of policy. It is the absence of lifecycle traceability for secrets, service accounts, tokens, and build artifacts that can expose the application long after code is merged. NHIMG’s Top 10 NHI Issues and NHI Lifecycle Management Guide both show that unmanaged identity sprawl and lifecycle drift are recurring causes of blind spots. In practice, many security teams encounter accountability failures only after a breach report forces a retrospective mapping of ownership, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability works best when it is assigned to the control point, not just the team name. Security typically owns the risk model, required evidence, and escalation thresholds. Engineering owns the implementation details in code, infrastructure, and deployment pipelines. Platform or DevSecOps teams often carry the operational mechanism that makes visibility repeatable. The practical question is who can prove, at any moment, what is exposed, what changed, and what remains accepted.

That proof usually depends on a joined-up view of source control, CI/CD, runtime telemetry, and identity data. A mature process ties application inventory to ownership, then links findings to a specific repository, service, or workload identity. For non-human identities, that means mapping secrets and tokens to the application that uses them, not just the person who created them. This is where the OWASP Non-Human Identity Top 10 is useful because it frames identity exposure as an application risk, not only an access management issue.

• Security defines the minimum evidence required for risk acceptance.
• Engineering fixes code, configuration, and dependency issues in the delivery pipeline.
• Platform teams automate scanning, tagging, and policy checks so findings are attributable.
• Risk decisions are recorded against a named service, owner, and expiration date.

That model is strengthened by lifecycle controls that detect secret sprawl, stale credentials, and orphaned workloads before they become invisible liabilities. NHIMG’s Guide to the Secret Sprawl Challenge is especially relevant here because duplicated and exposed secrets often break the chain of accountability between engineering intent and production reality. These controls tend to break down when service ownership is vague and multiple teams can change the same deployment path without a single authoritative inventory.

Common Variations and Edge Cases

Tighter visibility often increases process overhead, requiring organisations to balance faster delivery against stronger assurance. That tradeoff becomes sharper in multi-team estates, acquisitions, and microservice environments where one application may depend on dozens of identities, pipelines, and third-party components.

There is no universal standard for this yet, but current guidance suggests that accountability should shift with the risk domain. If the issue is dependency exposure, engineering owns remediation. If the issue is policy drift or inadequate detection, security owns the control design. If the issue is missing inventory, platform ownership may be the limiting factor. This is why standards like NIST SP 800-53 Rev 5 Security and Privacy Controls matter: they help separate governance responsibilities from implementation duties.

Two practical edge cases matter most. First, shared services can blur accountability unless each consumer application is explicitly mapped to its inherited risk. Second, ephemeral or auto-scaling workloads can disappear before traditional review cycles catch them, so control evidence must be collected continuously, not quarterly. Where that discipline is missing, teams often rely on manual attestations that do not survive rapid release cycles or identity churn.

NHIMG’s research on NHI Rotation Challenges and the Ultimate Guide to NHIs – Static vs Dynamic Secrets shows why static controls often fail once identities outlive the deployment that created them. In practice, accountability becomes visible only when lifecycle ownership, runtime telemetry, and risk acceptance records are all tied to the same application record.

Related resources from NHI Mgmt Group

• Why do organisations struggle to maintain accurate software inventory across the application lifecycle?
• Who is accountable for product security decisions when infrastructure, identity, and application risk overlap?
• Who is accountable for enforcing lifecycle controls across apps that lack native identity standards?
• Who is accountable for correlating identity events across cloud and application logs during a security incident?