The point of the zero trust model is that while you as a normal person may trust someone, everyone has the means to verify without having to trust it.

If the devs have written formal models for the system and verified that with a proof solver, you have a reasonable assurance the code matches the spec and that the spec is at least consistent with itself.

If the devs have Property Based Testing suites and fuzzing tools to automatically search for vulnerabilities in the code/spec or introduced via changes, you have reasonable assurances that the development process is thorough and likely won't haphazardly introduce a vulnerability in a change (and actively squash potential vulns that are discovered).

If open source security auditors (who's reputation is core to their business) regularly and publicly auditing the platform, you have reasonable assurances that on top of the code being reasonably secure, the spec itself doesn't have any glaring flaws in it.

If bug bounties have red teams regularly trying to discover exploits, you have additional assurance that if a bug exists, it'll likely be discovered, ethically reported, and resolved before being exploited.

Point being, zero trust isn't about not having trust, it's about not having blind trust. These should be the expectation for all high value software. We should be able to trust in the engineering of software systems like we trust in the engineering behind buildings and bridges.

---

Now with regard to this specific hack, CreamFi failed to do 2 out of the 4 of those things mentioned above and their security auditor only provided a very cursory/high level audit. Their report was not confidence inspiring and should have been a red flag to users to not use the service.

Now compare this with the org they forked their code off of. Compound Finance maintains a formal spec, uses formal methods, has a bug bounty, and receives regular, in depth security audits. CreamFi chose to make changes to a codebase after abandoning the security tooling (formal spec was no longer maintained) and protections that were in place with Compound Finance's code.

Any moderately competent technical user should have been able to tell that CreamFi was (like many other knock-off DeFi platforms) a ticking time bomb. We as a software engineering community however still have a long way to go in making these qualities/flags accessible to normal users.