except if you check the bitcoin core repo, all the PRs have extensive code reviews done before they're merged. the chance of a supply chain attack (eg. node-ipc) is low.
The solution at my workplace is a bot that opens PRs to bump dependencies and automatically merges if the tests pass.
It's taken a lot of workload off devs to meet security targets. But I worry it makes supply-chain attacks more attractive. If an attacker can compromise a package and it's instantly merged into the codebases of thousands of different companies that's a huge danger.
Check out https://socket.dev/
Been super impressed by their approach to identifying and securing codebases against supply chain attacks (and I believe they have a special deal for open source repos too!)
That's only the case if I am unable to review the code myself, before any update, I fully understand the code, and I am smart enough that the contributors are unable to pull a fast one on me.
Given that I'm not a cryptography expert, I have a limited number of hours in the day, and open-source supply chain attacks are typically obfuscated, I don't consider that to be a trivial statement.
At a naive level, this sounds like the sort of supply chain attack we've all been taught to fear. Asking seriously: has this build been replicated? is the source different from mainline? if so, what changed and who changed it?
Author didn't mention node-ipc which I think makes his point much better than supply chain attacks. In supply chain attack, some security failure leads to sneaky malware injected into the build. One could argue that cryptographic signing could solve this problem. However, in the case of node-ipc, #the author# of the package inserted malware deliberately. No package signing can help you with that. Nor can community reputation, as github did nothing about the deliberate distribution of malware from their platform.
When that is the working environment, he's right. Trust no one.
Seems like an interesting evolution of supply-chain attacks, since this is a bit more indirect. At least when a common open-source library gets poisoned, the code transparency makes it easier for someone to notice the issue and push put a patch.
If it was standard to compare a dependency graph of the program architecture pre and post build, then you would catch these sorts of things right away. Supply chain attacks are not new and I imagine at least some companies have a process like this in place already.
It's been the case with npm and the likes for the past decade already, and indeed the past decade has been interesting with respect to the so called “supply-chain attacks”…
I fail to see how decentralised package sources can possibly reduce the chances of a supply chain attack (from outsiders). Now instead of one repo needing to be secure and up to date, thousands must.
Supply chain attacks are worsened if everyone lives at the head. Staying far enough behind that some brave (and hopefully small) project discovers the compromise of a repo for some dependency five layers deep before you re-pin to a new version is probably the best mitigation short of some permissions based model like Austral is working on.
Sorry, I don't quite see how this would protect against supply chain attacks. If an upstream dependency is back-doored, they just have to silently add their code in an otherwise reasonable sounding release, and now you will happily download that version, add it to your internal mirrors, and pin its version forever. Unless you actually read the diff on every update, which I think is impractical (although you're welcome to correct me), I don't see how this is buying you much.
Imo this is the missing puzzle piece (and the more important one for me personally) for software supply chain security, the other ones being deterministic builds and signed binaries.
And the real problem aren't even people trying to steal your bitcoins [1], you notice that and hopefully had not all your eggs in one basket, it's a (sometimes expensive) lesson in IT security. The much more serious threat are state level actors trying to backdoor secure communication channels, the breach will happen without your knowledge. One shouldn't expect that every nation will take the obvious and public route like the Australian government [2], simply demanding access. With enough resources it seems totally viable to backdoor just one deep dependency of some UI framework and circumvent all end to end encryption used by affected apps.
I hope distributed code review will get some traction not only in the Rust world, but in the whole open source universe.
Wouldn't a supply chain attack like this be much worse with Rust and Cargo because of the fact it's not just a single dynamic library that needs to be reinstalled system-wise, but, instead, every binary would require a new release?
reply