4 ms·

Lots of things could be done, it's whether people are willing to accept the tradeoffs, which they haven't been (in general) up until now. Unfortunately, modern

Lots of things could be done, it's whether people are willing to accept the tradeoffs, which they haven't been (in general) up until now. Unfortunately, modern software development has heavily embedded the idea of using large numebers of un-reviewed open source libraries, changing that assumption would be very difficult. A non-exhaustive list of things that could be done... - Improve repository security (e.g. stronger authentication requirements). Problem here is most of the repositories are non-profit and this costs money. Also there's a risk that if you increase friction for developers, they'll go elsewhere. - Require library signing. This has some potential benefits (may even have stopped this attack) but again increased friction for developers and management overhead for repositories. - Curation of libraries. Actually pay some people to review the code in the libraries. This doesn't scale easily when you consider the volume that places like NPM have.

repolfx 8y ago
Also (on some runtimes): - Sandbox code modules If a library doesn't need any permissions, and it's not granted any, then attempts to e.g. access the filesystem or network will throw exceptions. The JVM can do this, but it's not well documented how to use it.
- nih0 8y ago
  The java security manager is a cool concept but sadly not very ergonomic to use.
bfred_it 8y ago
> This doesn't scale easily when you consider the volume that places like NPM have. Found the blanket statement for npm. How about instead of reviewing 1 library of 10k lines that does everything, you review 10 focused modules for a total of 1k lines? Also modules like left-pad don’t change that often so you probably have to review only changes in the top modules. We need to stop this mentality that dependency count should be low. Look at total LOC and you’ll probably find that it’s not as bad as people like to paint it.
- nfm 8y ago
  A high dependency count does increase your vulnerability surface area. All it takes is one weak or reused password on an account without 2FA enabled for a malicious package to be uploaded. You're more vulnerable to this when you depend on more individual publishers to get it right.

repolfx 8y ago

Also (on some runtimes): - Sandbox code modules If a library doesn't need any permissions, and it's not granted any, then attempts to e.g. access the filesystem or network will throw exceptions. The JVM can do this, but it's not well documented how to use it.

nih0 8y ago
The java security manager is a cool concept but sadly not very ergonomic to use.

bfred_it 8y ago

> This doesn't scale easily when you consider the volume that places like NPM have. Found the blanket statement for npm. How about instead of reviewing 1 library of 10k lines that does everything, you review 10 focused modules for a total of 1k lines? Also modules like left-pad don’t change that often so you probably have to review only changes in the top modules. We need to stop this mentality that dependency count should be low. Look at total LOC and you’ll probably find that it’s not as bad as people like to paint it.

nfm 8y ago
A high dependency count does increase your vulnerability surface area. All it takes is one weak or reused password on an account without 2FA enabled for a malicious package to be uploaded. You're more vulnerable to this when you depend on more individual publishers to get it right.