1 in 4 M&A transactions has already been affected by a cyber incident during or shortly after closing, and traditional due diligence still does not cover the right areas.
CEO
Diogo Goebel
When a company is acquired, the buyer inherits everything. Contracts, customers, team, culture, and also the software, with all the history of decisions that no one documented, outdated dependencies, and unaddressed vulnerabilities. This liability rarely shows up in the valuation.
Financial due diligence has evolved significantly in recent decades. Security due diligence, less so. And software supply chain due diligence, which involves mapping which components are in the code, where they came from, which CVEs they carry, and whether provenance traceability exists, practically does not exist as a structured practice in most transactions.
And the cost of this gap is starting to show.
According to the report CISO Redefined III, published by FTI Consulting in March 2026, 1 in 4 executives faced a cyber incident during or shortly after a transaction. Among those affected, 42% reported a reduction in valuation and 58% had financial targets compromised. These are numbers that do not enter the deal pipeline but appear in the results after closing.
Another data point that caught my attention: only 23% of companies proactively manage cyber risks after closing. The risk is inherited, but the management process does not come with it. Add to this the fact that 1 in 4 CISOs reports pressure to close deals quickly at the expense of cyber due diligence, and the equation becomes clear: the speed of the deal compresses the space where problems remain hidden.
What is still missing in this equation is a focus on the software supply chain itself.
What a vulnerability scanner does not answer in a due diligence
A vulnerability scanner goes through the binary and points out what is exposed today, but it does not answer where that dependency came from, if it has a history of critical CVEs without remediation, if there is an SBOM documenting the components, or if the build's provenance is verifiable. These questions remain unanswered, and that is exactly where the valuation haircut happens, when someone better prepared sits on the other side of the table.
There is another signal that usually goes unnoticed: when the target company spends a large portion of its senior developers' time fixing vulnerabilities that were already born in the base image, its engineering valuation is fictitious. What looks like delivery capacity is, in fact, an expensive team maintaining technical debt that the buyer will inherit.
BCB 538 and CMN 5,274: software supply chain has become a regulatory liability
In the Brazilian context, this risk has a multiplier that is not yet being priced in. BCB 538 and CMN 5,274, in effect since March 2026, made the suppliers' software supply chain the responsibility of the financial institution. A target company without technical evidence of integrity in its software supply chain is not just an operational risk for those who buy. It is a regulatory liability that the buyer inherits the moment they sign.
For a financial institution acquiring a fintech or a technology provider, the question "what are the open CVEs?" has become insufficient. The question that matters now is: can you prove, by version and by component, that your software supply chain complies with what the regulator requires?
If the answer depends on spreadsheets, tickets, and institutional memory, the risk is priced wrong.
What changes in practice is simple to state and hard to execute: the buyer needs to include in the technical due diligence the verification of SBOM, CVE remediation history by version, traceability of provenance, and evidence of regulatory compliance of the software supply chain. Not as a compliance checklist, but as an obligatory input for valuation.
While this is not the standard, whoever knows how to ask this question before closing will have an advantage. And whoever doesn't know will discover the problem later, when the price has already been paid.
Operating Kubernetes in production for more than 13 years. With Quor, this experience extends to software supply chain security as well.
GET UP
© Getup · 2026
