This article was originally published in Security Boulevard powered by Techstrong Group | By Sue Pombra
Organizations rely heavily on third-party vendors and contractors. Smart companies will have a service level agreement (SLA) with each vendor which includes information about the vendor’s approach to cybersecurity—in fact, it’s a best practice to add security to the software supply chain.
If only it was that simple. In the real world, the vendor supply chain is more like a train. The engine (your company) is leading the way along the tracks, but the further away you get from the engine, the less control you have and yet, if one of those cars near the back derails, it impacts the entire train. Your vendor has vendors who have vendors who have vendors . . . and so on. And if one of those vendors, four or five degrees separated from your company, is using open source software with a vulnerability, it could end up causing a lot of problems for your business.
How Your Vendor’s Vendors Cause Problems
Using contractors is commonplace. Most mature organizations do have systems in place to manage their direct supplier relationships, but getting a clear picture of who your suppliers rely on to provide services is much harder.
“Understanding what systems are being used and where client data is hosted and processed is also challenging,” said Anders Lillevik, CEO of Focal Point, in an email interview. “Companies may have a clear understanding of how direct suppliers are expected to handle data security, but the challenge is knowing how these direct suppliers are managing their own suppliers.”
The threat, said Lillevik, lies in the unknown. “Where companies lack visibility into these companies and their suppliers’ suppliers with whom they do not have a direct relationship, they therefore do not have audit rights or even communication.”
It gets more complicated when you add open source software into the mix. While the open source ecosystem offers a wide range of beneficial projects, explained Michael Skelton, senior director of security operations at Bugcrowd, it is crucial to remember that these contributions are often voluntary. This can result in a lack of formalized support, project maintenance and documentation compared to corporate offerings.
“Additionally, open source projects may not always undergo thorough security reviews or provide dependency manifests,” said Skelton. “These risks can propagate through the vendor supply chain, potentially causing security vulnerabilities in products that rely on these open source components.”
Finding Open Source Vulnerabilities Hidden in the Vendor Supply Chain
Identifying open source vulnerabilities in the vendor supply chain is not easy. Skelton recommends organizations conduct a comprehensive security audit, including a review of open and historical issues, before adopting any open source project. This review process should also take into account the dependencies that these projects rely on.
“For example, the Log4j vulnerability impacted organizations that had already taken remediation steps and issued patches for their products,” said Skelton. “However, downstream dependencies sometimes incorporated vulnerable open source libraries, leading to vulnerabilities in offerings that depended on them.”
But who, and at what point along an extensive supply chain, should be in charge of monitoring for potential open source vulnerabilities?
This is a non-trivial question, said Mike Parkin, senior technical engineer at Vulcan Cyber, and it has led to some serious debates.
“Each vendor is ultimately responsible for what they release, and that includes the product’s security,” said Parkin. “The teams that develop and maintain open source applications and libraries traditionally put a lot of effort into keeping their code secure and bug-free, but these libraries are normally offered as-is, no warranty express or implied.”
Building a Partnership With Vendors You Don’t See
SLAs usually only cover direct vendors, but it is vital for organizations to find ways to address potential open source security issues coming from fourth- or fifth-line vendors. It starts with companies implementing robust vendor management practices, including due diligence and security assessments. Thanks to executive orders from the White House and CISA directives, software bills of materials (SBOM) will play an important role in addressing open source security throughout the entire supply chain. Organizations shouldn’t hesitate to ask all vendors, direct or indirect, to disclose their use of open source code and provide an SBOM to identify potential vulnerabilities and dependencies.
Within critical infrastructure, processes or data hubs ensure organizations can follow the client delivery chain from beginning to end to know which companies are part of the process, what they do and where this work is being done, said Lillevik. This process and data mapping takes time and effort, but it provides companies with greater visibility and a clearer understanding of the complexity of the processes and who is involved.
“Once organizations know the players involved,” Lillevik added, “they can investigate the legal protections that are in place, what their security posture is and what the potential risks are.”
