In today’s world of agile software development and fast release cycles, developers increasingly rely on third-party libraries and components to get the job done. Since many of those libraries come from long-running, open-source projects, developers often assume they’re getting well-written, bug-free code. They’re wrong.
The major patching efforts triggered by the Heartbleed, Shellshock and POODLE flaws this year serve as examples of the effect of critical vulnerabilities in third-party code. The flaws affected software that runs on servers, desktop computers, mobile devices and hardware appliances, affecting millions of consumers and businesses.
However, these highly publicized vulnerabilities were not isolated incidents. Similar flaws have been found in libraries such as OpenSSL, LibTIFF, libpng, OpenJPEG, FFmpeg, Libav and countless others, and these have made their way into thousands of products over the years.
Among the reasons why these bugs end up in finished products is a belief by developers that the third-party code they choose to integrate is secure because it has already been used by many others.