Discussion - Auditors, Sessions 3 & 4
summary
Panelists describe security work as time‑boxed security assessments that read code, run static analysis (Slither, Mythril), run fuzzing and taint/symbolic analyses to find business‑logic and economic issues. Teams report long queues and some firms raise rates ~30%; one long engagement finds ~15 criticals and ~20 high issues. Reviews recommend executable specs, unit tests, traceability and continuous engagement; audits never guarantee safety, they deliver prioritized findings and incident‑response support, and upgradability is a qualified feature.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 6:08Smart contract assessments
- 9:37Should we stop calling them audits
- 11:24What a security assessment report includes
- 16:25Engaging auditors
- 19:14Preparing for review
- 23:50User expectations
- 26:19Early design reviews
- 34:21Audit queue reasons
- 36:58Nation states and sanctions
- 41:03Code maturity
- 44:35Modularity challenges
- 49:30Auditor liability
- 56:39Reviews ≠ safety
- 56:59Upgradability feature or bug
- 1:01:13Closing remarks
related talks
27mSecurity: The Thing That Everyone...
49mPragmatic Approaches To Building Secure Software
44mApplication Security: Everything we know is wrong
01h 00mWorkshop
01h 10mAuditors' Workshop: What You’ve Wanted to Ask an Auditor, but Were Afraid To Ask
41mAim-Ready-Fire
33mBattle Tested Application Security
38mDevSecOps Panel "AppSec Would Never Catch Me"