Third Party Security
Many applications rely on externally developed code and libraries to support certain functionality. Examples include the integration of Apache or other webserver to provide browser-based configuration or the use of parsing libraries such as libxml or expat to efficiently handle XML.
While use of these third party packages decrease development time and produce better products, they do have a drawback — your application inherits the vulnerabilities and weaknesses of the third party code.
In general, there are two different ways to integrate third party code into an application: embedded source or linked library. Each option has its own benefits, shortcomings, and customer impact.
| Integration Type | Overhead | Security | Stability |
|---|---|---|---|
| Embedded Source | worse | worse | better |
| Linked Library | better | better | worse |
It really comes down to a choice between security versus stability. In order to keep an application functional, many vendors prioritize stability.
Embedded Source
One option involves the literal copying of the source code or application libraries into the application distribution. That is, the application and all of its third party dependencies are shipped as a single, integrated unit.
Embedding the source with the application gives the developers some flexibility to modify the existing code to better suit their needs (license dependant). By having control over this integration, the developers have time to throughly test any patches or other changes before publishing updates.
On the down side, managing embedded code is tedious. Developers are responsible for tracking the third party applications for security and other fixes that may affect their application. This is compounded by the fact that some third party code do not make priority fixes clear, so security fixes may be hidden within other functionality updates.
Furthermore, once a security fix occurs in a third party library, the developers are responsible for applying that fix to their application. Until they update the embedded code and publish an updated application, all of their customers are at risk and vulnerable to the security issue.
Linked Library
The other option for integrating third party code or libraries is to build the application with links to the dependent libraries. By using linked libraries instead of embedding them, the third party code is kept external to the application. The linked library model is frequently used by RHEL and can be seen in many open source projects.
Since the dependencies are external, the responsibility for tracking and maintaining that third party code shifts from the developer to the platform maintainer. Unlike the embedded model, linking does not require developers to push out application updates to handle patches in third party code.
One issue with using linked libraries is that the developers forfeit control over the linked dependencies. They have no control over when or how the linked libraries may be updated. Making sure that the application is linked against the correct versions of the right libraries (and all cascading dependencies are properly resolved) is a difficult problem that is beyond the capability of most users. Tools such as package managers are required to help determine all of the dependencies and ensure the right libraries are available.
In terms of security, having applications capable of sharing the same linked libraries and having the update process managed externally should yield improved security. However, in order to take full advantage of these updates, an application must not be dependent on a specific version of a third party library. By permitting this flexibility, the application developers can benefit from updates by are taking a risk that a future update to one of these linked libraries could break the stability of their application. As there are no third party compatibility guarantees, an update could change an API or modify the behavior of a utilized feature; this would negatively impact the customer necessitating an application update.
Discussion