Security Static Analysis - Avoiding an Angry Mob of Engineers
summary
Static analysis reliably finds implementation bugs but misused tools cause notification fatigue: lightweight linters belong in the IDE, heavyweight interprocedural analysis runs centrally or nightly, and using both as a mosaic catches more issues earlier. A real-world run produces 55,000 findings on Elasticsearch—untriageable noise. Buy engines that let you edit rules, test on your actual codebase not goats, integrate findings into PRs, and separate UX for developers versus security reviewers.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 2:44Understanding static analysis
- 4:27Five categories of analysis
- 8:41Strengths and weaknesses
- 17:09The concept of alert fatigue
- 17:53Factors of fatigue
- 22:48Four types of issues
- 23:08Simplistic analysis tools
- 23:27Tool selection and scaling
- 31:25Deploying analysis tools
- 34:05Advocating for better tools
- 36:47Audience differentiation
- 37:29Tailoring tool UX
- 38:52Vendor evaluation strategies
- 41:04Customizing rule sets
- 41:40Managing rule customization
- 45:07Quality over quantity
- 48:43The problem with check boxes
- 49:40Tool evaluation best practices
- 51:53Conclusion and Q&A
- 55:13Final takeaways
related talks
39mPractical Static Analysis for Continuous Application Security
50mPractical Advanced Static Analysis
33mBattle Tested Application Security
44mStatic analysis as an additional barrier against bugs
54mA Shock to the System Static Analysis for Real AppSec
25mTypes & static analysis are good in PHP
44mUsing Static Analysis Tools to Become A Superhero Programmer
45mBringing Security Testing To Development: How To Enable Developers To Act As Security Experts