This is the same style of attack that took 1.5B from Bybit ~1yr ago.
Fundamentally: There is no way to lock webapps to reproducible builds.
Except: IPFS could do it but IPFS has been very very poorly maintained.
I published IPFS-boot ~1yr ago and its a simple idea:
1. deploy a webapp bootloader using something immutable like IPFS
2. bootloader is basically react hot reloading except user agrees what to load
3. bootloader polls a mutable list of app updates and user agree or disagree each update
Now the bootloader has a static content addressable URI but it can also do updates. TBH I think IPFS may be a lost cause but something needs to take its place and this idea is transferable to whatever that is. https://github.com/rhodey/IPFS-boot
You’re right, but the risk here could be reduced significantly by not loading dozens of third party marketing, analytics, and tracking scripts; one of which was supply chain compromised in this case.
Of course, that goes against commercial interests.
The reason subresource/web application integrity is not more commonly used is that there is no plan to actually do anything with it.
How are you going to verify your thousands of dependencies, some of them obfuscated/closed source? And if you can’t, what does integrity buy you?
Would you rather: lose $1.5BUSD or: do dependencies better?
> Fundamentally: There is no way to lock webapps to reproducible builds.
One could absolutely use subresource integrity to lock one’s reference to a vendor’s subresource to a specific version. That’s what it’s there for.
That's only meaningful if you are loading resources from a separate domain (e.g., a CDN or another subdomain).
There is no way to, for instance, only allow updates to a PWA from files signed by an offline key.
This only defers the issue to trusting that index.html is always trusted.