Thread by @mreavey

I thought I’d know all the stuff in this talk and just went to see @Lipner. But nope...Dr Lipner is still dropping new knowledge. #bhusa @SAFECode

If you’re not big enough to “do everything” this talk is for you. My key points:

1. Have a vuln response process, use it to learn, and fix more than just what’s reported.
2. Devs are accountable for writing secure code—don’t “test it in.”
3. Do RCAs

4. Track SDL in the mainstream bug tracking workflow you track other bugs in.
5. Have a bug bar — exploitability matters.
6. Secure your 3rd party code. If you ship it, it’s your problem.

7. Do the “free” stuff—use secure libraries, set secure compiler flags, ban unsafe api’s, etc.
8. Inform and motivate your developer population. (Context is powerful)
9. Then you can train—the more targeted to your environment the better.

10. Build security into design—or it’ll be expensive or maybe impossible to fix quickly. Threat Modeling is your friend.
11. Don’t roll your own security features if security isn’t your core biz.
The platform can be your friend.
12. Minimize your attack surface.

And after all that — *now* you can start worrying about code level vulns proactively. But so much goodness to be had before this. And even here, lots of free tools exist to help.

So the good Dr just shared at least dozen ways that SDL, indeed, doesn’t have to break the bank.

Oh—and as a final point: A bug bounty is a *great* compliment to / component of SDL and sec response. But not a replacement. Buying your way out of insecurity bug-by-bug will probably break the bank.