Data privacy and security terms have become ubiquitous in software license agreements, including in both hosted service agreements and software license agreements. Security terms have been the norm for many years in the SaaS world, where the software licensor is hosting a customer’s data. However, in more recent years, much to the chagrin of small start-up software licensors of on-premise software, security terms and guarantees are now an expected part of the deal, even if the terms tend to be shorter in length and more limited in scope. Given the increasing importance – and inherent risks – of storing data, customers are understandably still concerned with data privacy and security even where a vendor is not actually hosting or storing their data.
This is because vulnerabilities in software code can easily result in a security incident that exposes customer or personal data even in situations where the vendor is not hosting its customers’ data. Indeed, the “recent” SolarWinds hack demonstrates that vulnerabilities in a vendor’s software can lead to intrusions in its customers’ systems. In 2020, hackers input code into a SolarWinds software update. Unbeknownst to SolarWinds, SolarWinds pushed the update to its customers and when installed, the hackers were able to infiltrate the customers’ own systems and install further malware in those customer systems. The breach went undetected for months until the cybersecurity firm, FireEye, discovered it.
The 2017 Equifax security breach was another large security incident exposing volumes of personal data, due to a vulnerability in certain Apache open source code that was not patched (although the patch had been available for quite some time). In both cases, customers’ systems were compromised. As such, customers want to know – and be assured – that its vendors develop (and maintain) their software using standard anti-virus controls and secure coding methods, and have certain basic security measures in place.
Particularly with respect to open source code, which many engineers are eager to use, it is still imperative that the security of such code is tested. Arguably, the community aspect of open source may render open source more secure – with more developers touching the code, it can lead to better, cleaner and more secure code. However, some communities are not as robust or formal, and indeed most open source code is not checked for security vulnerabilities, despite the fact that nearly every software program uses some form of open source code (whether or not the legal and security officers in the company know about such code is another story).
In the open source world, if a vulnerability is found in a particular version, the question becomes whether or not all users of the open source code will easily find or obtain a new patched version or if they will implement it quickly – likely not, as demonstrated by the Equifax breach. Updates take time, particularly with complicated systems, and open source projects may not regularly push updates to users. Companies would be well-served to have their code scanned at regular intervals by industry leaders in open source management (e.g., Black Duck, WhiteSource, Veracode etc.) that can identify what code is actually used, what license it falls under and, now more critically than ever, what security risks may be present. Several nonprofits have sprung up to lead the challenge to improve security in open source: for instance, the nonprofit Open Web Application Security Project® (OWASP) works to help companies improve the security of software, including open source code, and provides lists of detection tools that companies can use. Other software industry leaders, including Microsoft, are involved in the Open Source Security Foundation.
No matter the size of the company, security must be handled at the outset of development and continue through the lifecycle of a product. It must be comprehensive and address the company’s own code, licensed open source code and licensed vendor code. Likewise, the security program must be tailored to the type and size of the business, the sensitivity of the data involved, as well as the company’s risk tolerance.