For any enterprise, what they never want is to find themselves in a situation where they don’t know where the code they are running is coming from. "Dependency chain is a big deal. Is this an enormous pain? Yes, without question. There are tools that will help with this, and admitting you have a problem is the first step," said Borohovski.
A wide range of tools can address these problems in both reactive and proactive ways, but Borohovski said, "Focus on the third-party software as if it were something you wrote. Test for vulnerabilities much like you would any other code that you wrote. Third party that’s open source or from other vendors—tracking solution or anything like that—are a potential surface area for vulnerabilities."
Chris Weber, co-founder of Casaba Security, said that it usually takes something breaking before somebody sees it. "The entire dependency chain with third-party code can become a dangerous proposition and the dependency chains can become quite large," Weber said. Some dependency chains become un-maintained as they can quickly branch out exponentially.
Often times with third-party code, they don’t understand the internals, but with the code they write, they understand it, so they have better visibility into their own code, so it's a good habit for the enterprise to evaluate their use case and requirement for that code, said Weber.
"Any time you take a dependency from a third party, you’ve given up some control of your application," Weber continued. Rather than abdicate that control, it is better to ask, "Do we really need this? How long will it take us to build?"
Understanding that security has no perimeters requires training and a shift in culture. Finding issues in both the first- and third-party code is not a singular act. Security is an ongoing process, and one that needs to be at the forefront of everyone's mind from the architects to the end users.
Sign up for Computerworld eNewsletters.