Who is accountable when a company ships vulnerable first-party code that attackers exploit before disclosure?

The organisation is accountable because it acted as both the software vendor and the deployer. There is no third party upstream to absorb the delay or issue the fix. If the defect sits in code the company wrote, only that engineering team can remove it, and only its own process determines whether the flaw is fixed before attackers find it.

Why This Matters for Security Teams

Accountability is not a legal abstraction when first-party code is involved. If a company writes the vulnerable code, it owns the defect, the exposure window, and the remediation path. That matters because attackers do not wait for disclosure processes to finish, and there is no upstream vendor to absorb responsibility. In practice, this is the same operational problem NHI teams face when secrets and credentials are embedded in software, then discovered by attackers before internal review catches them.

NHI research shows how often that gap turns into real compromise: 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 91.6% of secrets remain valid five days after notification. That combination creates a predictable blast radius. The issue is not only whether the code is vulnerable, but whether the organisation can prove ownership, detect abuse quickly, and revoke or patch before exploitation. See Ultimate Guide to NHIs — Key Challenges and Risks and CISA cyber threat advisories for how quickly routine weaknesses become active incidents. In practice, many security teams encounter accountability gaps only after exploitation has already begun, rather than through intentional pre-release risk review.

How It Works in Practice

For first-party code, accountability sits with the organisation because it is both the software publisher and the operator of the environment. That means secure coding, build controls, testing, release gating, and incident response all land on the same team. The practical question is not who wrote the line of code in a narrow sense, but who controlled the release decision and who can still remediate the defect once exposure is known.

That is why mature programs treat vulnerable code as a lifecycle issue. The response path usually includes:

• identifying the owning team and repository before release
• triaging the flaw against exploitability, not just severity
• patching the source, dependency, or configuration at the earliest safe point
• revoking any secrets, tokens, or keys the code may have exposed
• validating whether the same defect appears in forks, mirrored builds, or deployed artefacts

The same logic appears in NHI governance. If code contains a secret, the organisation must assume the secret is already part of the attack surface. NHIMG has repeatedly documented that exposed NHIs are commonly abused as soon as they become reachable; see LLMjacking: How Attackers Hijack AI Using Compromised NHIs and Ultimate Guide to NHIs — Why NHI Security Matters Now. External guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces this with controls for secure configuration, continuous monitoring, and timely corrective action.

These controls tend to break down when code ships through rapid CI/CD pipelines with weak ownership mapping, because teams cannot prove which release introduced the flaw or which secret was already live.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance release speed against evidence of control. That tradeoff becomes sharper when the defect is in a shared library, a generated artifact, or code deployed through multiple business units.

There is no universal standard for this yet, but current guidance suggests the organisation still remains accountable if it approved the release or operated the affected environment. Shared open-source components can complicate root-cause analysis, but they do not remove responsibility for safe integration, patching, or compensating controls. The same applies when an external contributor introduced the flaw but the company bundled it into a product or internal service.

Two edge cases matter most. First, if a downstream customer deploys the code without modification, contractual liability may be shared, but operational accountability for the vulnerable build often remains with the original publisher. Second, if the flaw is discovered through a disclosure program or bug bounty, the organisation is still accountable for whether it had the controls to detect and fix it before exploitation. For broader identity and exposure context, The 52 NHI Breaches Report is useful evidence that exposed identities and delayed remediation routinely turn into breach pathways. The real-world failure mode is simple: teams assume ownership is ambiguous until attackers force the issue.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Who is accountable if a vulnerable domain controller remains online after disclosure?
• Who should be accountable when attackers exploit chained weaknesses across software and identity?
• Who is accountable when third-party SaaS mishandles company data?