You have to trust software to spend your coin when you spend it.
Risk and trust can never be zero, but it is all about reducing your risk to a minimum.
You need to weigh the risk with the cost of mitigating the risk. Creating a 7 of 7 multi-sig private key should be less risky than creating a private key that requires one signature to spend coin (assuming you can easily replicate the procedure to keep each private key secure). At a minimum, this would increase the time it takes you to sign transactions and would increase the cost you pay to get each transaction confirmed. You could further reduce your risk by storing each of the 7 private keys in different countries, each located in a different continent; assuming you are acting as an individual, it would cost you thousands of dollars each time you want to spend coin because you would have to travel to 7 different countries to do so.
Even if I have the most malicious software wallet in existence on my airgapped computer, there is nothing it can do to steal my coins. If it signs a transaction to the wrong address, for example, I can easily pick that up before moving the transaction to my live computer to be broadcast.
This is not entirely true, see
this thread. In addition to leaking your private key, it could leak additional information.
In a simplistic example, the k value could be 20 digits, the malicious software could always have a value of xxxxxxxxxxxxxx[13 digits that is known to the author of the malicious software]yy[the index of a list]zzzzz[the actual message]. The x values would be one of a set of known values allowing the attacker to easily filter possible k values. The y values would be the index in a list, with the entire list being the entire message, such as your seed.
I just generated a seed: [concert, eyebrow, peasant, exile, fold, gather, sense, drastic, twice, clip, orchard, defy]
The y and z values could be 02peasa to correspond to the 2 index of the above list and the first 5 digits of the seed word. After this happens many times, the attacker would have enough information to easily brute force your entire seed.
Or malicious software could simply use a k value known to the attacker, the attacker could check all unconfirmed transactions for that k value, and create a double-spend transaction with a high transaction fee before your transaction is confirmed.
) 
... the setup you are using has a really good mix of "randomness", security and convenience. I like it. 
