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.

This is about a Rust library but equally applies to any ecosystem which allows to easily pull a dependency. As soon as you pull them, you need to monitor their health for the sake of your own project.

Definitely this, the software bloat directly impacts the attack surface of what gets shipped. Even though this is far from a panacea in terms of security, it's time for people to critically examine their dependencies also for other reasons.

The tone pointing at "open models" is wrong but the research is interesting. It still proves models can be poisoned (open or not) so traceability and secured supply-chains will become very important when using large language models.

There's still some work to secure the Python supply chain. It's clearly suffering from fragmentation and ambiguous data.

Very interesting study on dependencies. This is specific to the Maven ecosystem so too early to generalize the findings to other similar ecosystems. This indicates at least the difficulties of managing dependencies, especially the transitive ones. Also tries to define the "dependencies bloat" problem.

Interesting idea, for sure on a complex enough system just managing the dependencies can quickly become a full time job.

This is a good thing that Google makes such a move. Still, it could be so much more. Tidelift still seems to be the best offer for securing your dependencies.

Friendly reminder, if you're not paying authors of FOSS libraries, they owe you nothing.