Software Security Audit Guide for Software Acquisition

Mergers and acquisitions are standard business practices; they allow companies to grow and obtain assets to increase competitiveness and their bottom line. However, while these contractual allegiances and alliances are primarily bureaucratic, the evolution of technology created addendums to standard protocols, including a software security audit.

The evolution of technology and the dependence on software is astounding. Over only a few decades, the modern world evolved to rely on tech to shape, plan, manage, and analyze nearly every facet of life and business. No single person or entity is not somehow influenced or affected by technology and the software that manages it. In a realm where innovation is king, open-source software is queen.

Nearly all corporate transactions now include some form of technology acquisition. While every company does its best to ensure secure programming, prospective parties must perform software due diligence when merging or acquiring assets. The acquirer must review the target’s compliance practices and software. OSS will undoubtedly come up during such comprehensive reviews, and audits must include verification measures despite the potential challenges. It is crucial to acknowledge the differences between proprietary software and OSS. The target must know and comply with all license and regulatory measures or risk the acquisition or merger.

Know Everything About Your Software

Tech mergers and acquisitions require transparency. Most businesses understand that reviewing financials, legal issues, and potential culture clashes are paramount to an effective M&A, but software acquisition often gets overlooked as a secondary concern. However, an acquirer can step into significant liabilities without knowing where the code originated or any security or license issues. Additionally, the target business risks alienating future partners or buyers if it does not know everything about its software.

It is standard practice for developers to use code from open-source repositories, embedding it into a company’s products and ensuring on-time development. The usefulness and integration of OSS are beneficial from a cost and efficiency standpoint. Unfortunately, the use of OSS can become so habitual that some security and risk prevention methods are ignored in favor of speed. For instance, programmers might not review reused code for security and ownership issues, which might seem inconsequential initially but can result in significant problems later.

When developers continually reuse OSS without ensuring compliance, they are embedding problems throughout a company’s product line. In many instances, the use of General Public License code or “copyleft” licenses goes undetected, but it results in expensive and time-consuming problems when discovered, which is inevitable. If these issues are uncovered during an M&A transaction, they can present problems for both sides. Therefore, before going through an M&A process, the target must know and learn everything about its software to mitigate any potential compliance issues.

Common Open-Source Scenarios

Before delving into audit methods, it helps to acknowledge how a target can incorporate OSS into its source codebase. The most common ways companies use OSS in their software and products include:

Incorporation
Linking
Modification

Incorporation involves using an open-source component or portions of it to develop software products. The use of OSS or snippets does not immediately pose any license risks, depending on the OSS and software licenses. Incompatible licenses can result in a problem.

If using conflicting licenses within the proprietary codebase, the company’s legal responsibilities become muddied and complex. Anytime a code is incorporated, it needs to be internally tracked, declared, and approved because of the potential risks and liability concerns.

Linking involves the processes of static or dynamic linking, combining, packaging, or creating interdependencies. Typically, linking does not present any significant issues when auditing because all linked libraries are generally listed at the beginning of the code. Linking is different from incorporation because the source code remains separate.

Finally, modification occurs when a developer uses OSS but modifies it to suit the project’s needs. There are three ways of modifying OSS, including:

Adding new code to the OSS component
Optimizing, changing, or fixing the component
Removing or deleting portions of the code

Depending on the extent of modification, the process can eliminate most liability and compliance concerns. The level of alteration essentially remakes the OSS, creating something entirely new.

During an M&A, merger and acquisition software is used to help auditors analyze proprietary software and products. The programs are incredibly effective at identifying compliance and license issues.

Audit Methods

An open-source security audit is essential to assess value. The acquirer needs to evaluate the OSS source code snippets and learn how it relates to the target’s proprietary code. However, the opposite is also true in merger relationships.

The audit helps eliminate false positives, and software minimizes the labor necessary for manual searches. There are three ways to audit:

Traditional: An auditor gets total access to the target’s code. The audit is performed either on-site or remotely.
Blind: The auditor does not see the source code. The audit is performed remotely.
DIY: The target company or acquirer performs the audit. An auditor can be used for random verification.

Despite the ability to sum up each audit type with a couple of sentences, the methods are typically more involved. Having a thorough understanding of each method is crucial to selecting which is preferable.

Traditional Audit Method

When it comes to open source compliance and M&A auditing, the original method of source code scanning, or the traditional method, involved remote or physical access to the source. The process starts with the initial contact or meeting between all parties to discuss relevant aspects of the audit. The auditors then receive access to the source code through a cloud server or on-site. Next, the auditors run a scan to identify all OSS components and snippets to determine license compliance. Finally, the auditors provide and present a final report, including:

Executive summary
Bill of Materials
SPDX report (not all auditors have this capability)

