 The security community received a very powerful and earth-shattering awakening when Heartbleed, a critical security bug in the OpenSSL cryptographic library, was disclosed in 2014. OpenSSL was and continues to be a critical component used to secure data communications within equipment, web servers and hosts of services and applications. This discovery impacted millions of users and businesses worldwide who frantically scrambled to apply patches and updates to their environments, and software and hardware providers who had to review millions of lines of code to replace vulnerable components.  Beyond the critical vulnerability itself were perhaps bigger issues. One was a nearly blind and broad reliance on code developed by a small, critically underfunded team. Another is the simple but flawed belief that if so many used this critical code, it must have been tested, fully validated and free of bugs and other possible problems. While the code was fully visible as an open source initiative for all to review, it wasn’t until a few years after the flaw had been inadvertently introduced in OpenSSL in 2012 that it was discovered by security researchers. Today, as organizations struggle to catch up to ever-increasing demands for new services, new capabilities and better customer facing goodness, teams are looking to leverage and integrate more third-party developed offerings in order to meet tighter deadlines. As these components become fully intertwined with internal systems, it becomes harder to identify individual sources and, more importantly, clearly highlight dependencies and risks from this supply chain. Ultimately, while organizations have many formalized partnerships, there may be many more that are not reviewed and are not part of a centralized procurement. These completely circumvent any security audit or even basic identification. And even approved vendors and technology partners can be exposed to an undocumented supply chain, since they also leverage solutions and code from other third parties in their own hopes to better serve us and do so more quickly. This process is further exacerbated as organizations increasingly look to leverage more cloud-based capabilities and code. Let’s admit from the onset this simple truth: it is a practical impossibility to categorically and exhaustively test and review every single line of code that will ever be introduced in any application or service. This is similar to the alert overload problem most security teams experience in their day-to-day. However, similar to security teams who look at things from a different point of view and are able to tackle a mountain of events using an intelligence-based approach to streamline the process of identifying critical threats, so can we take steps ahead of time to minimize supply chain risk. As a starting point, there are many fewer vendors, partners and third-party sources of code and services than there are lines of code. While documenting these relationships will not be a simple task that can be achieved in a few days, it is a human scale task and it can be improved over time as awareness of the need to document these relationships becomes more prevalent and integrated in various activities. Once these relationships begin to be documented, they can be monitored for issues, reputation, brand and other concerns by scanning for news stories, articles and mentions in forums and other sites about the organization itself, the third parties that are part of their supply chain, their key executives, contributing personnel and more. While this effort can be a tedious undertaking if performed manually, service providers are available that offer this insight. Typically, this is offered as part of a digital threat and brand monitoring service. While most organizations considering these services think of using them for their own organization, brands and key personnel, the visibility can be extended to cover partners, third parties and more.  By combining the visibility from this service with threat intelligence data that closely monitors possible issues with the components deployed in an environment, organizations can develop a full 360-degree view of the potential threat and risk landscape associated with their supply chain. It also offers the basis for a regularly updatable reputation and risks score that can quickly identify possible or burgeoning areas of concern and dependencies before they hit a critical level. This is the only way a scalable approach can be put in place to mitigate and work around potential issues. As organizations become more reliant on components, platforms, services and other elements from third parties to provide critical functionality for their own deployments, they must incorporate a process for monitoring the risks their supply chain represents to their own security programs.		The security community received a very powerful and earth-shattering awakening when Heartbleed, a critical security bug in the OpenSSL cryptographic library, was disclosed in 2014. OpenSSL was and continues to be a critical component used to secure data communications within equipment, web servers and hosts of services and applications.This discovery impacted millions of users and businesses worldwide who frantically scrambled to apply patches and updates to their environments, and software and hardware providers who had to review millions of lines of code to replace vulnerable components. Beyond the critical vulnerability itself were perhaps bigger issues. One was a nearly blind and broad reliance on code developed by a small, critically underfunded team. Another is the simple but flawed belief that if so many used this critical code, it must have been tested, fully validated and free of bugs and other possible problems.While the code was fully visible as an open source initiative for all to review, it wasn’t until a few years after the flaw had been inadvertently introduced in OpenSSL in 2012 that it was discovered by security researchers.Today, as organizations struggle to catch up to ever-increasing demands for new services, new capabilities and better customer facing goodness, teams are looking to leverage and integrate more third-party developed offerings in order to meet tighter deadlines. As these components become fully intertwined with internal systems, it becomes harder to identify individual sources and, more importantly, clearly highlight dependencies and risks from this supply chain.Ultimately, while organizations have many formalized partnerships, there may be many more that are not reviewed and are not part of a centralized procurement. These completely circumvent any security audit or even basic identification.And even approved vendors and technology partners can be exposed to an undocumented supply chain, since they also leverage solutions and code from other third parties in their own hopes to better serve us and do so more quickly. This process is further exacerbated as organizations increasingly look to leverage more cloud-based capabilities and code.What Can We Do?Let’s admit from the onset this simple truth: it is a practical impossibility to categorically and exhaustively test and review every single line of code that will ever be introduced in any application or service. This is similar to the alert overload problem most security teams experience in their day-to-day.However, similar to security teams who look at things from a different point of view and are able to tackle a mountain of events using an intelligence-based approach to streamline the process of identifying critical threats, so can we take steps ahead of time to minimize supply chain risk.As a starting point, there are many fewer vendors, partners and third-party sources of code and services than there are lines of code. While documenting these relationships will not be a simple task that can be achieved in a few days, it is a human scale task and it can be improved over time as awareness of the need to document these relationships becomes more prevalent and integrated in various activities.Once these relationships begin to be documented, they can be monitored for issues, reputation, brand and other concerns by scanning for news stories, articles and mentions in forums and other sites about the organization itself, the third parties that are part of their supply chain, their key executives, contributing personnel and more.While this effort can be a tedious undertaking if performed manually, service providers are available that offer this insight. Typically, this is offered as part of a digital threat and brand monitoring service. While most organizations considering these services think of using them for their own organization, brands and key personnel, the visibility can be extended to cover partners, third parties and more. By combining the visibility from this service with threat intelligence data that closely monitors possible issues with the components deployed in an environment, organizations can develop a full 360-degree view of the potential threat and risk landscape associated with their supply chain. It also offers the basis for a regularly updatable reputation and risks score that can quickly identify possible or burgeoning areas of concern and dependencies before they hit a critical level. This is the only way a scalable approach can be put in place to mitigate and work around potential issues.The Bottom LineAs organizations become more reliant on components, platforms, services and other elements from third parties to provide critical functionality for their own deployments, they must incorporate a process for monitoring the risks their supply chain represents to their own security programs.