Third-party software components are a growing concern among those looking at the security of software. Most of the code used to make a running system isn't written by the developers -- it is based on third-party libraries. Issues surrounding third-party software components have gained prominence in recent years, assisted by the discovery of several critical issues in common frameworks such as Apache Struts and Spring Framework.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Identifying issues associated with vulnerable software components can be done in several ways. Dynamic analysis and penetration testing look at a deployed, running application. If there are vulnerable components that expose weaknesses, then hopefully testing will find it.

In addition, static analysis that includes the entire system can also identify these issues. Note that static analysis that only examines the source code from the development team will likely fall short because it will treat included libraries as black boxes and not be able to subject them to analysis.

A shortcut to identifying potential issues is an analysis of the libraries included in the entire running system. This library analysis includes known vulnerable software components in the system so that analysts can determine if vulnerabilities in the libraries will result in vulnerable behavior from the system as a whole. Commercial vendors have stepped up to provide this analysis, and there is also the excellent and free OWASP Dependency Check tool. This tool looks at included libraries for both Java and .NET platforms and combines an understanding of these libraries with data from the National Vulnerability Database, linking vulnerabilities to the included libraries. This identifies libraries that potentially contain vulnerabilities and are in use in an application.

When dealing with potential vulnerabilities that stem from the use of known vulnerable components, business impact analysis is critical. Just including a component with a known vulnerability doesn't necessarily mean that that vulnerability is exploitable in a particular system. Some vulnerabilities will be exploitable in any system that includes a given library. Other situations will depend on how an application is using the library.

It is important to evaluate how an application is using the library before deciding on what, if any, action to take.

Therefore, in most cases, it is important to evaluate how an application is using the library before deciding on what, if any, action to take. Ideally, applications would always use stable and up-to-date libraries, but sometimes the cost of upgrade -- reworking to deal with API changes, retesting to make sure the behavior hasn't changed -- is not justified.

Now let's look at the security risks associated with using partner APIs. This is especially important for mobile applications. It will become increasingly important as the Internet of Things gains momentum and we see more applications that are actually systems of applications -- some under the control of the application developer and others developed and maintained by third parties. In these cases, it is important to pay close attention to data sent to partners because that data could potentially be disclosed or otherwise misused.

One way to control this is via policy. Determining what can and cannot be sent outside of your organization may limit the functionality you can implement in certain situations, but this can also prevent data breaches. In addition, consumers of third-party services should ask questions such as: What are the terms of service for the third-party API, and what is their privacy policy? Often these policies provide the partner with broad latitude in how they are allowed to treat data and may give them the right to send data along to other entities or countries.

In addition to policy controls, developers can enforce technical controls to audit what is sent to these third-party systems. Static analysis tools employing dataflow analysis of a system can see what information flows through to the partner services. Developers may be surprised by what data ends up where. Also, developers employing third-party services should determine their ability to test the security of those services.

Service providers have a range of attitudes toward testing. Some restrict and even penalize users who test, while other organizations have bug bounty programs that reward parties for reporting issues. In many partnering situations, organizations should be able to negotiate the right to do some testing of the services within some reasonable constraints. Negotiate before you sign a contract because afterward there is limited leverage. In addition, test plans should incorporate ample time for manual testing, as most automated dynamic testing tools have a limited ability to analyze supporting Web services.

Dealing with the security of third-party libraries and third-party services is a critical concern for anyone building modern applications. It is typically impossible to get new applications to market without relying on these third parties, but this reliance also comes with potential critical risks. Smart developers will anticipate these issues and make plans to address them early in the development process.

How has your company tested for third-party application security? What worked well, and what didn't?

1 comment

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy