Using jq to manipulate JSON results of snyk security tests
Tags: jq, json, security, snyk
Published: 2019-09-06 08:23:18

---
title: Using jq to manipulate JSON results of snyk security tests
published: true
description: working tricks with JSON data
tags: jq, json, security, snyk
---

[jq](https://stedolan.github.io/jq/) is a handy CLI utility to easily print, filter and manipulate JSON data. Let me show you how I'm using it for some projects.


So let's say you have a Continuous Integration (CI) such as Travis, Circle or Jenkins to build your application, in which you are running Snyk's security tests via the CLI to hunt for those security vulnerabilities and break the build to make sure you're not introducing unnecessary risk.

How can you make sure you focus on actionability, so that developers are able to fix security issues when the build fails?

This is where `jq` and JSON formatted results come in.
￼
￼
## Getting the JSON output

If you're running snyk from the CLI to hunt those JavaScript and Node.js security issues you're probably used to the pretty printed list of vulnerabilities. That's nice to see in a build output.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/wzermd7s5fl7pe1z08kk.png)

Did you also know you can get results in JSON output?
and how does that help us exactly?
￼￼
￼
## Manipulating JSON 

Luckily, one of snyk's CLI command arguments is the ability to pass a `--json` to a snyk test and pipe all of its output to `jq` which we can then use with some filtering as below to selectively export or fail the build only on those open source security vulnerabilities in our project that could be addressed and fixed.

So here's an example:

```
$ snyk test --json | jq 
```

That will just pretty print the JSON output in color and proper formatting and indentation as we didn't provide any arguments to `jq`.

A super nice thing to do in a CI that promotes application security testing if you're using the Snyk CLI test is to make sure you're breaking the build on actionable security problems. Meaning, if the build breaks, developers can see why and then take action, such as to upgrade a library, in order to remediate the vulnerability.

Using jq, we can further do that thanks to Snyk's `isUpgradable` field in the JSON results:

```
$ snyk test --json | jq '.vulnerabilities |= map(select(.isUpgradable == true or .isPatchable == true))`
```

So cool!


## What's next?

Here are some further `jq` related resources to keep you going:

1. For filters and other operators documentation you may refer to the [jq documentation](https://stedolan.github.io/jq/manual/)
2. Lastly you might want to read a more thorough post about [getting the most out of Snyk test with JSON](https://snyk.io/blog/getting-the-most-out-of-snyk-test/)
3. 1. To learn more about Snyk CLI command arguments we have created this [Snyk CLI Cheat Sheet](https://snyk.io/blog/snyk-cli-cheat-sheet/)


If you care about your application security (you probably should? :-]) you might want to bump it up a notch and connect your source code repositories with Snyk (it's free, for private repos too!).

You get this lovely looking dashboard for your project and Snyk will also automatically open Pull Requests to fix your security issues:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/jlmlp8yv32q9m2s63lfz.png)

￼