Who is accountable when a software product fails to maintain secure development and disclosure practices?

Why This Matters for Security Teams

When a software product fails to maintain secure development and disclosure practices, the issue is not just a coding flaw. It becomes an accountability problem across build pipelines, release discipline, vulnerability handling, and customer exposure. NIST SP 800-53 Rev 5 Security and Privacy Controls frames these responsibilities through secure development, configuration management, and incident response expectations, which is why the manufacturer cannot treat security as optional after launch. Buyers can reduce risk, but they cannot repair broken producer controls at scale.

This is especially important in software supply chains where exposed secrets, weak disclosure handling, or delayed fixes can turn a single product defect into many downstream incidents. NHIMG has documented how quickly attackers move once credentials are exposed, as shown in the LLMjacking research, and why persistent gaps in software and NHI hygiene create repeatable abuse paths. The broader NHI context in the Ultimate Guide to NHIs — The NHI Market shows that identity sprawl and weak lifecycle discipline often compound vendor failings.

In practice, many security teams encounter manufacturer accountability only after a disclosure delay, leaked secret, or insecure release has already affected production systems.

How It Works in Practice

The accountability model is straightforward: the software manufacturer owns secure development and disclosure practices, while the buyer owns due diligence, deployment guardrails, and ongoing monitoring. That division matters because customers cannot verify every internal build control, but they can require evidence that the producer has a secure software development lifecycle, a vulnerability disclosure process, inventory awareness, and revocation-ready secret handling.

Operationally, current guidance suggests treating the vendor as the primary control owner for the product itself and treating the customer as the risk manager for how that product is used. Practitioners should ask whether the manufacturer can demonstrate secure build provenance, rapid patching, coordinated disclosure, and incident response procedures. Where the product handles secrets or NHI credentials, this becomes even more critical because exposed keys can be abused quickly once discovered. NHIMG’s DeepSeek breach analysis is a reminder that software exposure is rarely limited to one defect when data, credentials, and release hygiene are weak.

• Require contractual commitments for secure development and disclosure, not just generic warranties.
• Verify vulnerability intake, triage, fix, and customer notification timelines before procurement.
• Ask how the vendor inventories shipped components, secrets, and update channels.
• Pair vendor evidence with internal controls such as segmentation, least privilege, and secret rotation.

These controls tend to break down when software is delivered through opaque supply chains or when the manufacturer has no reliable way to identify all affected customers after a security issue.

Common Variations and Edge Cases

Tighter supplier accountability often increases procurement overhead, requiring organisations to balance assurance against speed, cost, and vendor availability. That tradeoff is real, especially for open source components, SaaS platforms, and embedded software where responsibility can be shared across multiple parties. Best practice is evolving, and there is no universal standard for allocating every disclosure duty in every contract.

One common edge case is open source software. The maintainers may publish fixes, but the organisation packaging, distributing, or operating the software still has obligations if it is the effective manufacturer in the supply chain. Another edge case is a software-as-a-service product where the buyer never receives the code, yet still depends on the provider’s disclosure discipline and incident response. In regulated environments, customers may also need to document compensating controls even when the vendor is contractually accountable.

The practical test is whether the party most able to prevent, detect, and disclose the failure is the one being held responsible. For product security failures, that is usually the manufacturer. For operational exposure after deployment, the customer still shares responsibility for configuration, access control, and monitoring.

Related resources from NHI Mgmt Group

• Why do security champions improve secure software delivery in development teams?
• Who is accountable when a device or software product fails to meet EU Cyber Resilience Act requirements?
• Who is accountable when a vulnerable product misses the CRA deadline?
• Who should be accountable for API policy and compliance when development moves faster than security reviews?