SBN

3 steps to reduce your API and web service risk in M&A due diligence

Learn more about the risk areas related to APIs and web services during due diligence in M&A transactions involving software, and how to reduce each risk.

3 steps to reduce your API and web service risk in M&A due diligence

Today, developers are more likely to assemble code for their applications than to write it. Sure, they still write the critical business logic. But with codebases comprising up to 90% open source or third-party components, developers save time reusing code for commonplace functionality. One type of component available for reuse is API-based web services, many of which are free to use for basic functionality. But using API-based web services can create issues regarding copyright, end user licensing, terms of use, and data and privacy policies.

Developers frequently find useful APIs for their applications on the internet. But development organizations might have no control, or even knowledge, of which APIs their developers are using. This could go on for an indefinite time. Then one day your company decides to buy the organization. How can you reduce the risks related to API-based web services involved with the acquisition?

Get the white paper on web services and APIs in M&A due diligence

Reducing 4 areas of API-based web services risk

When you’re considering acquiring a company with a substantial valuation based on software, there are four primary areas of concern when that software makes calls to API-based web services:

1. Legal and compliance risks

API-based web services come with copyrights and conditions of use that you need to understand.

API-based web services come with copyrights and conditions of use that you need to understand. Terms of use can also be complex and dynamic. When terms of use change, users agree to the new terms simply by continuing to use the API-based web service. Suffice to say, when you buy a company licensing API-based web services, you also buy their legal and compliance risk.

2. API security risks

API-based web services pose two risks to acquirers: the data that APIs send and the data they receive.

API-based web services pose two risks to acquirers: the data that APIs send and the data they receive. Sent data can leak or be eavesdropped on. Received data can include executables, tampered images, viruses, or malicious code. And data going in either direction can be subject to man-in-the-middle attacks.

3. Data privacy risks

All data needs the same tender, loving care when it comes to data privacy.

Organizations sometimes treat data from APIs differently than data they get from other sources. All data, especially personally identifiable information (PII), needs the same tender, loving care when it comes to data privacy. As the acquirer, you must do due diligence on how the target’s application handles API data, how it combines that data with anonymized data from other sources, and where (geographically speaking) that data is sent to, received from, stored, and processed to comply with regional data privacy regulations such as GDPR in Europe.

4. Operational/business risks

You must put in place contingency plans for when—not if—an API becomes unavailable for any reason.

API-based web services, in their free state, offer no SLAs. When looking at a potential acquisition, you need to know what continuing risk the use of free web services entails. You could end up facing a business continuity issue if the API license is revoked, the API is deprecated, or a competitor buys the API provider and restricts access to direct competition. You must put in place contingency plans for when—not if—an API becomes unavailable for any reason.

3 steps to mitigating API-based web services risk

As with open source software, the way for acquirers to reduce the risk of API-based web services revolves around full disclosure and discovery. Basically, it’s a 3-step process:

  1. Identify all API-based web services in the application. Know with certainty which APIs are being called, what data they provide, their associated licenses, and how much and how often they’re used. You can get this information by asking the application developers or, better, by conducting an audit of the application’s APIs with an API/code scanner.
  2. Analyze the application’s API licenses. Pore over the application’s API licenses to make sure the target company properly complies with the contractual terms. Look for inconsistencies as to how the APIs are used on paper and in real life. Also, note any differences between what data is supposed to be supplied and is actually delivered.
  3. Construct a remediation plan. Your remediation plan should encompass issues falling into different buckets, including code, legal, redundancies and contingencies, data privacy, and contractual risk allocation. Respectively, this will cover replacing APIs due to service interruption or discontinuation, seeking addendums or waivers to existing licenses, having API backups ready to go, informing the user base about what data is collected and transferred, and seeking binding representations and warranties from the target as to the API-based web-based services included in the deal.

Pulling it all together

This blog post provides a very high-level summary of how acquirers can reduce the risks posed by API-based web services in the merger and acquisition process. For a more detailed discussion of the due diligence required, check out our new white paper Best Practices for Reducing Web Services and API Risks in M&A.

Get the white paper on web services and APIs in M&A due diligence


*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Derek Handova. Read the original post at: https://www.synopsys.com/blogs/software-security/api-web-services-due-diligence/