Bad actors will go to great length to try to compromise your supply chain.

It's indeed surprising that this compromised npm account didn't lead to more damage. It's a good reminder that you better regularly audit what happens in your ecosystem.

Sometimes, it's indeed better to not pull an extra dependency.

Mind your typos... It seems clear a bad actor is hiding behind that one.

Not strictly about Rust, still is shows how to approach the conversation about your dependencies. It also gives good ideas on how to try to reduce them.

I'm not sure this dichotomy is enough for building a taxonomy of FOSS projects. But I guess it's a start and captures something often missing in other such attempts.

For studying it makes sense. But don't shun other's work away only because of trust or ego issues.

There's clearly a tension between security and ease of pulling dependencies. In a way, it's "too easy" with cargo and you very quickly end up having to trust a staggering amount of third party code.

Dependency resolution is harder than people generally expect. This is a difficult problem and is very sensitive to the context.

Indeed there is a tension between both approaches in package ecosystems.

This is a worthy questioning... We try to reuse, but maybe we do it too much? For sure some ecosystems quickly lead to hundreds of dependencies even for small features.

The browser extension ecosystems are definitely a weak link in term of security. Better not have too many random extensions installed.

There is some good advice in this piece. If you want to maintain something for a long time, some aspects need to be thought out from the beginning.

Interesting report, some findings are kind of unexpected. It's interesting to see how much npm and maven dominate the supply chain. Clearly there's a need for a global scheme to identify dependencies, hopefully we'll get there.

It's tempting to use uv. It's probably fine on the developer workstation at this point. It looks a bit early to use it in production though, it's a bit young for that and carries questions regarding supply chain security still.

Interesting comparison between old attempts at backdooring OpenSSH and the latest xz attempt. There are lessons to be learned from this. It makes a good case for starting to sandbox everything.

Good tour of all the way dependencies might get compromised in your supply chain. Getting this easy to detect is needed.

This is bad for two reasons: 1) people clearly put too much trust in random CDNs to distribute their dependencies and 2) people don't track depencendies obsolescence properly.

You should be mindful of the dependencies you add. Even more so when the name of the dependency has been proposed by a coding assistant.

Good analysis of the backdoor recently discovered in xz. Really a bad situation. Luckily it was probably detected before it could do any real damage. What's especially striking is the amount of patience it required, it's really been put in place over a long stretch of time to reduce chances of detection.