Requiring authentication in Snyk CLI
Since Snyk launched in late 2015, we’ve supported testing applications anonymously. Today, we released a new version that requires a (free!) registration and authenticating before testing. This post explains why we made this change, and how it affects you as a user.
Over the course of 2016, we’ve seen large and growing use of Snyk. Most of that use was legit and growing at a fast but steady clip, but every now and then we’d get a massive burst of tests. These bursts were usually abusive (at times even intentional attacks), and would dramatically increase the load on our system, slowing it down for other users.
In theory, the solution is simple—block or throttle abusive users. In practice, however, it’s all but impossible to isolate and block anonymous users. Cloud systems, ranging from CI platforms like Travis and Circle to cloud platforms like AWS and Google Cloud, reuse IPs constantly, making it highly inaccurate to block by IPs. Similarly, shared use (and testing) of open source packages make blocking tests by package name inaccurate too.
Those were the two more promising paths we explored before concluding the only way to prevent usage abuse in a service like ours is to require users to authenticate. Once authenticated, it becomes easy again to block or throttle an offending user who consumes more than their fair share.
Connecting with our users
Snyk is a growing and fast moving company, and our tools evolve quickly. We regularly release new capabilities to help our users secure their applications with less effort and greater accuracy.
Unfortunately, an anonymous user using Snyk’s CLI in the CI has little opportunity to learn about these new capabilities. As a result, we’ve seen that such anonymous users lag behind, being the slowest to evolve their use of Snyk and expand it to more applications.
This very change of requiring authentication is a good example of this problem, as we had no good way to tell users we’re about to require authentication. For the last couple of months, our CLI stated we’re about to require auth, which had some impact but was a poor communication vehicle.
By requiring authentication, we get the opportunity to tell you about important changes, ranging from exciting new functionality to changes that may impact your current use.
What about applying patches?
While Snyk’s testing now requires authentication, applying snyk patches using
snyk protect does not, and we have no plans on changing that.
Fixing vulnerabilities using Snyk’s patches is often a part of an npm package install. The package installs its dependencies, and then patches remaining vulnerabilities. This process is done by the users of the package, not the users of snyk, and there’s no right place to include a Snyk token in this flow.
snyk protect will continue to support anonymous usage, despite some risk of resource abuse. It’s a good thing
protect is a relatively lightweight action for our servers!
Does this mean I have to pay to use Snyk now?
Not at all!
Registration with Snyk was and remains free. All you need to do is run
snyk auth in your terminal (or register on https://snyk.io/) to get an account setup. We do have premium tiers which you definitely check out, but Snyk’s free tier remains exactly the same as it was before
Once registered, you will find a
snyk auth (with your specific key) on your dashboard as you login, and in your account page. Add that line before
snyk test, and you’ll be good to go. If you’re using Snyk in your CI, check out our docs for advice on how to setup your auth token there.
If you’re using Github or already running
snyk auth before
snyk test, there’s nothing for you to do.
To let our users ease into it, right now we only require authentication in the latest version of our CLI. Over the next weeks, we intend to track the new version adoption, and when the time is right, make authentication a server-side requirement.
We hope you keep using Snyk to secure your applications, and as always would love to hear any feedback you have about this change or others at firstname.lastname@example.org.