Software Supply Chain Security Risks, Part 1
It cannot be stated enough that software supply chain security risks are serious as organizations are so dependent on the software supply chain, an attack could cripple their business. The effects of the Log4j vulnerability continue to be felt as it spreads through the supply chain, all but assuring that more threats will emerge. Further, open source is increasingly being used in development projects.
The issue has become so concerning that Gartner has predicted that 45% of organizations worldwide will have experienced attacks on their software supply chains by 2025, a three-fold increase from 2021.
Here is a look at six software supply chain security risks organizations face in part one of a two-part series on what you need to know.
Risk: Vulnerabilities in Code
Developers are an integral part of the software supply chain since they use code to build their apps. They also use APIs to enable different services to interact with one another. To protect code from vulnerabilities, they should use secret management (the practice of storing sensitive data in a secure environment with strict access controls) and tools capable of flagging harmful security flaws in code and configurations.
They also need visibility into all artifacts used in the third-party supply chain infrastructure, such as open source and software libraries, which makes the use of an SBOM critically important.
Risk: Third-Party Dependencies
Today’s software ecosystem is comprised of third-party vendors, partners, and service providers. There are a multitude of dependencies that subject code to risk, from running apps on cloud instances and utilizing commercial libraries and frameworks to using services to streamline software availability.
Having the ability to understand third-party risk and applying cybersecurity supply chain risk management processes are essential to gain a comprehensive understanding of your dependencies. This includes knowing what third parties have access privileges to your code. By managing these risks, you can potentially avoid the types of software supply chain attacks companies like SolarWinds, Kaseya, Atlassian, and Mimecast, to name a few, all experienced in recent years.
Risk: Gaps in Change Management Databases
Organizations typically do not connect or track their third-party suppliers in change management databases, so consequently, they cannot proactively respond to supply chain vulnerabilities. This type of gap can potentially limit an organization’s ability to proactively respond to major vulnerabilities in the supply chain.
Risk: Distribution Systems
In addition to code repositories, use of public-facing distribution systems makes it easy to download new versions of apps and services. Sites like Softpedia and FileHippo are commonly used for software distribution, along with app store. But these distribution systems could be compromised by hackers that can install backdoors to enable the ability to infiltrate your software environment. Developers should carefully vet where they source their software careful from.
Risk: Public Repositories
Free and open-source code comprises as much as 70% to 90% of modern software. Public repositories are ideal for making code from various open-source projects available to everyone online, but they carry significant software supply chain risks.
One concerning attack technique is typosquatting, a type of social engineering threat actors use to impersonate legitimate domains to write malicious code. They do this by registering domain names that are similar to actual ones that may include a slight misspelling, or adding a period to the URL, for example. However, when developers download a typosquatted package, they unwittingly introduce malware into their code.
Risk: Build Tools
Continuous integration and continuous delivery (CI/CD) are used in today’s software development workflows so developers can automate, become more efficient, and create more innovative apps. Code repositories, containers, and build servers are all integral to CI/CD pipelines—but they also have the potential to become compromised. Besides continuous security testing, practicing other software security measures is paramount and should always take precedence over automation and innovation. Organizations should also adopt Infrastructure-as-Code (IaC) and Policy-as-Code (PaC).
Part two will examine other software supply chain risks.