The growing use of open source packages in modern software development has

come with the increased threat of supply chain attacks.

Attackers can choose from several methods to infect open source packages and
distribute malicious code, effectively poisoning the well that feeds millions of
other programs.
A new study by researchers at North Carolina University and Microsoft offers a
new approach to securing software supply chains, using data-based empirical
methods to predict which open source packages are more susceptible to
becoming the target of attacks.
The study, conducted on 1.63 million packages in the NPM repository, reveals six
indicators of weakness in the open source software supply chain.
Acting on these findings can help package maintainers and users make better
security decisions and therefore safeguard their software against potential supply
chain attack.

Weak links in the NPM supply chain

“Security researchers in academia and industry are actively investigating attacks

in ecosystems to propose solutions; these approaches seem to be based on
specific instances of malicious attacks (e.g. typosquatting, dependency
confusion),” Nusrat Zahan, PhD student at NCSU and lead author of the paper,
told The Daily Swig.
“Hence, they are especially effective in preventing malicious code distribution.
But recent attacks show evidence that out-of-the-box exploit strategies will
appear again and again.”
Zahan warned: “Any ad-hoc solution is not enough to prevent an attack that we
have not witnessed yet.”
In their study, the researchers found six key indicators that an NPM package may
be compromised by malicious actors:
1. There were 2,818 maintainers whose domains had expired. An attacker can
purchase an expired domain and use it to hijack the maintainers’ accounts unless
it is protected by two-factor authentication (2FA).

2. About 2% (33,000) of the packages included install scripts. Install scripts run

automatically before, during, or after a package installation. If compromised, they
can enable attackers to perform malicious activity on host devices, such as
 transferring user data, downloading malicious payloads, executing reverse shells,
or removing files and directories.

3. Around 59% of the packages were unmaintained for two years. Moreover, 44%

of the maintainers were inactive for two years. Unmaintained packages have a
greater chance of getting compromised without detection. Inactive maintainers
might be targeted with account hijacking attacks without noticing.

4. A small percentage of the packages had too many maintainers, which

increases the chances of at least one of the maintainers’ accounts being
compromised.

5. Some packages had too many contributors, which made it hard for maintainers
to keep tabs on all changes. An attacker can use social engineering to become
regarded as a trusted contributor to such packages before sneaking in malicious
code.

6. The top 1% maintainers were overloaded and owned an average 180

packages. Attackers have a greater incentive to target such maintainers because
first, they are more likely to overlook changes to any particular packages, and
second, if compromised, their accounts can provide access to many packages.

Next steps

“If we think about different supply chain attacks, we will often see attackers using
new techniques that we have not witnessed yet to propose a solution,” Zahan
said.
“Our study aims to motivate practitioners to adopt best security practices instead
of waiting for an attack to happen.”
The researchers corroborated their findings through a survey of hundreds of
NPM package maintainers. Most participants agreed with the severity of the first
three indicators and were interested in being notified about potential problems in
these areas.
 Read more of the latest infosec research news

It might be possible for the maintainers of the NPM repository to compute and
display a risk model based on scoring the indicators of potential problem they
identify, the researchers suggest.
Such a model would enable package managers to evaluate the security of their
packages and address areas of potential weakness. It will also enable package
users to make more educated, data-driven decisions and comparisons before
incorporating new packages into their development pipelines.
“Please think about package security before selecting any package,” Zahan
concluded. “Do not use a package just because other people are using the same
package. Our proposed weak link signals along with the OpenSSF Metrics,
Scorecard, and Best Practices Badge projects can be a good start to measure
package risk in the supply chain.”