DevOps and large-scale software building and delivery automation have raised the software supply chain and its supporting delivery pipeline to mission-critical status in every modern organization.
Software supply chain attacks are not new, and they are also not uncommon. The SolarWinds attack is just one of several, including the ASUS and event-streams attacks from previous years, as well as the dependency confusion and Mimecast instances more recently.
What has changed, though, is the way software is now developed. This is a change that has increased the risk of a software supply chain attack.
The mechanics of an attack
A supply chain attack has a basic concept. Malicious actors target third-party software components designed and maintained by people other than the primary software developer, which are usually stored in a centralized registry. They leverage design weaknesses and flaws in these third-party components to inject malicious code (directly into the consumed source or indirectly via a dependency tree constraint), allowing them to obtain access to internal systems and end-users. It’s not just centralized sources that can be hacked; decentralized third-party component sources can also be hacked.
Attacks on the software supply chain are both risky and successful. Targeting a software supply chain allows cybercriminals to compromise a wide range of businesses in one hit, just as hacking a public cloud allows them to attack numerous firms at once.
Although these attacks are not new, they are becoming more common. That’s because, in order to keep up with the pace of development, software engineers have progressively switched away from writing code solely by themselves and toward putting together programs using a mix of private and open-source code. Today’s code repositories are vastly different from those of even a few years ago, with proprietary and open-source packages, containers, infrastructure as code, and even build configurations all being popular. In the software supply chain, each of these is a possible attack vector.
How can developers build in resistance?
Although the risk is growing, developers can code in defense against software supply chain threats.
The first step is to protect against dependency confusion attacks, which include malware being installed on a company’s network by replacing legitimate packages with malicious public packages with the same name. Developers use package managers and build tools to automatically pull open-source packages as part of the software supply chain. Packages with the same name can be pulled in from a public code repository if these are not configured to exclusively pull packages from the private registry. An attacker can exploit this design weakness by scanning an organization’s public repository for private package names and uploading a malicious package with the same name. The rest will be handled by automated build processes, which will pull in the malicious package rather than the intended, internally-created one.
To avoid this, developers should use scoped namescapes in their projects. Scoped packages prohibit package substitution by locking the package’s namespace and mapping it to a single user or organization. Another method is to utilize repo-specific configuration for explicit upstream registry definition, which gives package managers like pip and npm explicit guidance so they don’t go seeking a newer version of the package in the public registry and mistakenly pull in a malicious package.
Disabling arbitrary install commands by open-source programs is another step that developers should take. Some package managers like npm, allow any package being installed or removed to run arbitrary commands by default. As a result, organizations are vulnerable to typosquatting and hidden backdoor techniques. The solution is to make sure that packages are thoroughly checked before being installed, and that they are not installed on the fly or via insecure copy and paste.
For more such updates follow us on Google News ITsecuritywire News