Here's my opinionated philopshy on external audits and security providers. This is very specific to our current position - it's not the approach for every project.
We should never rely on external partners for our security. External partners provide additional checks, but if they find a critical, we aren't doing our job as we should be. If we miss something real and anyone downstream catches it, we should prioritize adjusting our processes to ensure that that category of issue is caught internally, every time in the future.
Some parts of the code matter more than others. We have a contract architecture that means that big pieces of our system of contracts can't lose user funds from a bug, and thus have lower security requirements. Other parts have well known interfaces which mean as long as that one or two guarantees hold, the rest can do minimal damage.
This both means that we can do the smaller areas without audits, and should sometimes stack external partners onto the more critical areas when they change.
Our security philosophy is based around having multiple layers to catch safety problems.
This carries over to external security partners as well. We shouldn't just focus on audits as the only layer of external help.
Instead we should also consider individual private audits, code contests, fuzzing, bug bounties, and maybe occasional formal validation, and or economics sims when the code is right. Not all approaches are right for all code changes.
In general, a stack of layers each with 75% odds beats a single layer with 90%.
Costs in DeFi security follow an exponential curve. Moving back one cost tier has massive effect on price paid. Effectiveness does not always follow price either.
We have a super power in that we have the ability to evaluate external security talent after having worked with them. This means we aren't stuck with going with only brand name auditors and the high expense they bring.
The best way to know how good people are is to work with them. We should do small projects, spread over time, with many different vendors and individuals to see who is adding real bang for buck.
At times we will want to have multiple teams look at the same code. As long as these multiple looks are cheaper than a high dollar audit, it should both cost less, give more security, and give a good understanding of the strengths and weaknesses of those teams, which will better inform future selection decisions.
We make a lot of changes to our code. We are fundamentally not a point in time, one big release every five years project like uniswap, etc. We also want to move to having a short latency between starting new features and having them live.
Because of this, we want to build towards having a large amount of underlying tooling and checks on every PR and commit. This should include linting, unit tests, fork tests, fuzzing, and perhaps some formal verification one day. The idea is that our every code commit will have underneath it an almost audit equivalent of security review, in 30 minutes, automatically.
The large number of unit tests and fork tests around OUSD allowed our rapid development of OETH, since with every commit we could be sure that our behavior matched the previous contract in the same situations, and we could focus just on the new situations.
Excellent points, agree with all of them.
1 thing I would add is that it is worth following a couple of Twitter accounts of smart contract security reviewers. I found those accounts on Twitter extremely helpful. Sometimes they share useful gas optimizations, or common contract vulnerabilities, current exploits of a protocol. Have put together a Twitter List. Others please add your own accounts to that list and if you want follow it.