Using SARIF to Automate Vulnerability Remediation Tracking

Jessica Grider
Published in
5 min readDec 21, 2021


Policygenius is America’s leading online insurance marketplace. Our mission is to help people get insurance right by making it easy for them to understand their options, compare quotes, and buy a policy, all in one place.


At Policygenius, security is extremely important given that we handle sensitive customer data. A key aspect of security is ensuring that our code is not riddled with vulnerabilities that can be exploited. Strategic and pointed static code analysis is one way to identify potential vulnerabilities in source code before it is deployed to production. We recognized the need to prioritize implementation of a source code scanner to prevent simple but potentially devastating coding mistakes such as hard-coding secrets or leaving out cross-site scripting protections.

The Use of SARIF

We knew we wanted to create an automated system to push our scan results through a workflow that would autogenerate tickets, send alerts, and track tickets through the remediation process. This meant that we wanted an output format from all of the scanning tools that was similar enough to use one script for parsing results. Most static code analyzers have their own output format, and others have multiple options for outputs ranging from JSON to XML to CSV. This meant that anyone who wanted to automate parsing of scanning results was forced to create a parser for each tool they used. Teams were also required to stay on top of any output file changes made by the tool developers, lest their automated parsers break. This method was more than a minor inconvenience.

When we completed our output research, we realized that JSON seemed to be a normally available output format. When comparing the JSON output files from various providers, we discovered that they didn’t have enough similarities to create a single script for parsing all tool output files. While it would be feasible to use the JSON outputs, it wasn’t ideal, so we looked for a better option. This is when we discovered that the non-profit industry-recognized organization OASIS had approved a standard format for static code analysis tools. OASIS focuses on establishing industry-wide standards for the international open code and open standards community. The Static Analysis Results Interchange Format, or SARIF, has become not only an OASIS approved standard, but also has been widely adopted by static code analysis tools.

So, what is SARIF exactly? SARIF is a JSON-based format that follows a very specific and standardized schema, meaning the results for one tool will be organized the same way as every other tool with few optional changes. Another great benefit of the SARIF output standard is the option choice for viewing the results. Tools such as VSCode have a reader view for SARIF output, allowing users to easily comprehend the format and see their scan results. Github also has a built-in SARIF upload option that allows teams to upload SARIF files from every tool they use and displays the results directly in the Github repository in line.

Here is an example of what a SARIF file looks like:

Our Workflow

Once we had decided on SARIF as an output, we needed to establish a full workflow for our automation. Once the scanning tool completes, what would the workflow look like for alerting, and ensuring the vulnerability is tracked until it is fixed? Having the right process for issues to be surfaced and addressed is important for a rapidly growing engineering team. There is a lot going on, and we needed a way to make it easy for security to be communicated and continue to be a top priority. We chose to use Atlassian’s Jira for our ticketing and workflow process, with alerts sent to Slack for communications and reminders. The source code scanning tools run in our CI/CD pipeline to identify security vulnerabilities in the source code. These tools output a SARIF file at the end of scans, which is then picked up by our parser. The parser pulls out the relevant information for our ticketing system, and creates a ticket on our board.

The Parser

Parsing out SARIF files was initially a time consuming task, but once we realized we needed to just create our own parser, the task became far simpler to accomplish. We decided to use python. There is a python SARIF module, which we initially tried to use (and resulted in the initial consumption of time), but the lack of documentation made it impossible to use for our purposes. We instead created our own. We used the Benedict library to pull out the embedded json, focusing on the “runs” and “rules” keys. We used the panda json_normalize function and merged the “runs” and “rules” into a single array that had the results and rule information to push to Jira.

The next question we had to ask ourselves: “How do we deduplicate results to make sure that we aren’t sending the same result to Jira multiple times?” Fortunately, SARIF saved the day yet again. SARIF contains a couple of options for identifying duplicate findings: the partialFingerprints property and the correlationGuid property. Both are good options for identifying duplicate results. We chose to use a partialFingerprints record based on Tool+RuleID+uri. Using this record, we are able to deduplicate the run to ensure only unique findings are sent to Jira. The next question: “How do we ensure that the finding being sent to Jira doesn’t already exist in Jira?” In a DevOps environment, the goal is to deploy to production multiple times per day, meaning that our static code scanner will ideally run numerous times a day on the same repo, and of course find the same results as the previous run. Even though the partialFingerprints record allows us to deduplicate a run, our design didn’t allow for SARIF files that build upon each other (although this is a feature SARIF will allow). Fortunately, we found that Jira automation allows for an option to remove duplicate tickets, so we don’t have to account for what already exists in Jira as we create new tickets.

What’s Next?

Now that we have a vulnerability management workflow to help ensure identified vulnerabilities are being remediated, we are planning out what we want to do next. Our DevSecOps team will be looking to build a security specific build pipeline that will allow us to test out and experiment with new security tools and features without disrupting code deploys. Interested in DevSecOps? Come talk to us, we are hiring!

We’re hiring in NYC, Durham, and remote. Check out our careers page to see open roles: