We're not helped much by our tools here... Clearly provenance needs to be double checked.

New packaging ecosystems bring their new attack vectors. This is definitely a teething problem which will need to be addressed soon.

There are growing concerns regarding the Rust supply chain. It's still time to address them but it's became important to tackle this area.

Indeed, we might want to use dev containers more widely in the profession. If you're developing something for the desktop you're out of luck though.

Indeed, if you benefit from Free Software you'd better engage with it. Maintainers should stop bending backwards to please free loaders.

This is indeed the best way to handle your open source dependencies. I got concerns about the ability to sell that to management though because of the extra steps. It's also probably why you want to have an OSPO in your company, it's a good way to lower the barrier for developers to contribute this way.

Interesting analysis of the crates ecosystem. It shows quite well some of the challenges and weaknesses. Nothing to worry about yet about the ecosystem health overall. Still, you should probably be careful when picking dependencies.

Nice overview of where we stand regarding supply chain security. Code reuse has never been so widespread and we still have fundamental issues leading to security problems.

This latest development in the Ruby community is rather concerning.

Unsurprisingly ends up with an advertisement for their own security tool. That said the vector used for the attack is interesting, with more npm like ecosystems available nowadays, should we expect to see more such attacks?

Nice automation for such updates. I'm discovering endoflife.date this looks very handy.

A good explanation of why you likely don't want a centralised package manager for your ecosystem.

Good idea to standardise this for vendors just like we do using CVEs for software components. This would definitely improve dealing with breaches.

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.

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.

This is indeed a problem in the way Pipenv handle this kind of cases. Makes for bisecting clearly troublesome.

Interesting forensic of a supply chain attack targetting crates.io. Especially fascinating to me is how it then tries to target CI build environments as preparation for larger attacks.

Admittedly, the go toolchain seems to handle supply chain problems in a neat way. I especially like the VCS as the source of truth.

Interesting list of criteria about why you might not use some piece of tech. Also delves into why this is often not public knowledge.

Now this one is really nasty...

Another couple of attempts at supply chain attacks. This time in the Python ecosystem. The skill level of those attempts isn't high though.

This ecosystem keeps baffling me... How come there are so little checks on what can get published or how the command line process parameters.

Seeing the bad practices of Amazon with its Android AppStore, it really feels like another supply chain mess in the making with Windows 11 Android support...

Maybe a way out of the supply chain attacks? Will take time and adoption of course.