Developer Wietse Wind commented on the SOL attack situation.

Developer Wietse Wind on twitter commented on the SOL attack situation:
SOL vs @XummWallet
As far as I know it’s still not certain how the SOL attack happened. There are a couple of theories, the two most shared/speculated: 1. Faulty crypto (signing) implementation. 2. Generated keys compromised (sent in plain text over the wire after generation)
Further he continued:
While it’s never 100% possible to say a wallet is not at risk (not even for hardware wallets) of any security issues, I feel it’s safe to say that neither one of the speculated issues apply to Xumm. We feel we are doing a better (more transparent) job than the wallets involved.
The crypto parts (and many other relevant components) of Xumm have been audited. The audit is still ongoing. There are some interesting findings, things we can improve. But overall no high risk remote exploitable, nor mass exploitable things found.
We’re in the process of making some improvements after which a re-audit will take place. We will publicly share the report after the audit. The audit that has been done is VERY thorough compared to other non custodial software wallet audits we’ve seen so far.
We are doing this because we want to be responsible, transparent & because we want to verify our own work. Not to check some boxes, but because we want to sleep well, knowing that many people rely on us. Because we want to improve. Security is never finished. We’re never done.
Of course, this doesn’t mean there can’t be anything wrong with Xumm. However: security is our #1 (which the auditors could see). We’re always improving. Smarter crypto people looked at it. And (big difference with the SOL wallets involved): @XummWallet is open source (!)
This means that anyone who wants to verify, or audit themselves, can do so. We have nothing to hide. We want to improve. The other speculation is a logging/debugging/monitoring tool captured generated keys and sent them over the wire. A wild situation, if true.
This speculation could very well be true, but there’s no easy way to verify with the SOL wallets involved not being open source. Here we can say with 100% certainty that this will not happen to Xumm. We don’t collect telemetry. We hardly store anything.
We don’t monitor user activity & don’t send logs home (except for crash logs, so we can fix whatever needs fixing, but they don’t contain sensitive information). We sure as h#ll don’t send secrets home. We minimize 3rd party dependencies & sandbox their connectivity.
The biggest threat is end user key management. I would like to discourage using the same secret in multiple wallets. Don’t port your account. This narrows down the search if something happens. Don’t take your secret from Wallet A to Wallet B: there’s no traceability that way.
We’re horrified with the thought that users generated a secret somewhere (where it was compromised) then to take that secret to another wallet. After the generated (compromised) keys were abused, the new wallets were quickly blamed (as could be the case in this the SOL saga).
It would be quite unbearable to have to defend your wallet, spending so much time and effort on security, finding out that another wallet before (or after) you actually leaked keys resulting in massive losses of your users. Non custodial key portability is great but also a risk.
Of course we won’t remove the feature to import secrets to Xumm, and we can not and will not prevent Xumm generated XRPL keys to be imported elsewhere, but please don’t. Every time you enter your keys you’re putting them at risk again and continue doing so at yet another place.
Finally: if you want to make sure you don’t accidentally leak or port your keys, consider getting a hardware wallet that plays really nice with @XummWallet and the XRP Ledger for your higher value accounts.
(I’m not trying to take advantage situation)