The Eight Open Source Questions Every Technical Due Diligence Asks

After several hundred technical due diligence engagements, spanning many industries and evaluating companies from very small startups to enterprise scale, one thing is clear: open source usage is going to be evaluated. It can uncover intellectual property risk, and the number one rule of diligence is simple. Have no surprises occur after the deal completes.

Here is what to expect when you go to raise capital. You will be asked these types of questions.

1. Do you use open source?
2. What is your open source governance, meaning your policies and tooling?
3. Do you have any copyleft IP risk? How do you know?
4. How do you stay aware of security vulnerabilities?
5. Are you using any unsupported software components?
6. Do you have any older software components which either now, or in future, will require updating, and how easy will that upgrade be?
7. Do you distribute open source?
8. Do you modify open source, and if so, have you contributed back to the open source community project?

These are not the only eight, and diligence is not a script. It is a conversation, and where it goes next depends entirely on how you answer the last one. A single vague reply about governance can open up twenty minutes of follow-ups that appear nowhere on this list. But these are the eight we keep coming back to, and they are the ones worth being ready for. Answer these well and you are ready for most of what follows.

So let us break down the purpose behind each question, what the acceptable answers are, and which ones cause red flags. Red flag is a common term in diligence: they are the findings deemed potential deal breakers.

Do you use open source?

This is the equivalent of an ice breaker question. The expectation is a reply along the lines of "Yes, we do," followed by "we are careful about which libraries we use," and some explanation of what careful means to you.

When we ask this, we are not looking for a specific answer, so there is no single best one. But there are worst ones.

The worst answers all point to the same concern, and it is not really about open source. It is about competence. You are trying to raise capital, you produce software, and you have no idea what open source is.

What is your open source governance?

Ninety-nine percent of companies know what open source is and have some idea of the degree to which they use it. This is where the real questions start.

The premise is to get at what you are doing to protect against copyleft license risk and to manage your security vulnerabilities. Answers come back across a wide range: we rely on our engineers to know best; we do not want to use GPL, so we catch it during code review; we run tools as part of our CI/CD pipeline that enforce which licenses can be introduced.

This is where the answers either describe tooling or describe manual processes.

For companies that use tooling, we follow up by asking who runs it, who reviews the results, and what the process is to mitigate findings. These questions all speak to thoroughness, because it really does little good to run tooling if nobody looks at the results. That is a checkbox with no value.

For the companies using manual approaches, we may follow up with questions like how do you know that dependencies do not bring in IP risk. This is where answers indicate an understanding of the concern, or the lack of one, and often go down the path of the tools being very expensive or hard to use, so it is on a roadmap but not yet implemented.

After these two questions, we have a pretty good sense of whether the company is knowledgeable about open source and knows what it should be doing, even if it has not yet implemented it. In the technical due diligence report, the recommendations will relate to a need for better understanding of open source, or a statement that funding should be approved to help the company procure tooling.

Do you have any copyleft IP risk? How do you know?

Depending on the previous answers, a company may or may not know whether it has IP risk.

For those that do run tooling, this question allows us to discuss what their findings have been and what the status of mitigations is. For example, a company may say they have GPL in use but, since they are a SaaS application, they do not have IP risk in using it. Another may say they have an AGPL license, but since this is internal tooling, it does not impact their software product. It is always good to have a healthy discussion about findings, and the technical due diligence report will summarize for the investor whether there are any known risks and whether these are acceptable, or whether we recommend a different approach be taken.

Then there are the companies that have no data behind their belief that their IP is safe. They simply reply that they do not think they have any IP risk and that this is something they review manually to prevent.

It is a bit stressful to undergo an open source scan, the results of which may be deal breaking, without any confidence that the results will come back clean.

How do you stay aware of security vulnerabilities?

We now start to focus on the second aspect of open source, which is what security risk exists due to vulnerabilities, or CVEs, in the open source libraries in use.

Unlike license scanning, CVE scanning tools are readily available and often free. One such tool is Dependabot, which is free for all GitHub repositories and reports whether the open source in use has vulnerabilities. You can configure it to filter to a severity level, such as critical or high, to avoid too much noise. Dependabot also allows you to manually mark a CVE as investigated so it does not keep reporting that CVE during future scans.

What Dependabot will not do is review your source code or attempt to determine whether a CVE actually applies to your use case. It simply tells you everything that is possibly wrong and leaves it to you to investigate.

We find some companies are less on top of IP risk but do try to stay aware of critical security vulnerabilities. With further probing, we may discover that the tools are turned on but too noisy, and not consistently investigated.

Are you using unsupported or ageing components?

We specifically ask whether the product is using any out-of-support versions of libraries. Some companies have strict processes to remain up to date, while many do not have consistent upgrade processes, and it is not uncommon for companies to have some out-of-support versions of libraries in use.

The concern with using out-of-support software is that you are no longer receiving security updates, so using older versions increases technical risk.

There are reasons some companies remain on out-of-support versions. Sometimes the upgrade process would be a very heavy lift, perhaps requiring an upgrade across major versions with many breaking changes involved, and the company has chosen to delay attempting it. Another reason is that the out-of-support component sits in a legacy product which the company hopes to deprecate in the next couple of years, so it does not want to spend engineering time updating it now.

These are all business decisions that balance the company's needs and its risk tolerance.

Alongside the out-of-support question is the soon-to-be-out-of-support question. Together these frame the current and shorter-term risk, and the level of corresponding technical debt.

Do you distribute open source?

We ask this question because it is key to understanding open source licensing risk. Open source has hundreds of licenses, and many carry stipulations about restrictions that apply only if the open source library is distributed.

An example is that a mobile application is distributed, since it is loaded onto a user's device. Another example is that an on-premise system is distributed, since it is installed onto a company's servers. Cloud applications accessed via a browser are not usually considered distributed, though, like anything, there can always be legal arguments about whether what the browser downloads is or is not considered distribution.

Do you modify open source, and have you contributed back?

Sometimes a developer may like an open source library but want to tweak it, and since the developer has full access to the open source code, they can make a private copy and make the changes they want.

Some open source licenses add stipulations if a library is modified, so we ask this question to learn which specific libraries are modified and whether the changes were submitted back to the community, meaning made available for the open source project to include in a future release.

Here too, there are legal arguments about which licenses trigger which stipulations. Since we are not lawyers, we do not try to interpret things like distribution or modification rules. We ask so that there is a complete set of findings that can be handed off to IP lawyers to review.

Summary

Practically speaking, every software company uses open source, and so every company should have a good understanding of what it uses, whether there are any risks, and have a governance approach to manage open source.

The depth to which a company can provide open source reports and articulate its governance approach, meaning its processes and tooling, will be considered during the technical due diligence process, and that process may require a formal pre-close source code scan.

We did not build OSSScan to replace the high-touch, enterprise-grade source code scanning tools which a private equity firm will require be used. What OSSScan gives you is the preparation you need going into such a scan: a governance process, tooling, knowledge of what you use, and awareness of the license and security risks it carries. When that enterprise scan occurs, you will be much better prepared to respond to the voluminous report of findings these tools create.

OSSScan helps you be prepared, knowledgeable, and in control of the open source you use, and of the details about its use.

← Back to the OSSScan Blog