Securing Third Party and Open Source Code Components: An Introduction

0


The growing popularity of open source code continues to be a boon to developers in the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be aware of when using open source and commercial code components, as each carries a significant risk of becoming the enemy within, creating a vulnerability in the program it helps. to build.

Sacrifice security for ease of use

While the many benefits of open source have been widely touted, the sheer prevalence of code components (open source and commercial) in all industries is underestimated. CA Veracode recently found that 83% of developers use code components to build web applications, with the average number of components per application being 73.

Considering the fact that the vast majority of developers create applications with code components, the number of those who know the risks of doing so is surprisingly low. Just 52% of organizations reported that they provide security patches to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23% said they tested component vulnerabilities with every release.

Additionally, only 43% of developers said they were aware of industry-accepted OWASP recommendations to prevent the use of components with known vulnerabilities.

Where does the responsibility lie?

One obvious problem with this software development practice is that the responsibility for securing the code seems to lie with everyone and, sometimes, no one. Forty-four percent of those polled said developers are responsible for the ongoing security of code components, while 31 percent said they expect security to handle this task.

This lack of preparation and poor communication leaves the door wide open for bad actors to rush in and take advantage of vulnerabilities that could so easily be fixed.

How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:

  • Start with education: Software development teams must have the tools and training necessary to ensure the security of the code they write. Educating developers about the risks associated with open source and commercial code components is a start, but prioritizing security training and continuing education is the key to long-term success. Bringing on the security team to conduct training for their fellow developers is a good way to embrace peer-to-peer knowledge sharing and break down silos between the two teams.
  • Introduce clear processes: To avoid communication issues and confusion, organizations should implement clear processes for developing secure software. Knowing what an app is made of is the first step because teams can’t secure what they don’t understand. It may sound obvious, but CA Veracode has found that only half (53%) of organizations maintain a component inventory. Code components must be carefully vetted before they are integrated into an application and then added to a working inventory. Managers need to make sure that every part of the maintenance process has a clear owner on the team so that accountability is always clear. Consistent testing and patching is also best security practice.
  • Drive innovation with DevSecOps: It all comes down to integrating security into the entire Software Development Lifecycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to distribute secure code. Development, operations, and security teams each make their own unique and critical contribution to the software development process, and the combination of their strengths will result in the best possible product.

While taking the time to secure applications from the dangers of code components can slow development in the short term, protecting your organization and its software assets is invaluable in the long term.

– Pete Chestna


Share.

Comments are closed.