Supply Chain Security — 10 Tips That Won’t Slow Development Down

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.

This is part of an extensive series of guides about the software supply chain.

Supply chain risks are inherent to open source dependencies

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.

Protecting against supply chain threats

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. 

#1 Use only verified package sources.

#2 Watch your typos to avoid typosquatting attacks.

Typosquatting and brandjacking are among the most commonly used vectors of attack.

#3 Review the open source licenses of the packages that you are using.

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.

#4 Migrate from packages that are abandoned 

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.

#5 Don’t use new packages

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. 

#6 Make sure that critical production-related CVE notifications are part of your security alert workflow. 

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.

#7 Use only packages that are confirmed as safe

If you are using automated tools to update your dependencies, make sure that packages are confirmed as safe before updates are automatically installed. 

#8 Use isolated CI stages.

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. 

#9 Protect your entire development cycle, starting from developers.

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.   

#10 Review packages based on research, not just the description on the git repository.

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 its secure. You should not rely on the data that comes out of the registry you’re using. Or – use Mend Supply Chain Defender, which will analyze the packages for you to detect security and quality issues.

Supply chain security that doesn’t slow you down

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.