Imagine, if you will, you (and your team of developers) have invested the last two years building a fantastic new Software as a Service solution, and you have poured blood, sweat, and tears into the development process. Your team of developers has used every trick in the book to build the fastest, most efficient, incredible solution, and finally, you are gaining traction in the market. Early adopters love your product, and you are beginning to build a sales pipeline.
The last two years of privation, long hours, sleepless nights, and funding concerns are about to be erased as the dreams of the previous two years are about to come true – a much larger company has seen your product and wants to integrate your solution into their product and is putting together an offer on your company that you just won’t be able to refuse. You and your investors are thrilled; all the hard work is about to pay off.
But what’s the next step? Here begins the due diligence process. They love your product and are willing to pay top dollar. They hire a team to perform the due diligence, review your financials and sales pipeline, interview customers, and review your policies/procedures. The assessors are smiling, and the management teams are preparing to celebrate (some of them probably have already started). A few of your earliest employees even drive to work with brand new Teslas.
Then they bring in a team to perform due diligence on the product and run it through a code analysis tool. A few days pass, and there is a palpable iciness in the air. The management team for the potential acquirer goes silent for a few days, and then they call a meeting.
When the teams join the Zoom session, you are not greeted by the same smiles present the previous week. The meeting starts with a statement from the acquiring company’s acquisition project manager; she is concerned about the findings in the code assessment and wants to better understand the implications of what the audit team found.
The report is shared on the screen, and the auditor points out the findings.
1. As expected, the scanning tool found the open source within your code base. The auditor explains that this is normal; developers use open-source code to speed up development.
2. The concern the auditors have found relates to two major issues:
There are numerous uses of Open Source where no license statement is included with the code. The tool found the Open Source, identified where it was from, and determined that much of the use of Open Source does not include the required licensing representations in the source code. Open source has been used thousands of times without adhering to its license. The required attribution clause is not included within the source code repository.
More troubling is that there are additionally thousands of uses of open source within the product that include protective copyleft licenses (e.g., GPL and AGPL) that require all derivative works to be similarly shared under the indicated copyleft license.
The acquirer’s project manager asks the next obvious question, what will it take to remediate the issues? The acquiring company does not want to purchase the company if everything they purchase becomes publicly available. The valuation that the acquirer proposed presumed that they were acquiring a proprietary application. Based on this audit, that is no longer the case – all of the code would need to be opened up and made available.
The assessment team pipes up and indicates that the first issue around attribution is relatively easy to solve. We use Threatrix as our assessment tool, and they have integrated a capability to semi-automate remediation for attribution issues. So, at least one issue will be resolved in the near term. The assessment team lead continues by saying they can only partially help regarding the second issue by providing a detailed report from Threatrix indicating where each copyleft license instance exists with the code base. Finding the issues won’t be a problem; however, the assessment team does not have a solution for fixing them as developers will need to remove the offending code and replace it with either custom code or more permissively licensed open source.
You and your team of developers meet together to discuss the issue. The report shows your code is riddled with problematic open-source licenses. You don’t want to blame, so you approach it from the perspective of what it will take to fix all of the issues. The development team says it will take at least six months of concerted effort to eliminate all of the problematic code.
The next day you approach the acquiring company’s management team to discuss the issue. They are understandably concerned. They indicate that they cannot complete the acquisition until the problem is resolved and put the deal on hold. Your Board is worried that you have allowed this to happen as the investors are not getting the expected exit. New feature development will need to be halted to remediate the issue, and your competitors might catch up and surpass you. The acquiring company might move on to something new or even worse to one of your competitors.
All of this is 100% avoidable. You could have scanned your code daily using the same tool the auditors use; if an issue appeared, it could be addressed immediately. This exact scenario has played out before. Understand what is in your code. Find the issues when they are small and manageable. Go into audits and due diligence exercises knowing what the findings will be, or just provide them the report on day one – after all, you have nothing to hide.
Threatrix is the first-to-market, cost-effective solution, providing continual license compliance and automated security, allowing organizations to determine their exposure to open source risks with one solution. Actionable results drive measurable reductions in risk and license compliance, saving organizations developer time and costly remediation efforts for compliance teams.
