Software Supply Chain: Why a Small Package Can Bring Down the Entire System
Photo: tl;dr sec

Software Supply Chain: Why a Small Package Can Bring Down the Entire System

A modern project brings with it thousands of indirect dependencies. Each one is a gateway you’ve never considered.

Run the setup command for a new web project and count the number of packages downloaded: the number usually exceeds a thousand. How many of those have you actually read the code for?

Three Common Types of Attacks

  • Hacking an author’s account — the attacker gains publishing rights and releases a version containing malware; users upgrade as usual and get infected
  • Misleading package names — register a name similar to a popular package and wait for users to mistype it
  • Long-term trust-building — making legitimate contributions for months to gain maintenance privileges, then installing a sophisticated backdoor

The third type is the most dangerous because the malware is injected gradually, hidden in build files or test data rather than in the easily readable source code.

Defense Based on Effort Level

It's easy and should be done right away: lock the exact version using a lock file and commit it to the repository; enable automatic vulnerability scanning; and prevent the package's installation script from running arbitrarily.

On average: maintain an internal cache instead of downloading directly from the Internet; set a delay of a few days before receiving new updates, since most malicious packages are detected within the first 48 hours.

It's expensive but worth it for critical systems: it can be rebuilt from source code, and you can verify and check signatures, significantly reducing dependencies.

A useful question to ask when adding a library: If the author of this package turns hostile tomorrow, what would my system lose?
Chia sẻ

Thảo luận