Wallets and software supply chain security

Transcript

[music] >> Hello everyone. The sound, yes? My name is Pol Mimetex. I work on Wallet Beat, which is trying to compare wallets and we look at various aspects of wallet security, one of which is how seriously they treat the issue of software supply chain security. Why should you care about software supply chain security? Well, there's a pattern of multiple compromises of mostly NPM packages that have that make their way into eventually crypto software and this has led to loss of funds. And in case you missed it last week, the largest hack in computing history happened in which from the Binance article that they posted of just a few days ago, they blamed the very first point of attack as being a software supply chain attack

in what they who they call engineer A in in the incident. You as a software developer, I'm assuming that the audience is mostly software developers, are part of this chain of the software supply chain and every link in that chain, every edge is at a risk because it is a dependency on someone else, some other organization that has its own security vectors and compromise. And so whenever you extend it, you need to make sure that you're doing it safely. So if you do need to use a dependency, you have to make a choice about how you treat it safely.

There's multiple approaches. You can avoid it entirely or you can try to mitigate it by containing it or locking it down. Avoiding it is obviously the better option if you can. It's not always appropriate, like don't write your own crypto library of course, but for like simple less simple stuff like left pad, like don't don't take a dip on those things if you can avoid it. There's still some obvious ones that you cannot really avoid, like you know the the basic HTTP library, VM, those types of things, those are difficult to get rid of. So if you can't avoid it, then you can at least contain it. Containment means being able to isolate the effect of having that dependency. One of the things I want to call out here is a technology by by consensus in that is used in Metamask called Lava Mode, which

allows you to isolate set of JavaScript objects and reachability of the JavaScript runtime that each of your dependencies has access to. So, for example, one thing you can do with this is you can have the cryptographic stuffed library that touches the private key never be able to access the network, and you can have the stuff that touches the network never be able to access the private key. And the only thing in the middle is kind of your your own business logic that has no external dependencies, and therefore you are mitigating the attack surface that each of those dependencies can have. Uh outside of the JavaScript ecosystem, there's a few other options. You can also do process sandboxing, which doesn't come up often in wallets, but you know, for like back end of wallet infrastructure, you can use it.

And sandboxes on their own are only as effective as the policy that you configure them as. So it's not like a on off switch. You need to configure them to like set the policies of what they can and they cannot access. AI makes this a little bit easier, but it's still maintenance that you have to take on. It's not just adding a line in your package.json. And then the last option you have is to locking it down. So there's a few little tricks, but none of them are perfect, but the the added effect of all of them together is still quite significant. So some of the obvious ones are things like removing installed time scripts as much as possible. You can use lock files to um prevent the registry compromise of uploading different packages than the one that the offers intended. You can add a dependency age

gate, which means that you never use a dependency that's been published too recently, and you let automated scanners pick it up to see if there's been some compromise that's been pushed to it before you actually use it in your own project. And then there's a six store provenance information that I'm not going to get into now. Six store is kind of like the web two version of this answer, and there is no particular reason not to use it other than the centralized dependencies that it adds at build time. But it is still the best that we have right now. So there is multiple components of it. The main one that you would interact with is six store. Six store is a system by which you can sign your builds and publish their signatures into what they call a tamper proof transparency log because they don't want

to use a blockchain, but it is a blockchain. And it integrates with GitHub CI, which means that you can have GitHub build your sign it, and only it has the ability to that produce the signature. No employee laptops being compromised is a problem at this point. And so that protects you against registry site tampering, protects you against employees laptops being compromised, and also split view attacks where only some employees have some compromised version of package and others don't because there's a single source of truth about which which versions of which package exist and what is their signature.

And then SLSA is the way in which you can prove your compliance to others. So it is kind of like a a maturity framework for software supply chain security. It has three levels kind of like the L2 beat stage system where level one is you have a documented build process that eventually at the end signs your build. Level two is you run that on trusted infrastructure that is not controlled by any of your probably lower opsec individuals within your company and it's instead running in a TEE somewhere in a data center which adds centralization but still also adds safety.

And level three where you do the same but also you ensure that there is no possible way for one build to affect others so that they're all fully isolated from each other which is yet another way of hardening. You can look more about these two technologies more at Uh there's a lot more to software supply chain security that I don't have time to to cover in a lightning talk but I'm just showing them here if you want to think about even more ways in which you can be compromised. Uh the list does not end. You may not be interested in software supply chain security just the name is very boring but software supply chain security is interested in you.

Thank you. Do I have time for questions? >> Hello. Can we put the questions up on the stay on the screen? There's only one question. Is open source code enough to ensure wallet security? >> Absolutely not. I think it's a basic requirement but it's definitely not sufficient. There's a saying I think from Linus Torvalds perhaps that says that open source means you have way more eyes looking at the source code and that's true but it's not the entire story unfortunately. All love the hacks that I showed earlier are all in open source NPM packages. So obviously, this is not sufficient.

Any other questions? >> [music]