While this is not the only potential audit type, the traditional audit is a standard method. The primary advantage of such an audit is collecting multiple bids on the same job. However, the traditional audit requires extensive cooperation from the target because it can be invasive and sensitive. This form of auditing requires tremendous flexibility and hospitality, which may seem intrusive and become a nuisance at times.

When a traditional audit is preferred, the acquirer and target should be on the same page. The target will need to accommodate most requests from the auditor, including on-site access.

Pioneered by a Stockholm-based company, FOSSID AB, the blind audit is a way to address confidentiality requirements in M&A transactions. Auditors can generate reports and perform their duties without directly reviewing the source code with the appropriate technology.

The blind audit process begins with an initial meeting to determine the clients’ needs. Then, the target company receives installation and execution instructions through a Command Line Interface to collect their software’s digital signatures. The signatures are then transferred securely over SSH to a dedicated server at the auditor’s data center. The auditor then searches for OSS files and snippets using a knowledge base comparison tool. All auditings occur without accessing the target’s source code, using only digital signatures. The final audit report is sent to the target company for review before delivery to the acquirer.

The primary advantage of a blind audit is the maintained secrecy of the target company. The auditor may never learn of the target’s identity with appropriate precautions, ensuring paramount confidentiality. While not many companies or auditors offer blind audits for open-source compliance services, it is an approach that can add value to transactions that require secrecy or caution, especially when announcements could impede M&A efforts.

DIY Audit

Many M&A transactions are set on strict timelines. Unfortunately, auditors are not always available when companies need them. The DIY audit method provides a time-saving approach that can also be cost-effective for each party.

The DIY method allows the target or acquirer access to the compliance cloud tools of the auditor for a limited time. With access, the target or acquirer can perform the audit in-house while accessing the auditor’s knowledge base and reporting facilities. However, this method should only be attempted by companies with an adequate or capable internal team. The team must possess the wherewithal to interpret the scan results and suggest mitigation or remediation guidance. The auditor can verify the findings to ensure the integrity of the results and audit.

As with any audit, the process starts with the initial contact to determine the goals of the audit. Then, as with the blind audit, the target company receives the Command Line Interface with installation and execution instructions, allowing the collection of digital signatures. The auditor then provides time-restricted access to the web application and aids in the initial setup of the tool. Next, the target company uploads its digital signatures and runs the scan. In the final stages, the target company audits its code, creates a final report, and sends it to the auditor for verification.

Software Security Audit Final Report

It should not surprise companies to find a lot of white noise in the final reports provided by auditors. Because auditing tools tend to highlight all potential issues, companies in an M&A transaction can often find many non-issues in the final report. Essentially, many audit reports contain a lot of white noise. Therefore, companies should prepare to sift through the noise to get to the meat of the information. The auditing process is primarily used to highlight any potential concern for the acquiring company; it is up to the company to evaluate each item’s threat or risk level.

Additionally, participating companies must acknowledge that security and version control are not the primary concern of the auditing process, which focuses heavily on compliance issues. Companies need to investigate OSS updates and exposure or threats using other tools and practices. However, some auditors might offer a mapping service to identify OSS components and known vulnerabilities. The costs associated with these one-off scans might not be worth the investment, especially when companies can invest in and integrate SCA tools into their SDLC. As with anything else in business, decisions typically come down to a cost-benefit analysis.

Pre- and Post-Acquisition Actions

The audit should highlight the target company’s efficiency with managing OSS, including compliance with license obligations. Once reports are delivered, the two companies should negotiate remediation actions.

Depending on the final report’s findings, there are a few ways to resolve any pending compliance issues before completing the M&A transaction:

The target can remove the code, primarily if it only augments the proprietary code.
The company can use cleanroom techniques to design around the OSS.
If the offending code is essential to the proprietary software, the company must bring its code into compliance.

Regardless of the remediation action, it is crucial to identify the individuals responsible for using the OSS. While non-compliance with the OSS license is often the result of accidental oversight, the individuals must realize their mistakes and aid in the remediation effort. Their insight is often helpful in resolving the problem, and they may have additional knowledge or documentation that is essential to a solution.

Before entering into the merger and acquisitions process, especially as a target, companies must understand their software and resolve any compliance or vulnerability concerns. Choosing to rely on the findings of the audit process is a mistake, and it may cost the target the entire transaction.

The incorporation of OSS is standard and practical for software development. However, companies risk frequent compliance and vulnerability issues without effective and thorough security practices throughout the SDLC.

Conclusion

SOOS can help mitigate these concerns. By incorporating SCA and vulnerability scanning tools into every stage of the SDLC, companies become intimately aware of licenses and vulnerabilities. Using SOOS, companies will gain unprecedented insight into any compliance concerns and mitigate any potential exploits or vulnerabilities before bringing software to market.