4 ms·

Surprised to see no discussion about the supply chain attacks against Russia where devs added malicious code that would computers with ip addresses in Russia &

Surprised to see no discussion about the supply chain attacks against Russia where devs added malicious code that would computers with ip addresses in Russia & Belarus. How does one guard against that? Review every patch?

swatcoder 4y ago
> Review every patch? Well, yeah. If you review code contributed by somebody you spent hours vetting and interviewing, and whose worked in the next office over for a year, and whose work is accountable through their livelihood, why would you not review the code contributed by some unpaid internet rando? Of course, the practical answer is “Because that’s crazy! There’s no budget for that!” — which is why this problem exists. There are other ways of establishing and delegating trust so that you personally don’t have to review every import and change (see the Linux distribution ecosystem), but these vulnerabilities will persist until those networks and systems get built out. And they won’t get built out until people learn that GitHub stars and popularity are not sufficient measures of quality or reliability.
deleted 4y ago
[deleted]
feross 4y ago
> Review every patch? Yes. You are responsible for the code that you ship to production, whether you wrote it or it comes from open source. Fundamentally, there's no other way to solve this problem in a dynamic language like JavaScript. You can use tools like https://socket.dev https://socket.dev (disclosure: I'm the founder) to automate finding the dependency updates that are particularly suspicious/risky, i.e. they contain 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. In the far future, I have hope that efforts like ES Realms and LavaMoat will give us per-package permissions and true isolation, but at the moment they're not practical/performant enough to use. Even with code signing (an often suggested approach), you still have the problem of maintainers going rogue, or maintainers adding new malicious maintainers to formerly safe dependencies. tldr; you need to 'review' every patch, though it doesn't necessarily need to be a human review for every patch.

swatcoder 4y ago

> Review every patch? Well, yeah. If you review code contributed by somebody you spent hours vetting and interviewing, and whose worked in the next office over for a year, and whose work is accountable through their livelihood, why would you not review the code contributed by some unpaid internet rando? Of course, the practical answer is “Because that’s crazy! There’s no budget for that!” — which is why this problem exists. There are other ways of establishing and delegating trust so that you personally don’t have to review every import and change (see the Linux distribution ecosystem), but these vulnerabilities will persist until those networks and systems get built out. And they won’t get built out until people learn that GitHub stars and popularity are not sufficient measures of quality or reliability.

deleted 4y ago

[deleted]

feross 4y ago

> Review every patch? Yes. You are responsible for the code that you ship to production, whether you wrote it or it comes from open source. Fundamentally, there's no other way to solve this problem in a dynamic language like JavaScript. You can use tools like https://socket.dev https://socket.dev (disclosure: I'm the founder) to automate finding the dependency updates that are particularly suspicious/risky, i.e. they contain 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. In the far future, I have hope that efforts like ES Realms and LavaMoat will give us per-package permissions and true isolation, but at the moment they're not practical/performant enough to use. Even with code signing (an often suggested approach), you still have the problem of maintainers going rogue, or maintainers adding new malicious maintainers to formerly safe dependencies. tldr; you need to 'review' every patch, though it doesn't necessarily need to be a human review for every patch.