Lately I’ve been talking a lot about the supply chain risk. You import some software, and are suddenly importing their business model and practices. Well, we’ve just had another ‘shenanigan’ unveiled. And its got some good drama. https://github.com/dominictarr/event-stream/issues/116
In a nutshell there is some package which is relatively stable. The original developer doesn’t use it anymore, its stagnant, but people are still using it. Someone comes alone, offers to take over the maintaining, its handed off.
The new dev makes a quick minor fix, updates the package. And then… makes some evil changes, pushes them on top of that version and then hides it.
And now all your bitcoin are belong to unknown dev #2.
And lots of things are broken. One person in the thread (perhaps a troll) is complaining because he has some software which has pinned the dependency to the bad version, and now won’t build in their CI.
Millions of people have installed this software, somewhere, everywhere, no real way to say.
Since there is no signing, we can’t say what was in github when it was published, or if it came from github or elsewhere, so the source is murky. There’s some encryption, some patching of dependencies. You could have this and not know. You can’t trust the ‘npm ls’ to show the truth.
So this brings up the question of open source governance. A strong project that is hard to breach has multiple maintainers, who are unrelated to each other, and who it takes more than one of reviewing a commit to get it approved. Is this something you look for when you choose your immediate upstreams? Do your upstreams look for this? Do their upstreams? And so on. The tree is both deep and wide.
Red team only has to get it right once, blue team needs to be right 100% of the time.
Commence worrying in 3…2…1.
Leave a Reply