There's pressure out there — and the best application developers understand it. Not only do they need to push out their projects fast and at a low cost, but they've got stiff competition from other developers and development shops. Third-party applications and libraries can speed up a developer's work by allowing him or her to use already built pieces rather than reinventing the wheel every time a specific feature or function is required. But these same building blocks introduce more risk because a single vulnerability can put many different applications at risk. Is it a risk worth taking?
In today's fast-paced IT world, each new version of software must top the last — and speeding up app development means using software libraries such as OpenSSL, which improve efficiency in the development process by enabling the faster creation of portals and other client-facing apps. In April 2014, everyone became extremely familiar with OpenSSL for all the wrong reasons thanks to Heartbleed, a security vulnerability that could enable an attacker to expose sensitive data. This vulnerability was found in millions of web servers built using certain versions of OpenSSL, and the subsequent headlines brought this third-party security issue to the forefront of international news.
Shellshock, a dramatically named vulnerability in Bash (the default shell for OS X and Linux, which is also often installed on Windows-based devices), debuted in the fall as a sequel to Heartbleed. Again, vulnerabilities affecting third-party components caused a wave of panic as developers and security experts rushed to determine if affected versions were in thier code. However Bash and OpenSSL are far from the only software components that have — or could have — neglected updates or patches. According to Threatpost, "Hundreds of open- and closed-source libraries are used, each with their own set of issues that often aren't updated or patched with any consistency."
There's no denying it: just like all software, third-party applications and libraries will have inherent vulnerabilities as more people use them and find exploitable flaws in their design and development. So, how should developers approach these risks?
When third-party components are used in a development project, they frequently include more code than required for the software's purpose. A single app can use dozens of third-party software libraries. Developers looking to ensure the resiliency of their applications must implement security testing in the development process. With a continual series of tests, development teams can ensure each change does not introduce vulnerabilities even when third-party components are added.
With all the potential hazards involved with using third-party software, is it ultimately worth it? Yes, but only if your team approaches everything with security and functionality in mind. No matter where code is developed, it requires the same meticulous security testing to ensure it meets an organization's requirements. If any element is ignored, your team could be partially responsible for the next terrible breach — or just for producing low-quality software that doesn't live up to a client's standards. But by testing early and often, you can consistently deliver the sterling software on which your reputation (and the reputation of your client) depends.
Photo Source: Flickr