Why CISOs Need to Ask Questions About Third-Party Code

News broke recently regarding the breach of a website owned and operated by the Small Business Administrator in which the personal data of around 8,000 business owners was exposed. At this time, it appears that a bug within the website allowed access to a range of data, including social security numbers, financial information, email addresses, physical addresses and phone numbers. 

The reality is that most modern websites today are extremely complex, often containing many thousands of lines of code and as such, bugs will exist. While most bugs will be benign, affecting areas such as user experience or visualization, some can result in serious flaws that enable the exposure of an organization's customer data. 

CISOs are responsible 

The primary job of a CISO is to ensure the security of an organization's assets and to put technologies and procedures in place to facilitate this function. There have been many examples where CISOs have been held responsible for breaches that have occurred, even when they might not have been directly involved. 

Oftentimes, CISOs will avoid getting into the weeds with respect to projects, for example, assuming that existing QA processes are adequate at detecting code issues. While a certain element of trust between a CISO and the development team is expected and required, CISOs need to be mindful of certain details and ask relevant questions.

The good and the bad of code sharing 

Open source and third-party code are integral to the development of many products today and if you ask any developer to create a feature, they will usually first look for available libraries or components. While some of this code comes from reputable organizations, such as Google and Facebook, some of it can be the side project of hobbyists or the product of a college thesis. 

Even popular and well-known projects are often created by dispersed teams of largely unknown individuals from many different places around the world, all whom, in theory, have the ability to make code changes with the potential to cause harm to any organization making use of them. 

A strong example of this took place in 2018 when a Node library known as event-stream was infected with cryptoming code. It turns out that the library, which was at the time downloaded over two million times weekly, changed developer ownership with the new owner later adding the malicious code. For organizations utilizing the library, however, knowledge of the ownership change was probably unknown and the developers themselves had not been validated. 

Trust (but verify) what the development team chooses to use 

While an organization's development team is often (and should be) trusted to make good choices in terms of the technologies they use, CISOs should get into a habit of verifying the choices. Engineers for example will often hit code repositories, inspect usage licenses and may even check bug reports to ensure good support, but they likely will not conduct any research into ownership or entities involved. 

CISOs need to involve themselves in the development cycle and ask important questions, such as where the open source library developers are located, could entities like state-sponsored threat actors be involved, are there possibilities of competitors inserting features that give them an advantage or even, could criminals manage to inflict influence for nefarious means. 

Unfortunately, unless an organization reviews every single line of code present in the libraries which they use, a task which in most cases is not possible, then the usage of third-party code is always going to present a potential attack surface risk. With this in mind, the role of a CISO must also be one of mitigating potential breaches as a result of unforeseen bugs. 

Therefore, they should trust that their development team produces good, stable and secure products, but take a view that a breach may happen at some point – if not directly against the organizations infrastructure, then against one of the systems that the organization makes use of – and CISOs need to consider what they can do to mitigate the effects of such an event. 

Mitigating the effects of breaches resulting from third-party code 

Most attacks that are introduced by using third-party libraries are largely impossible to prevent without intimate knowledge of the component code. 

Ensighten enables organizations to prevent a range of online attacks by providing technology that allows filters to be placed within a website. These filters ensure that any data accessed by code, whether first, third or even further down the website supply chain, can only be sent to trusted destinations. Should a third-party component contain malicious code, the code would not only be blocked from stealing user data, but the organization would also be alerted to its presence. 

Our technologists will work with organizations and identify areas of potential concern, regardless of whether they use our technology or not, with no obligation. With online attacks growing in both complexity and frequency, we are happy to talk to businesses if for nothing more than to help educate them on the risks. Get in contact to book a demo and see our solution in action.