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

Why Accountability Stays with the Company That Wrote the Code

When first-party code is shipped in a vulnerable state, accountability remains with the organisation that authored, approved, and released it. That is true even if attackers exploit the flaw before disclosure, because the company controlled the development lifecycle, the release decision, and the remediation path. A disclosure race may affect timing, but it does not transfer responsibility for the defect itself.

This matters because first-party software creates a direct duty of care to customers and users: the company is both the source of the vulnerability and the only party able to fix it without waiting on an upstream vendor. In security terms, the failure is not just the bug, but the process that allowed an exploitable weakness to ship and remain exposed. Public guidance on exploit development and disclosure, such as CISA cyber threat advisories, is useful context, but the accountability question starts with ownership of the code and the release decision. In practice, many security teams discover the accountability gap only after customers are already affected and the incident timeline has become the only place the organisation can still defend its process.

How Liability and Fix Ownership Work in Practice

Accountability usually follows control. If a company writes the code, integrates it, signs off on it, and distributes it under its own name, then it owns the defect lifecycle from introduction to remediation. That includes secure design review, testing, release gating, patch creation, communication, and post-release validation. The fact that an attacker found the weakness first does not change the origin of the problem; it only changes the urgency of the response.

Practitioners often separate the question of blame from the question of operational responsibility, but in first-party code those two are closely linked. The same engineering organisation that introduced the flaw generally has the best context to assess exploitability, reproduce the issue, and verify that the fix does not create a new regression. Where the company also operates the software, it carries an additional burden because the vulnerable code can affect availability, data integrity, and customer trust at the same time.

Useful distinctions include:

• First-party code means the company is accountable for both development quality and release governance.
• Exploit-before-disclosure changes incident response priority, but not the origin of responsibility.
• If the company controls deployment, it also controls exposure windows and patch timing.
• If the flaw affects shipped product or hosted service, remediation must address both code and operational rollout.

Frameworks such as the MITRE ATT&CK Enterprise Matrix help security teams think about how exploited weaknesses are turned into access, persistence, or follow-on activity, but the accountability point remains simpler: the organisation that produced the vulnerable code is the party expected to fix it. This guidance breaks down only when the software is materially modified, redistributed, or embedded by another organisation that has taken over the effective control of the release and support chain.

Edge Cases That Change the Story Without Changing the Core Duty

Tighter accountability often increases legal and operational scrutiny, requiring organisations to balance clear ownership against the reality of complex supply chains and shared deployments.

Not every exploit scenario is identical. If a customer self-hosts the software, the vendor still remains accountable for the defect in its own code, but the customer may share responsibility for patch application, exposure management, and compensating controls. If the company used a third-party library, responsibility becomes split: the company is still accountable for shipping the vulnerable first-party integration, while the upstream supplier may also bear responsibility for the underlying flaw. Where teams disagree is usually about whether the issue was a code defect, a missed dependency update, or a release governance failure. In practice, all three can be true at once.

Another edge case is coordinated vulnerability disclosure. A company may not be blameworthy for the existence of a software defect in the moral sense if it was responsibly disclosed later, but it remains accountable for its own release discipline and patch responsiveness once the issue is known or knowable. That distinction matters for governance, not for absolving ownership. The strongest position is to treat exploitability before disclosure as evidence that assurance processes were insufficient, not as proof that another party should carry the burden.

For software teams, the hardest cases are usually those where product, security, and operations all believe another function owns the fix. That ambiguity is itself a risk signal, because exploitability tends to persist wherever no single team is clearly assigned to close the loop.

Risk and Threat Considerations

Vulnerable first-party code creates direct exposure because the organisation has placed an exploitable weakness into production under its own control. Once attackers discover it, the issue becomes a trust and resilience problem as well as a software defect, since the same team that introduced the flaw must also assess exploitation, contain impact, and prove remediation.

Failure mechanism: insecure code reaches release through weak review, insufficient testing, incomplete threat modelling, or rushed deployment, then attackers weaponise the weakness before defenders finish disclosure and patching. The mechanism is straightforward: the organisation’s own software becomes the attack path.

Impact: the result can include compromise of customer environments, unauthorised access, service disruption, loss of confidence in release governance, and extended exposure if patching is slow or coordination is unclear.

Practitioner Guidance

What to prioritise: assign one accountable owner for the full defect lifecycle, from discovery to verified remediation. In first-party code, ambiguity between engineering, security, and operations is often more damaging than the vulnerability itself because it delays containment.

What to verify: confirm whether the issue is in shipped code, a bundled dependency, or deployment logic, and verify who can actually patch it without external reliance. If the fix depends on another party, the accountability question changes; if it does not, the company should treat the issue as fully owned.

Practitioner takeaway: exploit-before-disclosure does not move accountability away from the author of the code; it usually exposes whether the organisation had a real release discipline or only an assumption of one.

Related resources from NHI Mgmt Group

• Who is accountable for vulnerable dependencies when a team ships code without centralised visibility?
• Who is accountable for fixing internet-facing appliance vulnerabilities before attackers exploit them?
• Who is accountable for fixing a React Server Components RCE before attackers exploit it?
• Should organisations prioritise external exposure or internal credential governance first?