Survey: Third-Party Code Proves Vulnerable
A recent survey of 307 IT professionals conducted Osterman Research on behalf of PerimeterX, a provider of cybersecurity tools for web applications, suggests there’s a lot of third-party code running on websites that no one can say with any certainty is truly secure.
The survey finds less a third (31%) of respondents have addressed all the vulnerabilities in the third-party scripts running on their websites and only 11% said they believe they have complete insight into the third-party scripts on their website. Less than 2 in 5 respondents said they could assure their management that their sites are secure and compliant with appropriate regulations.
Kim DeCarlis, chief marketing officer for PerimeterX, said as much as 50% to 70% of the code running on a website is likely to have been created by a third party. Nearly 90% of respondents said they believe that there is only little to moderate risk from these scripts, and yet, more than one-third (36%) of those surveyed reported that their websites had been hacked or attacked in the past. A full 70% said they believe that website decision-makers certainly would be fired if a major data breach occurred because they relied on third-party code that had not been vetted.
DeCarlis said it’s apparent there is a significant amount of cognitive dissonance surrounding the risks associated with relying on third-party code on websites. Far too many organizations are taking it as an article of faith that third-party developers are proactively addressing vulnerabilities. However, even when third-party developers are staying on top of vulnerabilities that get discovered after code is deployed, it might be weeks or months before the vulnerable code is patched or replaced.
Cybersecurity professionals are expected to run scans to discover vulnerable code. The challenge they encounter is, even when they do discover that vulnerability, they may not be able to dictate how quickly that vulnerability should be remediated. That often puts organizations in the unenviable position of having to run code on their website that they know could be exploited.
It’s not feasible for most organizations to write all their own code. Third-party developers who have created reusable scripts and frameworks for performing specific tasks are an indispensable part of the software supply chain. Nevertheless, it’s also apparent more needs to be done to secure the software supply chain. After all, beyond the risk associated with incurring various fines, most end users today typically evaluate organizations based mainly on the robustness of the web experience provided. If it turns out that a website has been compromised and turned into a distribution hub for stealing credentials and distributing malware, it won’t be long before customers move on.
No one can say with certainty how pervasive a problem code security really is. It is clear there is a rising need to extend best DevSecOps processes across a range of third-party developers. That may take some convincing based on the number of organizations a third-party developer may be trying to support. However, if all the organizations relying on that code encounter the same cybersecurity issues, it’s only a matter of time before the vulnerabilities discovered become a much higher priority for all concerned.
