Comment by 0xbadcafebee | Hacker News Reader

Comment by 0xbadcafebee | Hacker News Reader

Parent Full thread

The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev...

The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac...

The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope...

A student researcher took over Python ctx and PHPass package maintainership, pushing out malicious changes, and that took over 7 days to be detected and fixed: https://infosecwriteups.com/how-i-hacked-ctx-and-phpass-modu...

Kaspersky found multiple PyPI packages that had been exploited for more than a year: https://www.kaspersky.com/about/press-releases/kaspersky-unc...

"LoftyLife" packages were exploited for several months: https://securelist.com/lofylife-malicious-npm-packages/10701...

Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.

> Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.

Many automated scanners use static code analysis rather than run the installation script. Not all of them are caught, but a good part of them are and you'd be saved by a delay.

Instant attacks are much easier and more common than delayed attacks. Security is an onion.

Ok so no external dependencies, or pull versions from 2021 and apply security patches?

- Best practice for both reliability and security is to not immediately upgrade to latest versions. Only immediately upgrade to security-patched versions. If your software doesn't need a new version, you can remain on the old version.

- When a feature you're developing, or a transitive dependency, requires an upgraded version, you can upgrade to the latest stable version that satisfies the dependency. But as each of those then requires an additional transitive dependency to be upgraded, you have more and more components upgraded to "latest", and the attack surface widens. So there are two alternatives:

1) (preferred) Upgrade to the latest version of the next-to-latest minor version, within the oldest major version that is supported, if that is available. This is the least number of changes that provides the needed functionality.

2) Upgrade only to the oldest version that gives you the functionality you need. If this ends up being the first version of a new major or minor version, this can cause bugs (initial releases of new major/minor always has bugs), so in that case you might as well use the latest version of that major/minor version.

This all affects security by avoiding upgrading to the latest version. It affects reliability by minimizing the amount of changes between your current version and upgraded version (changes lead to bugs).

The argument against all that, and for always upgrading to the latest versions, is intended to make software development easier. You avoid all the complexity of picking versions or reading changelogs by using software that is probably (but not always) all compatible. But it makes reliability and security worse. So you need to choose: do you want security and reliability, or an easier time writing code?

it would be way easier if dependencies were a flat list and not a graph, aka peer in npm parlance. I believe that’s what go does. A library only need to say that it depends 1.x.x or 1.2.x and it’s up to the application to provide it. Conflict is handled manually.

The onus is on libraries developers to cleanup their act. Start vendoring code instead of depending on hundreds tiny libraries.

Reply on news.ycombinator.com