Introduction
Due to the way recent technology has been developed, software supply chain attacks are a serious security threat. As with industrial supply chains, the software supply chain includes planning, material procurement, production, and distribution. Rather than physical commodities, the software supply chain is based on code. While some of this code is confidential, an increasing percentage is obtained from commercial or open-source. These dependencies may be exploited to inject malware into the program. Software is developed using code, and in today's software supply chain, the development includes an ever-increasing number of procedures, which may be exploited for efficient malware distribution.
Before we discuss the details, it's important to manage software packages to eliminate those threats, therefore it's important to use a package manager service such as packagecloud. Packagecloud can store all of your packages in one location, giving you complete control over the programs you use. Instead of utilizing public repositories, you can ensure that packages are always pulled from a controlled environment.
You can utilize packagecloud to ensure the complete security of your packages and software supply chain. You should register for a free trial of packagecloud here.
What is software supply chain security?
Harmful actors may hack a centralized or decentralized source of third-party software components with the intent of adding malicious code directly or indirectly through a dependency tree restriction. Software supply chain assaults are not new, nor are they uncommon. Software development has shifted away from engineers developing functionality separately and toward combining private and open-source code to keep up with the rapid pace of development.
A code repository today looks completely different than it did five years ago. It will almost certainly contain not only your proprietary code but also various pieces of open source code such as open-source packages, containers, infrastructure as code, and most likely also build configurations. Each connection in this contemporary software supply chain is a possible attack vector to compromise a wide variety of companies in a single assault.
Package Protection
You can utilize restricted scopes to safeguard your packages. Certain package managers provide scopes, namespaces, and prefixes that may be managed. The specifics differ per environment, but the goal is to safeguard a diverse set of package names. These may be used in combination with packages controlled by you to prevent an attacker from publicly claiming a name you use confidentially or to ensure users that your team released public packages. One of the examples of these attacks is Dependency Confusion which is discussed below.
Dependency Confusion
Dependency confusion leads to malware activation inside an organization's network by substituting dangerous, public packages with the same name for privately-used ones. As part of the software supply chain, developers use package managers and build tools to pull in different open source packages automatically. If the development environment is not set correctly to import these packages from the organization's private registry, packages with the same name may be imported from a public code repository.
This loophole provides a perfect opportunity for attackers - all they have to do is search an organization's public repository for private package names and then upload a malicious package with the same name to a public registry such as npm or PyPi. The misconfigurations and automated build procedures will cover the rest, bringing in malicious packages rather than the ones generated inside.
Defending against threats of dependency confusion
As anticipated, the dependency confusion assault resulted in copycat attacks against other businesses' software supply chains. The following are some precautions to take to guarantee your protection:
Use a scoped namespace - npmjs, one of the attack's sensitive ecosystems, supports package scopes. The usage of "scoped packages" restricts the package's namespace and associates it with a certain user/organization. This negates the dependency confusion attack since no underlying package is substituted for the user's original purpose, and an alternative upstream repository is used.
Our suggestion for utilizing restricted scopes as a mitigating approach is as follows:
Using npm:
By combining a scope prefix with registry settings, you may define the source of each package. Since only one registry will be examined, this prevents replacement attacks through the public registry. These parameters may be adjusted using an npmrc file for each project or the whole computer. Similar settings are available for Yarn through the.yarnrc.yml file.
Using scopes for Internal Packages
A "scope" is a @-prefixed name that appears at the beginning of a package name in npm. @packagecloud/foo, for example, is a "scoped" package. Scoped packages are used in the same way as any other module name in package.json and JavaScript code.
{
"name": "Packagecloud/foo",
"version": "1.1.1",
"description": "just a scoped package name example",
"dependencies": {
"@Packagecloud/bar": "2.x"
}
}
// es modules style
import foo from '@Packagecloud/foo'
// commonjs style
const foo = require('@Packagecloud/foo')
Scopes: Why and How to Use Them
On the public npm registry, scoped packages may be published exclusively by the person or organisation with whom they are associated, and packages within the scope may be kept private. Additionally, scope names may be associated with certain registries.
For instance, this login command ensures that all requests for packages falling within the @Packagecloud scope are sent via the https://registry.Packagecloud.local registry. Other requests that are not scope-bound will be sent via the default registry.
$ npm login --scope=Packagecloud --registry=https://registry.Packagecloud.local
This stores your login credentials in the following format in your /.npmrc file:
@Packagecloud:registry = https://registry.Packagecloud.local/ //registry.Packagecloud.local:_authToken = xyzabc123-arbitrary-token-value
After that, go to the public npm registry and establish a new free organisation named "Packagecloud." No one else can publish anything on the public registry in the @Packagecloud scope after that, and if your builds are misconfigured, they'll fail with 404 errors instead of quietly fetching untrustworthy stuff. This is a critical step since it prevents an attacker from stealing your organization's name in the public register, resulting in the same issues.
As a last precaution, create a.npmrc file in the root directory of your projects and include the following line:
@Packagecloud:registry = https://registry.Packagecloud.local/
When dealing with that project, npm will automatically link the scope with your internal registry.
Avoiding non-malicious failures
Using scopes avoids extra failures, which, although not malicious, may be inconvenient and difficult to troubleshoot. As an example, suppose you're utilizing the internal package ABC. Later, a user on the public registry selects the package name ABC. Someone else creates a shared package bar that is ABC-dependent.
You attempt to utilize the bar (the public package) in an internal environment one day. It indicates to npm that it requires a dependence on ABC. npm downloads ABC carefully, and since it is set to use your internal registry, it locates the internal package ABC. However, this is not the same as the public package ABC, and your build will fail unexpectedly.
Additionally, scopes prevent leaking caused by an accidental publication of private packages to the public npm repository. If no one is in the public org, even if they somehow manage to screw up the setup, the publish will fail since they lack the authorization to publish to that scope.
Using Scopes to effectively eliminate attack vector
While software security is never a black-and-white problem, scopes may help reduce the dangers associated with the stated attack vector, in which an attacker claims a name on the public registry that you use internally.
If you are utilizing a private npm registry solution that does not allow scopes, please communicate this need to your vendor. If you haven't been utilizing scopes, migrating your package names may be a significant effort. While you are making this critical move for security, you can do a few other things in the meantime.
Conclusion
To summarise, a software supply chain consists of everything that enters or impacts your code. Supply chain breaches are real and increasing in popularity — which is why it’s critical to secure your supply chain by fixing your vulnerabilities. Then, to effectively protect your software supply chain, you must understand your environment's dependencies, be aware of their vulnerabilities, and promptly fix them.
Numerous solutions are available to assist you in ensuring the safety of your software supply chain. The critical point is to ensure that you use accessible tools and know the trade-offs involved in decision-making. Packagecloud is one of the most frequently used tools to secure your software supply chain.
Packagecloud checks your packages against all known cybersecurity risks, guaranteeing that nothing inside them is susceptible. Packagecloud can store all of your packages in one location, giving you complete control over the programs you use. Instead of utilizing public repositories, you can ensure that packages are always pulled from a controlled environment.
You can utilize Packagecloud to ensure the complete security of your packages and software supply chain. You should register for a free trial of Packagecloud here.
