rvlsoft - Fotolia

Manage Learn to apply best practices and optimize your operations.

How do you secure software components and partner APIs?

As our developers incorporate more and more third-party software components and partner APIs that we don't have direct control over, how do we test for third-party application security?

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.

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.

Next Steps

Testing, assessment methods offer third-party software security assurance

Third-party application security evaluation tools and services

Should third-party software tools be used to customize applications?

What to expect of a third-party Web application security tester

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How has your company tested for third-party application security? What worked well, and what didn't?
I would add that the onus is on developers to learn secure design patterns. Also, when you interface to third party _systems_ (as opposed to embedded components), it is essential to monitor the traffic because you have no control over the security policies of those third party systems.