3 ms·

Founder of Socket (https://socket.dev https://socket.dev) here, a new tool built by npm maintainers to help solve JavaScript supply chain security. I totally a

by feross 5y ago

Founder of Socket (https://socket.dev https://socket.dev) here, a new tool built by npm maintainers to help solve JavaScript supply chain security. I totally agree with the idea that we should assume all open source packages may be malicious. Socket.dev uses "deep package inspection" to characterize the behavior of an open source package. By actually analyzing the package code, Socket can detect when packages use security-relevant platform capabilities, such as the network, filesystem, or shell. For instance, to detect if a package uses the network, Socket looks at whether fetch(), or Node's net, dgram, dns, http or https modules are used within the package or any of its dependencies. This entails running static analysis (and soon, dynamic analysis) on a package – and all of its dependencies – to look for specific risk markers. In this way, Socket can detect the tell-tale signs of a supply chain attack, including the introduction of install scripts, obfuscated code, high entropy strings, or usage of privileged APIs such as shell, filesystem, eval(), and environment variables. We are taking an entirely new approach to one of the hardest problems in security in a stagnant part of the industry that has historically been obsessed with just reporting on known vulnerabilities.

caseyross 5y ago
This, in my opinion, is the right answer for the problem identified in the parent blogpost. Rather than trying to get every single package author to adopt some unified capability token scheme in their code, just statically analyze all dependencies from the outside and report the capabilities they actually use. It would be even better if something like this could be integrated directly into the package management tool itself, so that you could run `npm update` and get back "New dangerous API usage in package X version a.b.c: filesystem access. Type package name to acknowledge and upgrade."
- feross 5y ago
  Thanks. Glad you like our approach. > It would be even better if something like this could be integrated directly into the package management tool itself We're planning to build this. However right now, the primary way to consume Socket.dev data is through our GitHub app (https://socket.dev/integrations https://socket.dev/integrations).
vbezhenar 5y ago
What prevents malicious person to craft their code until it evades your analysis? It's the same with antiviruses. They're not that useful because adversaries adapt their viruses to pass antivirus heuristics. And, as viruses show, you can make your heuristics whatever complex, someone smart will find a way around. Especially in that wild JavaScript environment.
- feross 5y ago
  This is a fair question. The answer is that most malware behaves in ways that are deterministically detectable. For example, 93% of malware uses install scripts, which must be declared in the package.json file and are not possible to hide from our analysis. From recent research: > We found 93.9% (3,412) of malicious packages had at least one install scripts, indicating that malicious attackers use install scripts frequently [1] When malware authors adapt and start doing fancy dynamic stuff, we might not be able to figure out exactly what they're doing, but we can detect the usage of obfuscated code, dynamic requires, and other signals of compromise. [1]: https://arxiv.org/pdf/2112.10165.pdf https://arxiv.org/pdf/2112.10165.pdf

by feross 5y ago

caseyross 5y ago

This, in my opinion, is the right answer for the problem identified in the parent blogpost. Rather than trying to get every single package author to adopt some unified capability token scheme in their code, just statically analyze all dependencies from the outside and report the capabilities they actually use. It would be even better if something like this could be integrated directly into the package management tool itself, so that you could run `npm update` and get back "New dangerous API usage in package X version a.b.c: filesystem access. Type package name to acknowledge and upgrade."

feross 5y ago
Thanks. Glad you like our approach. > It would be even better if something like this could be integrated directly into the package management tool itself We're planning to build this. However right now, the primary way to consume Socket.dev data is through our GitHub app (https://socket.dev/integrations https://socket.dev/integrations).

vbezhenar 5y ago

What prevents malicious person to craft their code until it evades your analysis? It's the same with antiviruses. They're not that useful because adversaries adapt their viruses to pass antivirus heuristics. And, as viruses show, you can make your heuristics whatever complex, someone smart will find a way around. Especially in that wild JavaScript environment.

feross 5y ago
This is a fair question. The answer is that most malware behaves in ways that are deterministically detectable. For example, 93% of malware uses install scripts, which must be declared in the package.json file and are not possible to hide from our analysis. From recent research: > We found 93.9% (3,412) of malicious packages had at least one install scripts, indicating that malicious attackers use install scripts frequently [1] When malware authors adapt and start doing fancy dynamic stuff, we might not be able to figure out exactly what they're doing, but we can detect the usage of obfuscated code, dynamic requires, and other signals of compromise. [1]: https://arxiv.org/pdf/2112.10165.pdf https://arxiv.org/pdf/2112.10165.pdf