“Threat actors don’t have to defeat a company’s security measures, they only have to compromise a third-party supplier that it works with or relies on.” CSOonline
That seems to be the case with a new wave of software supply chain security breaches. For example, a destructive malware called “NotPetya” was deployed using a legitimate software package employed by organizations operating in the Ukraine. The attack was perpetrated using a mechanism to provide updates distributed by that vendor to their customers. In another attack, hundreds of thousands of computers were infected by a deliberately corrupted version of a free security software utility, CCleaner. Similarly, another group of hackers added deliberately corrupted Python libraries of Python’s public package repository, which were unknowingly incorporated into applications by thousands of Python programmers.
These types of attacks are not new, but the frequency with which they have been taking place are cause for renewed concern.
According to a technical note from The Software Engineering Institute, software supply chain security risk exists at any point where organizations have direct or indirect access to the final product or system through their contributions as a supplier. Security risks can be introduced into the supply chain in several ways:
- coding and design defects incorporated during development that allow the introduction of code by unauthorized parties when the product or system is fielded. In addition, there are those defects that compromise security directly by allowing unauthorized access and execution of protected functionality.
- improper control of access to a product or system when it is transferred between organizations (failures in logistics), allowing the introduction of code by unauthorized parties.
- insecure deployed configuration (e.g., a deployed configuration that uses default passwords).
- operational changes in the use of the fielded product or system that introduce security risks or configuration changes that allow security compromises (configuration control and patch management).
- mishandling of information during product or system disposal that compromises the security of current operations and future products or systems.
Most developers build modern software applications with a combination of public software libraries and custom code. According to an article in Forbes magazine, the average web application has hundreds of these libraries, which are comprised of tens of millions of lines of code. The vast majority of these libraries come in the form of freely available software that can be downloaded from the internet.
The Software Engineering Institute points out that supply chain security risks will remain a growing concern as outsourcing and expanded use of commercial off-the-shelf (COTS) and open source software products increase and end users exploit opportunities to reconfigure or make limited additions to deployed products and systems. Common software defects can be readily exploited by unauthorized parties to alter the security properties and functionality of the software for malicious intent. Such defects can be accidentally or intentionally inserted into the software at any point in its development or use, and subsequent acquirers and users have limited ways of finding and correcting these defects to avoid exploitation.
Because it is so important for developers to fully understand all of the public libraries they may be using in conjunction with their own custom code, Wibu-Systems maintains complete transparency of the open source software components and versions that we integrate into our CodeMeter protection and licensing tools. That way, both ISVs and end users can monitor for any new issues that may arise with these components and address them quickly.
