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.
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.
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.
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 Software Security Test Best Practices
Dan Cornell asks:
How has your company tested for third-party application security? What worked well, and what didn't?
0 ResponsesJoin the Discussion
Related Q&A from Dan Cornell
Is it safe to move from on-premises application lifecycle management tools to cloud-based tools? Read this expert answer to find out.continue reading
Can security impact application performance? What security vulnerabilities might be slowing us down?continue reading
Software systems security expert Dan Cornell discusses the challenges and processes that come with the integration in smart process applications.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.