Security is hard, but we can't go shopping
summary
Ruby and Rails are seeing a surge of vulnerabilities: three Ruby releases in six months, 13 CVEs so far this year for Rails, and concrete incidents like Bundler's first CVE and the rubygems.org breach. The talk gives actionable choices: whether a bug allows unauthorized data access or denial‑of‑service, how to follow responsible disclosure, contact addresses and PGP for gems, when to ship a patched gem or fork, and a low‑traffic security mailing list that actually exists.
AI-written summary · about
chapters (26)
- 0:00Intro
- 0:43Ruby security releases
- 1:41Rails security releases
- 2:56wait what's a CVE?
- 3:11common vulnerabilities and exposures
- 3:38numbering authorities
- 3:49apple adobe
- 5:10minaswan security? vulnerabilities?
- 11:09a small cost to mitigate risk
- 12:03without it failures are catastrophic
- 12:52disclosure liability lawyers
- 13:57updating is hard work
- 14:24update sleep well at night
- 14:45reporting security issues
- 16:06responsible disclosure
- 17:13responsible clever, triumphant hackers hate it
- 22:06ask yourself two questions
- 22:43can I disable something for other people?
- 25:07look for a security policy email in gemspec email on github
- 26:38work together have empathy
- 29:54your gems are security vulnerabilities waiting to happen
- 30:26unless your code is perfect (and you want to buy this real estate in Florida)
- 31:41medium
- 34:45on a team security address PGP key disclosure policy
- 35:05ecosystem mailing list for announcing security issues and releases
- 35:47questions?
related talks
40mSecurity Is Hard, But We Can't Go Shopping
42mSecuring Your Rails App
29mGem install: What could go wrong?
31mA survey of recent RubyGems CVEs
37mThe Evolution of Rails Security
36mUsing Ruby In Security Critical Applications
54mSecure Programming with Ruby on Rails
20mDefending Against Data Breaches, as a Practicing Ruby Developer