How Voltos Uses Snyk to Secure Their Own Security Product

This is a guest post from Glenn Gillen. Glenn is one of the co-founders of Voltos, a service to help you securely manage your apps and service credentials, and is a co-contributor to the online course Tiny Security Wins: Quick steps to secure your dev environment. Previously he ran the add-ons ecosystem at Heroku and is an active investor in early-stage developer tools startups.

Most companies publicly claim that “we take our customers’ security very seriously,” mostly because to say otherwise is bad PR. For any company who is building a security-focused product, it’s a mantra everyone on the team needs to live by as failing to do so will ultimately erode the customer trust and run us out of business.

At Voltos we help developers manage and share their app’s credentials and configuration with their team and across their infrastructure. Losing focus on security compromises both our customers and us, so it’s not something we’re willing to take any chances on. And some early infosec lessons I learned were not to assume you’re the smartest person, don’t assume you know all the answers, don’t assume you’ve covered all your bases, and above all else don’t be afraid to ask for help.

Watching your back with Snyk

We do a pretty good job at keeping across the latest CVE announcements when they come out, patching quickly, testing, and deploying the change to production. Anyone who’s tried to do that knows it can be a heck of a lot of work, though. And with a sprawling ecosystem of nested dependencies pulled in via the Node, React, and Ruby communities the effort required only continues to grow. Combine that with the fact it’s not a job a single person or team within the company is 100% dedicated to, and it’s easy to imagine how something might slip past.

And slip through things have, like the medium severity remote memory exposure vulnerability pictured before.

This workflow also assumes that being across all of the CVEs means you’re as secure as can be. The truth is that about 85% of the npm/node vulnerabilities in the Snyk database had no announced CVE!

It took us less than five minutes to sign up Snyk, run a scan against our most critical apps, and find a problem. A single-click to create a pull request (including instructions on how to resolve the issue! ?). We were sold immediately.

A seamless part of the workflow

The best tools are the ones that either fit silently into your workflow or are such an impactful improvement to your productivity you adapt your workflow. Anybody who has tried to use PGP with their email will have a sense of what using a security-focused tool usually means for your workflow. It’s a massive pain.

What we’ve loved about Snyk is it’s invisible.

Every single pull request is automatically checked for vulnerabilities using the built-in GitHub integration. Given we open PRs early to discuss new features, it means new potential vulnerabilities are identified the moment they are introduced. Not a week later when we want to deploy and need to scramble to find alternatives. Not after the code has gone out to production. Not as part of some quarterly security audit where customers have been exposed for 3 months.

Our repositories are also regularly scanned asynchronously of any code changes, and Slack notifies us via email of vulnerabilities that have been discovered since our last commit. This has been great for code bases that have become more stable and are under less active development; it can be so easy to overlook the things that are just quietly working away which can be a huge risk.

Adhoc analysis

There’s occasionally times when we don’t want to do our usual GitHub PR workflow to get a security analysis on our code. Maybe it’s a side-projects, a spike on a new branch that you’re not ready to share, or we just want to do some analysis on a language other than the default one we’ve configured for the repo. The Snyk CLI tool allows us to run that analysis whenever we need to without forcing us to fit into a single workflow for every occasion.

Practicing what you preach

While there’s no doubt there’s significant value in having a 3rd party have our back when it comes to spotting vulnerabilities, I think one of the most valuable aspects is the subtle cultural reinforcement of security as something we value.

Every pull request someone opens gets that little green check. It’s a consistent reminder that everything you work on needs to take security into consideration at all times.