The Risks Associated with Third-Party Software Components

I was recently contacted by a colleague in an information security leadership position who was concerned about his developers using some third-party plug-ins for an enterprise application they were rolling out. His developers wanted to install these third-party components in order to speed up their development work. Sounds like a reasonable thing to do.

However, the developers informed my colleague that this code would have to be installed on production servers in order for the system to execute properly. The plug-ins were are all from independent software vendors that my colleague (nor I) had ever heard of. My colleague wanted to get my opinion on the security of these products and whether or not going down this path was too big a risk to take.

Given what was at stake, this was a complicated question to answer. I told him I wouldn’t be able to speak to the security or overall quality of these particular software packages without analyzing them myself but did provide some questions for him and his team to ponder – some things you’ll want to consider as well when the needed arises:

• Could the code be placed in a development or test environment and checked for security flaws before it goes into production?
• Are the plug-ins going to be publicly-accessible?
• Have any vulnerabilities been listed in the CVE dictionary or an exploit database?
• Can you test the third-party modules once they’re in place? What recourse do you have if a security flaw is found?
• If something is exploited, what’s the worst that can happen? What sensitive information (if any) could be exposed? What systems could be taken offline?

At the end of the day, business needs to get done. Whether you’re a developer or an information security professional in a decision-making position, you have to look at the big picture. Based on the answers to the questions above (and others necessary for your situation) you have to determine what’s worse: some confirmed or perceived security risks or not deploying the code at all, thus delaying the roll-out of a new business system.

Situations like this one are why I recommend getting management, including those outside of IT, involved in these types of decisions. It’s up to you as the technical expert to present management with the facts and then step aside and let them make the call based on their risk tolerance and business needs.

THE AUTHOR

Kevin Beaver

LinkedIn

Kevin Beaver, CISSP is an independent information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC. With over 32 years in IT and 26 years in security, Kevin specializes in vulnerability and penetration testing, security program reviews, and virtual CISO consulting work to help businesses uncheck the boxes that keep creating a false sense of security.