Per the guidance given in the security audit guidelines, I am not sure the code properly clears the private key after it is loaded. Not seeing any Try statements in the signTransaction.py so I suspect it may need to be worked in.
Private Key Management
You should minimize the code that works with private (ECDSA, RSA, etc.) or secret (HMAC, AES, etc.) keys. Importantly, you should always clear the memory after you use these keys. That includes key data and key objects.
Leaving parts of private or secret keys lying around in memory is not a security issue on its own because there is no easy way to extract the content of RAM on the chip. If a key is left in RAM by an app, another app will not be able to access it.
However, if the key has not been properly erased, a security issue could lead to the leak of this key, even if it is not used anymore. An attacker able to read arbitrary memory from the app, or execute arbitrary code, will be able to read the content of the stack segment, hence the parts of the key which have not been erased.
A common (and wrong) way of doing this:
uint8_t privateKeyData[64];
cx_ecfp_private_key_t privateKey;
os_perso_derive_node_bip32(
tmpCtx.transactionContext.curve, tmpCtx.transactionContext.bip32Path,
tmpCtx.transactionContext.pathLength, privateKeyData,
NULL);
cx_ecfp_init_private_key(tmpCtx.transactionContext.curve, privateKeyData,
32, &privateKey);
explicit_bzero(privateKeyData, sizeof(privateKeyData));
// (later, after privateKey is not needed)
explicit_bzero(&privateKey, sizeof(privateKey));
In the happy path, the previous code will correctly clean the memory once the private key is initialized. Note, however, that this code fails to protect private key in case some system call throws (for example cx_ecfp_init_private_key). Correct code should wrap the clearing in TRY { ... } FINALLY { explicit_bzero() }.
There are additional items that could be composed into a checklist and the clearing of the private key would be one. It could be a moot point if there was no potential for error in the script block but idk solar flares or some shit.
Interestingly, the BOLOS guide cites one of my favs (which I have set up on my ledger) as a reference point which is SiaCoin and Cardano for the more paranoid.
Again, code audits is really my expertise but I am generally able to follow the gist of code that is unfamiliar. Being that it is python, it's actually more of what I am accustomed. I would also advise looking at the getPublicKey.py that Sia has as I noticed the hive code is significantly shorter. (205 vs 69 lines) I am not sure if they performed additional data validation that we would want to try to replicate. Or maybe the Hive code does the same with less lines. Sure that would be within the realm of possibility.
They've included some UX macros in there so may have to follow the trail of breadcrumbs to find where they are defined. It's mostly Greek to me as this is pretty new but hope, even so, I provided some degree of meaningful insight.