Skip to content

Details

We hope that everyone is doing ok during these strange times. Since regular meetups are unlikely to happen anytime soon, we’re going to run virtual meetups to give a space for the community to connect.

We’re excited to have Clint Gibler (@clintgibler) from r2c who will show us how to enforce code patterns by writing lints for Ruby using Semgrep, a static analysis tool.

This meetup will happen over lunch. After the talk and Q&A, we’ll break out into groups of 3 to 6 people to connect and discuss topics of your choice.

RSVP to get access to the Zoom Link™.

Looking forward to seeing you all!

---

✍️ Abstract

Every code base comes with a set of built-in expectations: do things this way, don’t do things that way. There are some great tools with out of the box checks you can use, like Brakeman for security and RuboCop for linting and quality.

But what if there are code patterns you want to enforce that are unique to your codebases? Existing tools won’t have these checks, because they’re not general Ruby or framework patterns, they’re specific to you. You can augment existing tools with custom checks, but this generally requires becoming familiar with abstract syntax trees (ASTs) and the tool’s architecture. Feasible, but it takes some work.

But what if you could write lints for Ruby that are essentially just Ruby, no complicated upfront learning required?

In this talk, we’ll show how to do just that, using Semgrep (https://github.com/returntocorp/semgrep), an open-source, lightweight static analysis tool.

We’ll discuss how to:

  • Search for Ruby code using patterns that are basically just Ruby (with a few helpful abstractions)
  • Find and block security bugs from entering your code
  • Scale your team’s productivity: automate the things you always comment in code reviews, and help onboard new engineers with custom checks that teach them calling conventions. Replace internal docs that people don’t read with checks that scan every PR
  • Iteratively explore code bases, finding potential code spots or anomalies; for example, functions whose return value should be checked, or before_filter’s that should be consistently applied

You’ll leave this talk with another open source tool in your toolbelt for helping you and your team release higher quality, more secure code, faster and easier.

👤 About the author

Clint Gibler (@clintgibler) is the Head of Security Research for r2c, a small startup working on giving security tools directly to developers. Previously, Clint was a Research Director at NCC Group, a global security consulting firm, where he helped companies implement security automation and DevSecOps best practices as well as performed penetration tests for companies ranging from large enterprises to new startups. Clint has previously spoken at conferences including BlackHat USA, AppSec USA/EU/Cali, BSidesSF, and DevSecCon Seattle/London/Tel Aviv/Singapore. Clint holds a Ph.D. in Computer Science from the University of California, Davis. Check out tl;dr sec, Clint’s newsletter that contains summaries of artisanally curated, top talks and useful security links and resources from around the web. https://tldrsec.com/

Intended audience: Intermediates, advanced

Length: 45 minutes

You may also like