As supply chain attacks continue to dominate headlines, software development teams are beginning to realize that package management can’t be taken lightly — the threats hidden under the hood are real. In this installment of The Source, we want to talk about the practices and tools that developers need to adopt in order to protect against supply chain attacks.
Open source components, via package managers and registries, are a great way to hack into a company’s supply chain. Developers are busy enough already, and no one has the time to review every single line of code in every single package, let alone the package updates.
Projects usually start out with the latest versions of all packages, and then slowly fall behind. Software development organizations’ AppSec strategies must take into account that while open source usage has many benefits, there are also risks. One of them is that open source dependencies contain open source supply chain risks. Failing to secure the open source supply chain opens the door to risks like outages, cryptojacking, botnets, leaked data, or legal risks related to open source licenses or data loss.
What developers need to remember is that for many of the ecosystems, merely installing a package could open the door to threats. Ecosystems line NPM, PyPI, and RubyGems contain post-install hooks. As soon as a developer installs a library, permissions are granted, allowing access to anything and everything associated with the account their machine is running on. If the installed library contains malicious code, it could easily cause havoc or infect other libraries while cleaning itself up.
While there is no one solution that addresses all of the risks, there is a series of countermeasures that developers can use to address supply chain security.
Typosquatting and brandjacking are amongst most commonly used vectors of attack.
Many package registries provide information about the license for a given package. It’s important to remember that different releases might have different open source licenses.
Abandoned packages are more likely to be a subject of a malicious takeover. If you’re relying on a piece of software that does not get enough attention, consider either avoiding it or taking it over. You could also run a community assessment on the packages you plan to incorporate into your software.
If a package is less than 30 days old, wait until it’s confirmed as safe by the community’s security researchers.
In the past year we saw several attempts to publish malicious packages to various registries. With this policy in place, the majority of them could be avoided.
Once in a while there may be a critical vulnerability that is affecting your production. It’s better to be woken up due to a security alert rather than a security incident.
If you are using automated tools to update your dependencies, make sure that packages are confirmed as safe before updates are automatically installed.
Don’t use a single CI pipeline that has all of the environment variables for AWS, Docker registries, etc. If you’re using the same environment for running specs, building containers, pushing updates, and everything else — you are putting your environment, your company, and your customers, at risk.
The first step towards threat prevention is spreading awareness. Educate teams that randomly searching for and downloading packages is not OK. Make sure standard practice is to never install a package before checking who’s behind it.
In order to review an open source project you’re interested in using, you will need to download the package and study its content to ensure it’s secure. You should not rely on the data that comes out of the registry you’re using. Or – use WhiteSource Diffend, which will analyze the packages for you to detect security and quality issues.
As security shifts left, developers are increasingly tasked with the detection and remediation of vulnerabilities.
While old methodologies put security at the end of the development process and slowed down the development cycle, today’s DevSecOps gives developers a seat at the security table from the earliest stages of development. Unfortunately, they aren’t always given the tools and practices that they need in order to share ownership over security.
Developers don’t need to become security experts in order to share ownership over security. They simply need to integrate the right automated tools and practices that will help them cover security threats like supply chain attacks, without slowing them down.