Due Diligence You Would Never Skip Anywhere Else

The Due Diligence You Would Never Skip Anywhere Else

By Jacqueline Winter, CFO & CISO, ActiveState

Every CFO who has ever approved a contract, signed off on an M&A transaction, or capital allocation request understands one thing with complete clarity: unreviewed liability is a governance failure. You do not let unvetted instruments into a financial portfolio. You do not close an acquisition without knowing what is on the balance sheet. Due diligence is not optional. It is the minimum condition for defensible decision-making. 

Open source software is the largest unmanaged liability on the enterprise technology balance sheet, and in most organizations it does not appear on any ledger the board reviews. April 2026 gave us four incidents that make the cost of that oversight very concrete.

What the Board Has Not Been Told

OpenAI revoked its macOS app signing certificate after a compromised Axios dependency executed briefly in a GitHub workflow. Two separate attackers poisoned widely used open source tools and extracted credentials from more than 10,000 organizations. An attack on an open source security tool specifically injected malware into the development pipelines of the organizations relying on it. Microsoft's attempt to enforce verification on major open source projects created a gap in update distribution that left users exposed while the appeals process worked through its backlog.
None of these organizations were negligent in any obvious sense. They had tools. They had processes. Some had strong security teams doing exactly what they had been told to do. What they did not have was governance at the point of origin: a verified, continuously managed source for the open source software entering their environments, with provenance that could be demonstrated and remediation that did not depend on human bandwidth to execute.
I have watched this failure pattern in other domains. It looks the same every time. The organization invests in tooling. The tooling produces information. Nobody changes how decisions are made at the top. The exposure compounds quietly until it does not.

The Question That Follows Every Breach

When a supply chain incident reaches the board, the question is not whether the security team had a scanner. The question is what the organization had in place to govern the intake of open source software before it entered the build pipeline. Not after. Before.
That distinction has a specific regulatory context in 2026 that did not exist 18 months ago. SEC cybersecurity disclosure rules, finalized in mid-2023 and effective for fiscal year 2024 filings, require public companies to disclose their processes for managing third-party software risk, including open source dependencies, and to report material incidents within defined timelines. The EU Cyber Resilience Act, which entered into force in December 2024, places the burden on the software producer to demonstrate that what shipped was secure at the point of origin. These are not emerging frameworks. They are current requirements operating against security leaders who are still running programs designed for a different standard.
The good news is that your scanner found 3,000 vulnerabilities. The bad news is that it found 3,000 vulnerabilities, and the regulatory question is not how many you found but what you did to prevent them from entering your environment in the first place. 'We had a scanner' is not a sufficient answer to that question. It has not been for some time, and the regulatory environment has now made that official.
The industry average for mean time to remediate critical CVEs runs upward of 60 days. In the current regulatory and legal environment, that number is not a benchmark. It is a liability that every executive who signed off on the security program is now personally attached to.

Why This Is a Leadership Decision, Not a Technical One

The security leaders I speak with are not unaware of the problem. They are working within organizations where the decisions that created the exposure were made above them, on timelines they did not control, by people who did not understand the downstream consequences. That is not an excuse for inaction. It is the actual problem that needs to be addressed, and it starts at the top.
AI-assisted development has made the governance gap urgent in a way that changes the timeline for everyone who has been treating this as a future consideration. AI coding tools do not sleep, do not take PTO, and do not stop to evaluate whether the dependency they just pulled from a public registry is actively maintained or compromised. The volume of unvetted open source entering production environments has crossed a threshold where human review at the point of consumption is not a viable control. The governance infrastructure built over the last decade was designed for a world where humans chose their dependencies. That world is gone.
The organizations that will navigate this well are the ones where someone at the top made a decision to govern open source intake at the point of origin, not at the point of discovery. That decision looks like establishing a verified, built-from-source library as the single authorized source for open source consumption across the organization. It looks like contractual remediation SLAs, measured in business days rather than industry-average months, that provide the documented evidence of a reasonably designed program. It looks like policy enforced at the tooling layer, so the governance does not depend on developer compliance under deadline pressure.

What Defensible Looks Like After April

The executives in the best position after April's incident wave are not the ones whose teams detected the attacks fastest. They are the ones who can demonstrate, with specificity, what their organization had in place to prevent unverified components from entering the environment at all.

That demonstration requires provenance, not a scan report. It requires immutable build-time records attesting to the origin and integrity of every component in the stack. It requires an automated audit trail that a regulator can review, a legal team can present, and a board can understand, produced as a natural artifact of the development process rather than assembled under pressure after an incident.

Due diligence has governed every material financial and operational decision in well-run organizations for decades. The question is not whether software supply chain risk requires the same standard. It is why we have accepted a lower standard for it than we would for any other liability that appears on a balance sheet.
April answered that question with four separate demonstrations. The organizations still treating open source governance as a technical problem rather than a leadership decision are the ones who will be explaining the gap to their board, their regulator, or their counsel.