Wallet attribute: Wallet Supply Chain for security libraries

[v1rtl]

Supply chain matters, and so do which security libraries are used by a wallet. If they are not audited and aren't inspected by anyone, this opens exploit possibilites.

Most wallets (and their SDKs) use Noble, though not all yet. Some roll their own crypto (for example WalletConnect, until recently used stablelib instead of Noble, which is not audited nor popular).

It is difficult to check which libraries closed source wallets use though. So I guess for those they could be left as N/A.

[polymutex]

My opinion: Yes, it is critical for wallets to use security-audited security libraries... but difficult to implement such an attribute in practice.

I believe an attribute that evaluates this shouldn't "pick a winner" by pre-selecting a specific library as valid and treating other libraries are either unsatisfactory, or as "the burden of proof remains on the wallet team to prove". Additionally, while it's easy to point to examples of wallets doing it wrong, it's quite difficult to prove that a wallet is actually doing it right, because the task of completely verifying this throughout a wallet's dependencies is quite complex.

Given that Walletbeat's volunteer contributor base aren't security auditors, and that wallet teams themselves may overlook some of the security library dependencies they're taking on (this can easily happen by accident these days given the large dependency tree of modern software), how should this be asserted in practice?

Another question is: what is the boundary of "security libraries"? For example, for browser extension wallets, surely the browser's own TLS implementation shouldn't be in scope of this attribute, yet the wallet extension definitely relies on it for cryptographic correctness. So there needs to be some definition of which security libraries are in scope.

At a minimum, it seems to me like an attribute for this would need to function as follows:

• A wallet must have at least one third-party security audit
  • The scope of that audit must encompass security-related libraries that are in the dependency tree rooted at the project's own direct dependencies (e.g. package.json for JavaScripty projects, similar for other languages), and:
  • That audit either:
    • ... includes auditing the code of those security-related libraries too, OR
    • ... The auditor's task includes verifying that all such security-related libraries have all been security-reviewed
  • And the wallet's set of security-related dependencies hasn't changed since the last audit that meets the above criteria.

All of this is quite difficult to verify, and may require all wallets to perform a fresh security audit with those constraints in mind as this may not have been in the scope of their prior security audits. So this seems like a large cost to ask of existing wallets.

In conclusion, this seems... difficult to support in practice. Do you have ideas on how to evaluate this fairly with a lower burden?