May 31 · 4 min read
Your CI/CD security is only as strong as its weakest link. An overlooked part of the CI/CD pipeline can be just the one that poses a security risk. For many organizations, one such overlooked area within the CI/CD process is dependencies. The recent SolarWinds supply chain attack has put the spotlight on these types of attacks, and rightly so.
In this post we look at dependency confusion attacks and how to secure your CI/CD pipeline against them.
Part of developing with any programming language is to trust its public code repository. Node package manager, Python PiPy, and Ruby Gems are examples of public repository stores. Developers frequently download packages from these repositories using a simple command like npm or pip followed by the name of the repository. The ease of executing these commands and the fact that they’re coming from a very popular source make them look perfectly safe. However, this is precisely where security is compromised. Being a publicly available repository, the packages here are uploaded by unknown developers and open source communities. There are no security guarantees associated with these packages. Some developers and communities may have basic security measures, and may be quick to fix any security vulnerabilities. However, most repositories would contain known or unknown risks that you automatically take on when you use them.
Attackers are well aware of the opportunities these repositories present and are quick to launch an attack. Typosquatting is a well-known example of how attackers try to exploit this weakness. They create and upload a repository that is a misspelling of another package. Since developers type in the name of the repository they want to install, they would often misspell the name, and end up installing the one with the typo. Another way attackers try to gain entry is to upload dependencies that no longer exist. This is how dependency confusion attacks happen.
There are many instances of attackers gaining access to a machine remotely using this form of attack. Many organizations have been victims of this attack. Alex Birsan details how he used this method to breach the security of multiple high profile organizations like Apple and Microsoft, and received handsome bug bounties for his ethical hacking.
The package management services further complicate things. For example, if there are two packages with the same name, the package manager would install the one with the higher version number. This is only when using an argument like ‘’–extra-index-url’ in pip. Hackers can simply name their package as ‘library 9000.0.0’ and become the preferred package in many instances.
Organizations are tight-lipped about how they handle dependency confusion attacks. Indeed, it can be embarrassing for a high tech firm, or a company that handles sensitive information to admit they’ve dropped the ball in such a seemingly obvious way.
Preventing these attacks takes a modern type of security tooling. One that can read the contents of a package, understand its origins, and be able to sniff out an impostor.
As a rule of thumb, no external package should be trusted as is. Additionally, every package should go through a scanner before it is allowed to be installed
Modern container security scanners Quay are an example of this approach. You can configure them so that container images only from a trusted private repository are allowed. Additionally, they scan every container image to check for CVEs (Common Vulnerabilities and Exposures).
When upgrading packages, dependencies get updated too. In these cases, it’s easy for modified dependencies to slip through the cracks. A security scanner that can spot these modified dependencies is crucial. If any suspicious changes are spotted this should automatically result in the upgrade getting aborted.
jFrog Artifactory calls itself the first ‘Universal Repository Manager.’ It hosts packages, container images, and Helm charts all in one place. While this is convenient, it shows how wide the attack vector is for dependency confusion. As we modernize the supply chain, we’re looking for ways to move faster, and centralize repositories. This move makes us more vulnerable to dependency confusion.
While consolidating operations is convenient, it is necessary to implement customized security protocols for each repository and artifactory, and control the private and public packages differently on each repository. This is easier said than done, and requires a policy-based approach to security.
By understanding the various risks you’re exposed to when you use a package repository, and taking the steps to protect yourself from each of them, you can ensure better supply chain security. Your developers can work on install packages in confidence, and your Ops team can rest assured they won’t be in for any surprises later.
Argon Security helps automates the enforcement of security protocols across the CI/CD pipeline stages and tools, enabling development teams to take full advantage of such tools’ benefits and focus fully on delivering the best software without compromising security.
jFrog, Artifactory, Repository, Dependency Confusion, DevOps, DevSecOps
Hardly a week goes by these days without hearing about a new supply chain attack. A recent headline featured yet…
The relevance of DevSecOps has grown in the past years as companies solidify their move towards automating their software delivery…
What is Jenkins and it’s Logo about? Jenkins is the most widely-used CI/CD tool today. As the world moves from…