Envestnet

Have you ever really thought about how software gets built? Many of us envision a team of software engineers and architects furiously working to develop features to be released to clients at a rapid pace. While this is mostly accurate, the reality is that these developers and architects are pulling in libraries and components from multiple locations to add to their own custom code in order to build a more robust product. These components and libraries are called “dependencies” because your software is dependent on them to function as expected.

This is where a software supply chain comes into the picture. Although the term “software supply chain” can mean the full set of services and software being used, down on the lower levels of development there is a complex set of dependencies that are used to build specialization in the software. If you need help developing an authentication function for your Node.js application, leverage an authentication module that will provide you with the hooks to authenticate with Google or Facebook. Need to integrate an email function into your application? You can simply integrate an SMTP module to manage email transactions. Yes, you can develop these features yourself, but if the component already exists, there is no sense in reinventing the wheel. Especially with deadlines looming.

Although this is a powerful and quick way to get features developed and into the hands of clients, it creates software soup that quickly becomes muddled which offers up opportunities for attackers to compromise a single dependency as opposed to the broader application. Furthermore, without the proper oversight for ensuring that the dependencies are free from vulnerabilities and are well maintained by the vendor, the application can be vulnerable without the organization being aware. This often leaves the organization scrambling to determine what their exposure is when a zero-day is announced, or a new vulnerability makes the headlines.

Although the term “software supply chain” can mean the full set of services and software being used, down on the lower levels of development there is a complex set of dependencies that are used to build specialization in the software

The issues with the software supply chain have been evident in multiple attacks over the years. Probably no more so than with the attack on SolarWinds in 2020 in which case attackers were capable of injecting a malicious DLL (Dynamic Link Library) that was then sent to thousands of SolarWinds customers. The attackers were able to hide their tracks for months before being discovered. Although the overall impact was small, it was one of the most high-profile supply chain attacks and put many organizations on the defense. More recent attacks on the supply chain manifested in Okta’s breach in December of 2022 where attackers were able to gain access to Okta’s GitHub code repositories. No doubt this access could Okta’s source code.

To address these types of concerns at the national level, the White House in the year 2021 issued an executive order called the Executive Order on Improving the Nation’s Cybersecurity. In this EO the White House focused on the supply chain and how software is managed, acquired, deployed, and used by federal departments and agencies. Specifically, it requires the software purchaser (in this case the federal agency) to ensure that the software producer has followed a risk-based approach to secure their software. This allows the software purchaser to make a well-informed decision about the software they are about to procure. Although this EO only addresses federal entities, this type of requirement is quickly becoming a de facto standard for other non-government entities. Those of us that work in an application or product security are no strangers to being pressed on our processes for ensuring the software we deliver is free from risk and vulnerabilities.

You may find yourself as one of the organizations needing to attest to the security of your software or are simply looking to secure your software dependencies. Here are some simple steps to consider:

 • Ensure that the dependencies you are using are from a reputable source and are well maintained. Ideally, the source will be able to provide notifications in the event that the component they are offering becomes compromised.

• Build an inventory of the software and the dependencies you have in-house. Additionally, have the ability to dynamically update the inventory as new software is developed. Often you can find support for this in the source code manager (SCM) that you use, or you can use a third-party tool to track and manage your dependencies.

• Have a process for monitoring for new vulnerabilities that can impact your software and the dependencies. This can be done through services that monitor the NVD (National Vulnerability Database), or through your chosen tool in the previous step.

• Have a process to patch, test, and deploy new dependencies as they become available. When new vulnerabilities are released in these dependencies, oftentimes the remediation is to upgrade to the newest version of the software. Attackers can move rapidly to take advantage of a newly released vulnerability. Often exploit code is available within hours of public disclosure. For an organization that cannot patch and deploy for days or weeks, this can spell trouble.

• Have a process to replace components that are abandoned or sunset by their developer. Much like the software you create, other components will have a shelf life that needs to be considered by the consuming organization.

Whether you are using a tool to manage and monitor your dependencies, being able to address security in the software supply chain requires quick detection and remediation to reduce the risk and exposure to your organization.