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.

Very interesting new supply chain attack. Shows one of the big downsides of the very convenient packaging tools everyone uses lately. Interestingly in that particular case it seems less risky only with the publicly available components, it's in the context of private repositories that the risk arises. Root cause seems to be the lack of control on how those tools resolve between private and public repositories.