Bringing Security to Your Open Source Project
summary
Small projects get concrete steps: publish a security@ email and thank reporters instead of legal threats, run automated checks (CVE checker, static analysis like Coverity or clang), and automate release-time scans. Hands-on learning uses a Kali USB stick for live tools, fuzzing (American Fuzzy Lop) that often finds issues in about half an hour, and pen tools like Metasploit or Burp. Run security hackathons with ground rules, fast VM resets, issue trackers, checklists and tests so experiments actually produce fixes.
AI-written summary · about
chapters (36)
- 0:00Introduction
- 1:02Warranty disclaimer
- 1:48Terris background
- 3:09Encourage existing security researchers
- 3:35How to report security bugs
- 4:29Do not send a cease and desist
- 5:30Give feedback
- 6:20Dont immediately say its not a security issue
- 7:11Bugs are bugs
- 7:45Bug bounties
- 9:56Terris favorite story
- 11:29Encouragement
- 11:53Where do people start
- 12:27The problem with PhDs
- 14:32Courses are archaic
- 16:05Hackathons are wrong
- 16:31How do you run a hackathon
- 17:10Setting ground rules
- 18:17Fast resets
- 19:23Bug tracker
- 20:09Beginners
- 21:09Threat Modeling
- 23:44Learning to break websites
- 25:14Security tools
- 25:52Hackathon toolkit
- 26:41Fuzzing
- 27:46Static Code Analysis
- 28:50Fuzz Testers
- 29:51Vulnerability Checker
- 30:55Security Best Practices
- 31:24Checklists
- 33:15Automation
- 33:55Call to Action
- 34:25Fun
- 35:05Steve Krug
- 36:49Outro
related talks
35mOpen source security: Opportunity or oxymoron?
13mFreedom of Security
38mFinding Security Issues in Open Source
49mImproving FOSS Security
31mSharing Security Secrets: How to Encourage Security Advocates
43mThe Importance of Developer Tooling to Make Open Source More Secure by Default
01h 03m“Secure Coding Best Practices: Your First Line Is The Last Line Of Defense (2 of 2)”
27mHow to Start Security Testing Without Fear