A Sonatype survey highlighted just how much modern software uses recycled, open source code, much of which contains known security flaws. I know my organization uses recycled code, so I'm very wary of the security implications. Any advice on how to spot insecure code and possibly replace it? Are there third-party services that can perform such tasks?
Ask the Expert
Have an enterprise application security or platform security question for expert Michael Cobb? Submit your question now via email. (All questions are anonymous.)
The use of vulnerable third-party components and code in new applications has become such a major security issue that it appears in the latest Open Web Application Security Project (OWASP) Top 10 list of application vulnerabilities. In previous versions, it was included in the more generic Security Misconfiguration entry, but the problem has become so widespread that Using Components with Known Vulnerabilities is now a separate category.
The results from Sonatype's annual Open Source Software Development Survey provide good insight into why the use of recycled code is leading to so many vulnerable applications. In this report, the vast majority of the 3,500 developers, managers and architects interviewed stated that their applications were at least 80% open source and 20% custom components and code. But that's not where the problem lies. It lies in the revelation that 76% of large organizations have no control over which components are used in their software development projects, and that 65% don't maintain an inventory of the components used in production applications. On top of that, more than half of large organizations admitted that developers don't focus on security. Combine all of these aspects, and it's obvious why OWASP flagged code reuse as a major vulnerability in the application development process.
To improve the management of open source and third-party code development, teams need to create and maintain an up-to-date list of all code used, including all dependencies and sources. Additionally, each source should have a designated point person to track the relevant mailing lists and updates. These tasks can be more easily managed by a repository manager tool -- a central point for the management of software components and their dependencies for use in development, deployment and provisioning. A repository manager can also help enforce policies regarding code reuse.
Only components that have been reviewed and meet the required standards should be allowed in the repository, and developers should be able to use only these approved components for their projects. Repository management products, such as Nexus from Sonatype or Stash from Atlassian, help integrate component lifecycle management into the application development lifecycle. They also provide an inventory of the components in internal repositories and production applications, and proactively alert managers to newly discovered vulnerabilities, making the ongoing monitoring of production applications easier.
While having a repository manager simplifies component and code management, projects still need to be run with a policy in place to regulate code reuse and prevent confusion over who is responsible for open source governance. An emergency response plan is also vital to provide a rapid reaction to any critical patch releases for components in use. Vulnerabilities found in open source components, frameworks and libraries are rapidly exploited by hackers, as they can automate their attacks, knowing that any application built using the flawed code will be vulnerable until a patch is released and installed.
The benefits of using open source code will almost always outweigh the cost of the time and resources required to develop something similar from scratch. The downside is that a process has to be put in place to ensure all third-party code is vetted and kept up to date. It's no longer safe to just let DevOps choose the components that they want for a project.
This was first published in November 2013