The Importance of a Third-Party Due Diligence Perspective on Code Risk
Aug 04, 2025 / 3 min read
Merger and acquisition (M&A) targets vary in the sophistication with which they manage software risk. Generally, smaller companies have fewer controls in place to identify and address security, legal, and quality problems in their code than bigger companies. But when targets are using tools to manage aspects of code risk, acquirers may want to consider that in planning their due diligence.
If a target company’s development team is above average with regards to how it ensures good code, particularly if code scans are integrated into its software development life cycle (SDLC), an acquirer should take some comfort with respect to code risk. However, with the limitations of tools and how they are deployed, third-party audits remain a due diligence best practice.
Understanding which tools a target uses in software development is a good foundation. Different tools are aimed at the three areas of code risk: security, open source, and code quality. An organization may be set up to test for quality but not have a good handle on application security and third-party code content. All three risk areas are best managed with automation and tooling, and any is better than none, but it’s important to understand the quality and focus of the tooling. Some smaller companies use rudimentary open source scanners, for example, that are a good start, but by nature simple tools don’t find all the open source, particularly code snippets, which have risen in importance of late with the advent of AI code generation.
Most tools, particularly sophisticated ones, require some expertise to deploy and configure. Typically, companies implementing a tool will tune it for their needs, increasing or decreasing sensitivity to particular issues. Most tools allow you to configure the severity classification of issues. For example, something that would normally appear as red, such as a specific type of security vulnerability, might instead show up as yellow or even green because of the way the target has implemented the tool. But many tools don’t log the specifics of how they were configured, so you don’t know what “ruler” was being used to measure.
Software analysis tools typically allow users to interpret or even override results. They may not require or even allow for comments from the user. A user might dismiss a bug for good reason or due to ignorance or to cover up a problem. You can’t tell from a report. And even seasoned software developers don’t have experience or expertise with tools used by engineers who evaluate code for a living. Just as with any specialized field, seasoned experts are always in the best position to make sense of results.
Importantly, scan reports from a tool usually don’t make clear the scope of the code they relate to, i.e., which applications or files are covered by the report. An application may have five modules, but the tool may have been run on only three of them. Perhaps this is for a good reason, but it could be an inadvertent or even an intentional omission. There’s generally no way to know.
Lastly, tools are only part of the process and only tell the story of that part. Dozens of bugs may have been cleared and pushed into a queue to be addressed in the next release. The developer can mark them as a nonissue although they have yet to be addressed and they are not highlighted in the report. The tracking of these issues sits outside the tool, and so it doesn’t show up in the reporting.
For these reasons, reports supplied by a seller will not give a definitive picture of all the risks that are actually in the software. A trusted, expert third-party auditor with properly configured, world-class tools can work with the acquirer to ensure insight into to all the relevant code from the target. They can comprehensively analyze open source content, code quality, and application security, emphasizing areas of the acquirer’s concern based on the investment thesis, and hints of concern that may have come up in their prediligence. They have the expertise to augment the analysis and overcome the shortcomings that any tool has, and can expertly interpret the results free of bias.
If a target is using any tools and automation to evaluate its software, that should give the acquirer some comfort and might suggest risk areas and applications to prioritize or deprioritize. But to thoroughly reduce risk in acquiring software assets, acquirers will do well to insist on expert third-party code audits.
