The Security of Using Third-Party Software: A Vendor’s Perspective
Inclusion of third-party software as part of a vendor’s own products has become a common method of reducing time from conception to product launch. As with all strategic decisions related to product development, the costs of including third party code are weighed against the benefits. In this post I’ll discuss how security considerations should be factored into this decision. These include who has worked on the code, the end-user, and the vendor using it. Who does the work (and how much does it cost)?Let’s assume a simple premise that is the main reason for usage of third-party code: why reinvent the wheel? If you are developing a product and the functional specifications require a commonly used function or service, it can be advantageous to use third-party code for at least three reasons:* Time spent developing and debugging that part of the code is reduced, thereby reducing time to market (TTM)* Overall costs may also be reduced* Highly complex functionality (e.g. crypto code) is best implemented using ‘tried and true’ algorithms, and/or there is a requirement to utilize a specific common code sourceI intentionally say costs may be reduced, as there are really two types of third-party code: commercial (for fee) and open source (for free). Commercial code means you pay a fee up front to use the code under specific condition which are detailed in the End User License Agreement (EULA). This fee becomes part of your development cost.Open source is generally free. Costs could remain low, provided you maintain adherence to the licensing terms. Those typically include providing a copy of the open source code included with your product, as well as acknowledging that you have included open source code in its development (GPL is a well-known example). However, maintenance of the code is a less predictable expense than if the code is developed directly by the vendor.Sometimes, the savings on TTM alone is well worth it: think about all of the applications which require an operating system and machine as a host. Rare is the vendor that is going to commit resources developing and maintaining a new operating system. Many cannot scale to the task or do not wish to create a new OS. Instead, they include another developer’s code (whether commercial or open source) in exchange for agreeing to terms set by the OS’s creators. TTM is reduced and, depending on the price of the code and scope of the project, development costs are reduced as well.How secure is it?Code sold for fee typically has a finite number of developers working on it in a ‘closed’ environment: access to the source code is normally limited or not possible if you are not employed by the developer, thereby potentially reducing (but not eliminating) introduction of catastrophic bugs, including malicious code.In contrast, open source is as its name implies: anyone is permitted to contribute and help improve it. The community of people working on open source projects is generally self-policing: while not always formalized, there is usually a core group of individuals that vet updates and changes to identify and minimize destructive code (benign or malicious). This seems to work well for the most part, despite the size of some more well-known collaborative open source efforts such as Mozilla Firefox.How will security vulnerabilities be perceived by the end user (consumer)?The degree and speed to which a vendor can respond to reports of a vulnerability in its products is dependent upon a number of factors. A major factor is where does the source need to be updated upon discovery of a vulnerability, and by whom. I’ll purposely use two extremes to help illustrate this point.- If you use a version of Microsoft Windows with Internet Explorer (IE) as your primary browser, Microsoft owns the source code for both of those products and you, as a consumer, paid for those products. If a malicious bug is found in IE, you know whom to turn to for authoritative information and, ultimately, a fix- OpenSSL is included in a variety of products by many vendors, including Cisco. If a vulnerability in the code is reported, the timing for the fix to be incorporated is reliant on how responsive both the open source community is as well as any vendor who has OpenSSL included in their code. If you are an IT manager with product that use OpenSSL, you must examine the security of your products on a case-by-case basis. You may be responsible for the maintenance of products both vulnerable and not vulnerable, depending upon the responsiveness of the ‘selling’ vendor.What are the responsibilities of the vendor?How a vendor wishes to be perceived by its customers in terms of responsiveness to security issues becomes an additional consideration when using third-party code as part of its product. As I noted earlier, reduction of TTM and minimization of costs are desirable goals a vendor tries to meet. And again, perception can be shaped by the open or fee nature of the third-party code. If a vendor includes for-fee code as part of their own product, paying the appropriate fees and adherence to the terms of the EULA are necessary.When open source is used, a vendor must ensure that they comply with the terms of usage previously noted. In reality, compliance can be challenging for a vendor if a vigorous set of checks and balances are not in place to ensure that each engineer knows and understands the responsibilities associated with usage of open source. This is particularly daunting if the vendor has thousands of engineers working on hundreds of products across multiple global locations.Beyond the obvious consequences for failure to comply (e.g. potential legal action), there are more complex issues as well. For example, what if the vendor modifies an open source ‘snippet’ and then includes it as part of a commercial product? Under the scope of some licensing terms, this could require that the vendor share the modified source code with the community (a practice known as ‘copyleft’). In effect, what the vendor had created as intellectual property now must become open source due to its failure to understand and adhere to the terms of usage.Even if the aforementioned issues are handled responsibly, there are still issues that must be addressed when reporting security vulnerabilities. For example, addressing vulnerabilities in third-party code which is present in multiple vendors’ products should be coordinated carefully to ensure that customers are not exposed to malicious behavior — a tenet of ‘responsible disclosure.’ But not all third-party providers have the resources, structure or perhaps even do not share the ‘responsible disclosure’ philosophy. ConclusionVendors can benefit from third-party code if they are willing to allocate the proper resources necessary to ensure consistent compliance with the terms of usage. With respect to product security, the implications of introduced vulnerabilities can vary depending upon the source of the third-party code, the knowledge of the vendor’s employees, and the commitment to protecting its customers when (and if) vulnerabilties are reported.