Security@ Notes

I went to HackerOne’s Security@ conference last week, and can vouch that it was pretty cool! Thanks to HackerOne for the invite and to Hired for leave to go around the corner from our building for the day.

My notes and main take-aways:

The name of the conference comes from an email inbox that every company should theoretically have. Ideally you’d have a real vulnerability disclosure program with a policy that lets hackers safely report vulnerabilities in your software. But not every company has the resources to manage that, so at least having a security@ email inbox can give you some warning.

As a company, you probably should not have a bug bounty program unless you are willing to dedicate the resources to managing it. To operate a successful bug bounty, you need to respond quickly to all reports and at least get them triaged. You should have a process in place to quickly fix vulnerabilities and get bounties paid. If hackers have reports sitting out there forever, it frustrates both parties and discourages working with the greater bounty community.

I was surprised during the panel with three of HackerOne’s top hackers (by bounty and reputation on their site). Two of them had full-time jobs in addition to pursuing bug bounties. They seemed to treat their hacking like a freelance gig on the side - pursue the quickest & most profitable bounties, and skip over low-rep or slow companies. Personally I find it difficult to imagine having the energy to research other companies for vulnerabilities after a full day’s work. But hey, if that’s your thing, awesome!

Natalie Silvanovich from Google’s Project Zero had a really interesting talk on how to reduce attack surface. It had a lot of similar themes to good product management in general: consider security when plotting a product’s roadmap, have a process for allocating time to security fixes, and spend time cleaning up code and keeping dependencies up to date. It’s easy to think that old code and old features aren’t hurting anyone: the support burden is low, the code isn’t getting in the way, and 3% of users love this feature, so why take time & get rid of it? Lowering your attack surface is a pretty good reason.

Coinbase’s CSO had an interesting note: the max payout from your bug bounty program is a proxy marker for how mature your program is. If your max bounty is $500, you’re probably paying enough bounties that $500 is all you can afford. They had recently raised their max bounty to $50,000 because they did not expect to be paying out a lot high-risk bounties.

Fukuoka Ruby Night

Last Friday I also went to the Fukuoka Ruby Night. I guess the Fukuoka Prefecture is specifically taking an interest in fostering a tech and startup scene, which is pretty cool. They had talks from some interesting developers from Japan and SF, and they also brought in Matz for a talk. Overall a pretty cool evening.

Matz and another developer talked a bunch about mruby - the lightweight, fast, embeddable version of Ruby. It runs on an ultra-lightweight VM compiled for any architecture, and libraries are linked in rather than interpreted at runtime. I hadn’t heard much about it, and figured it was a thing for arduinos or whatever. Turns out it’s seen some more impressive use:

  • Yes, arduinos, Raspberry Pi’s, and other IoT platforms
  • MItamae - a lightweight Chef replacement distributed as a single binary
  • Nier Automata, a spiffy game for PS4 and PC

Matz didn’t have as much to say about Ruby 3. He specifically called out that if languages don’t get shiny new things, developers get bored and move on. I guess Ruby 3 will be a good counter-point to the “Ruby is Dead” meme. Ruby 3 will be largely backwards-compatible to avoid getting into quagmires like Ruby 1.9, Python 3, and PHP 6. They are shooting for 3x the performance of Ruby 2.x - the Ruby 3x3 project.

One way the core Ruby devs see for the language to evolve without breaking changes or fundamental shifts (such as a type system) is to focus on developer happiness. Building a language server into the core of Ruby 3 is one example that could drastically improve the tooling for developers.

He also talked about Duck Inference - an “80% compile time type checking” system. This could potentially catch a lot more type errors at compile time without requiring type hints, strict typing or other code-boilerplate rigamarole. Bonus: it would be fully backwards-compatible.

I’m a little skeptical - I personally find CTAGs and other auto-complete tools get in the way about as often as they help. For duck inferencing Matz mentioned saving type definitions and message trees into a separate file in the project directory, for manual tweaking as needed. Sounds like it could end up being pretty frustrating.

Guess we’ll see! Matz said the team’s goal is “before the end of this decade,” but to take that with a grain of salt. Good to see progress in the language and that Ruby continues to have a solid future.