2 ms·

Somewhat controversial these days, but treat every single dependency as a potential security nightmare, source of bugs, problem that you will have to solve in t

Somewhat controversial these days, but treat every single dependency as a potential security nightmare, source of bugs, problem that you will have to solve in the future. Use dependencies carefully and as a last resort. Vendoring dependencies (copying the package code into your project rather than using the package manager to manage it) can help - it won't stop a malicious package, but it will stop a package from turning malicious. You can also copy the code you need from a dependency into your code (with a comment giving credit and a link to the source package). This is really useful if you just need some of the stuff that the package offers, and also forces you to read and understand the package code; great practice if you're learning.

devsda 1y ago
Inspecting 10 layers of dependencies individually to install a popular tool or an lsp server is going to work once or twice. Eventually either complacency or fatigue sets in and the attacker wins. I think we need a different solution that fixes the dependency bloat or puts more safeguards around package publishing. The same goes for any other language with excessive third-party dependency requirements.
- marcus_holmes 1y ago
  Agree. It's going to take a lot of people getting pwned to change these attitudes though
  - zbentley 1y ago
    Why would attitudes change? The impact is diffused across a wide enough populace (precisely because ecosystems with weak community norms around dependency security are extremely popular) that the rate of “shaping up in response to a painful lesson” may remain lower than the rate of newcomers joining the community or the rate of new insecure dependencies proliferating to serve new needs brought about by new use cases brought about by growing popularity of a platform. That’s not to say it’s hopeless. Rather, it’s more likely that widespread improvement will need to be centrally orchestrated rather than organic in response to hacks.
    - a96 1y ago
      PHP is living proof that no matter how Broken As Designed something is, it will just go on if it's popular enough.
hinkley 1y ago
Local proxies that can work offline also helps. Though not as much as vendoring.

devsda 1y ago

Inspecting 10 layers of dependencies individually to install a popular tool or an lsp server is going to work once or twice. Eventually either complacency or fatigue sets in and the attacker wins. I think we need a different solution that fixes the dependency bloat or puts more safeguards around package publishing. The same goes for any other language with excessive third-party dependency requirements.

marcus_holmes 1y ago
Agree. It's going to take a lot of people getting pwned to change these attitudes though
- zbentley 1y ago
  Why would attitudes change? The impact is diffused across a wide enough populace (precisely because ecosystems with weak community norms around dependency security are extremely popular) that the rate of “shaping up in response to a painful lesson” may remain lower than the rate of newcomers joining the community or the rate of new insecure dependencies proliferating to serve new needs brought about by new use cases brought about by growing popularity of a platform. That’s not to say it’s hopeless. Rather, it’s more likely that widespread improvement will need to be centrally orchestrated rather than organic in response to hacks.
  - a96 1y ago
    PHP is living proof that no matter how Broken As Designed something is, it will just go on if it's popular enough.

hinkley 1y ago

Local proxies that can work offline also helps. Though not as much as vendoring.