Building the Gulp Snyk plugin, an interview with Doug Wade

Doug Wade is a Senior Front-End Engineer at Indeed. Doug built the wonderful gulp-snyk plugin, which lets you seamlessly include Snyk in your Gulp build process. We were really excited to stumble upon the plugin, so we wanted to talk to Doug to hear a little more about it.

Why did you first start using Snyk?

When I was at Node Summit last year as a mentor, I had the chance to catch Guy’s fantastic talk and live demo of how to exploit some security advisories with minimatch that I had been ignoring on my projects, which was both enlightening and scary.

During the happy hour, I talked with Guy about why I’d make the switch from nsp to Snyk, and he told be about (what I consider to be) Snyk’s “killer feature”: snyk protect.

For a long time, I’d been bothered by publishing .nsprcs to Github to get my Travis builds to pass. For project’s like React Server, it felt like I was publishing a manifest of vulnerabilities that attackers could use to exploit sites like www.redfin.com. That’s the opposite of what I was trying to do!But realistically, that’s how it had to be.

Early on in npm’s history, Isaac Z. Schlueter (inventor and CEO of npm) made a decision that I think is core to both the explosion of npm packages available and to making access to open-source development on npm the most accessible way to start contributing. Isaac decided to avoid Java-style dependency hell by giving every dependent its own independent copy of its declared dependencies.

This means that for a single developer writing modules on npm—like I am for a lot of my open-source modules—I can iterate very quickly by changing and upgrading my dependencies without having to worry about my customers being stuck on an old version while they wait for a consistent dependency closure.

The tradeoff is that for application developers that need to remove vulnerable dependencies from their dependency closure—like I am when I go to work—it’s not enough to upgrade your direct dependencies; you also have to make sure that every dependency upgrades to the safe version. After I got a tongue-lashing from a developer that I very much respect for submitting an issue and PR to update a vulnerable dependency in a Node Foundation project, I knew that the nsp method of nsprc’s and waiting for fixes to percolate through the ecosystem was unsustainable.

Snyk’s approach fixes this by patching my application through a postinstall script, so I don’t have to wait for the change to percolate through the ecosystem, and my manifest is no longer a list of vulnerabilities that currently exist, but instead a list of vulnerabilities that have been fixed.

Why did you end up building gulp-snyk?

I’ve been developing on Node since the 0.8 days, mostly because it was the only development environment I successfully set up on my Windows machine back when I was first learning to program. As such, I have a bunch of modules still laying around that still use Gulp as their build system.

One of the things I believe about build systems is that their primary purpose is to make common tasks standard and discoverable. Rather than expecting new contributors to discover tasks spread out across a package.json and a gulpfile, I wanted a single list of tasks. There wasn’t a lot of boilerplate to write my Snyk tasks in Gulp, but there was enough that I didn’t want to copy-paste it between projects, so I published it on npm.

I did the vast majority of the development in two evenings after work. It turns out there’s an undocumented programmatic API which gulp-snyk uses to run the test target.

I’ve opened an issue to try to coordinate with Snyk about this, but for me, this highlights one of my favorite things about working in a dynamic language. I didn’t need to know anything about Snyk. I could just fire up a REPL (Read-Eval-Print-Loop) and start poking at stuff.

How are you using gulp-snyk today?

I’m using gulp-snyk to protect Clefs and name-suffixes, and I have plans to add it to React Server. I’m using Snyk for 17 of my node modules, with plans to expand it to all 33 of them.

Thirty-three NPM modules! What drives you to contribute like that?

I believe that we as developers have an ethical obligation to contribute back to the community because of how much we gain from it. Honestly, though, I think that a lot of what motivates me is profoundly selfish.

When I write a PR against Node or npm or Lerna I get a chance to explore the code of—and get a code review from—some of the best and brightest minds in software development. When I post a new project I’ve written for the first time to Reddit or Hacker News, I get feedback on API design and architecture and documentation that is more acutely attuned to my particular area of expertise than what I get at the office.

In some ways, I suppose it is also my form of not pulling the ladder up after myself. My career has been built on a foundation of working with and learning from free and open-source software (FOSS). So in a very real and meaningful sense, without FOSS I wouldn’t be where I am now.

On that note, if people want to help contribute on gulp-snyk where should they go?

The gulp-snyk plugin is available on npm and you can install it with npm (npm install --save-dev gulp-snyk) or yarn (yarn add --dev gulp-snyk). If anyone wants to help contribute, the code is available on GitHub.