@Barry Unfortunately, the authors do not provide key-takeaways for reducing exposure to vulnerabilities that have not yet been discovered. They only provide defense approaches for the attacks they list in the paper.
@cipherix Your points make sense; however, they are not a guarantee even if followed religiously. For instance, it does make sense that one should only interact with contracts that have been audited. However, in practice, many audited contracts change from time to time, and these changes are often not audited. Tracking which dependencies have been audited and which have not is tricky and time-consuming, as it has a cascading effect (certainly deserves proper tool support, which is lacking). Formal methods are an interesting approach, but it would only work if all the third-party contracts one interacts with are also formalized, which is not feasible in practice (or unrealistic to expect). Formal specs can easily be out of synch in regards to a constantly evolving code base; also, they have a very heavy upfront investment in time and effort. Plus, formal specs, if done incorrectly or if found to contain mistakes, also pose a threat on their own.
So, in summary, I think the way to go to reducing exposure to unknown vulnerabilities is to have a contingency plan, aided by extensive use of defensive programming techniques (e.g., safety guards in the code, such as emergency shutdowns and invariant checks) and runtime monitoring as a means to unveil suspicious actions. Some of these have been discussed in more details in another thread: What constitutes a good test suite?. Let me know of your thoughts 