Guarding Your Packages with Snyk and Icinga
Do you use any 3rd party packages in your project?
Have you ever wondered what is the quality of those packages? What security vulnerabilities they might contain?
If not, maybe now it’s a good time to start thinking about this question. Each package you’re using could contain known vulnerability — but you don’t know. And you can’t fix something if you don’t know it’s broken.
So how can you find out about all those vulnerabilities and fix them on time? And how can you make sure that you stay secure over the time? How will you find out when a new vulnerability found on a package you’re using? Read along to find out.
Snyk is a great product that can be easily integrated into your pipeline to scan the packages you use in your project — both for security and licensing issues. It has built-in support for notifications (via email or Slack) when a new vulnerability was found in one of those packages. This might sound like a good solution, but it’s not perfect. Why?
Issues reported by Snyk, are just like any other production issues: indications of an issue that happens just now in production. And like any other production issue, the relevant person whose on-call should receive an alert, and fix it. This is why it should be reported by the same monitoring tools that are already in use. This will also allow us to ensure that everyone will treat this issue as a production issue, instead of missing or ignoring it accidentally.
Integrating Snyk with Icinga2
Icinga2 is a free and open source monitoring solution. Icinga is highly extensible — which mean I can use it to monitor issues reported by Snyk. I’m focusing on Icinga because this is we’re using at Soluto, where I work. If you’re using something else, like Prometheus Alert Manager, the same idea can be applied — the implementation will be different.
In order to integrate Snyk with Icinga, all that is required is writing a check plugin — which is just a script, running on Icinga. The script will use Snyk API to list the issues of a given project. If the project has no issues — the scritp will return ok (exit code 0), either wise— warning (exit code 1):
The code is very simple. To use it, follow the documentation to find your
API KEY, and then run it:
./check.rb -k <Snyk's API Key> -o <The organization ID containing the project> -p <The requested project to check>
To add this code to your Icinga instance, upload it to somewhere on your server. Than, follow the documentation for creating a new check command. Now you can start using this check command everywhere!
Now that you know how to use packages securely, it’s time to apply it. For each project you have you need to (after creating an account on Snyk, of course):
- Create a new project on Snyk, and scan all the packages
- Triage the issues found by Snyk
- Add the check command to the relevant host on Icinga, to monitor this project on Snyk
This is a long process, especially if you have a lot of projects (and when using micro-services or FASS, there could be hundreds of projects). And this effort that should be done by the developers, who own those projects.
This is a tedious and annoying process, but (as I hope you now understand) also a very important one. The good part — once you complete this process for a project, you can rest assured. Snyk and Icinga will watch your back and guard you against using packages with known vulnerabilities, at least in this project.
So, What are you waiting for? A journey of a thousand miles begins with a single step. Go ahead, choose one project, and try this process out. You might be surprised with what you will find. I know I was.