Github Action for Javascript Vulnerability Scanning
Tags: security, softwaredelivery, javascript
Published: 2020-01-30 03:22:54

---
title: Github Action for Javascript Vulnerability Scanning
published: true
date: 2020-01-29 14:44:17 UTC
tags: security,software delivery,javascript
canonical_url: https://mattorb.com/github-action-for-javascript-vulnerability-scan/
---

 ![Github Action for Javascript Vulnerability Scanning](https://mattorb.com/content/images/2020/01/gisela-bonanno-@gise_bon-a073XCeYm1U-unsplash.jpg) photo credit: [gisela-bonanno](https://unsplash.com/@gise_bon)

Part of what is served by [this](https://mattorb.com) web site includes 3rd party javascript libraries.    The libraries included in a page are a mash-up of libraries and dependencies from a few    sources.  

Those libraries occasionally have security vulnerabilities disclosed.  In our last post, we put in [automatic checks](https://mattorb.com/github-action-for-google-pagespeed-insights/) around performance of the site.   Now, let's do something to detect [Javascript library vulnerabilities](https://snyk.io/vuln/search?q=jquery&type=any).

## The Github Action

I found [this project](https://github.com/lirantal/is-website-vulnerable) and whipped up the [changes necessary](https://github.com/mattorb/is-website-vulnerable/pull/1) to turn it into a Github Action.   Thanks Liran!  Thanks too to [Snyk](https://snyk.io), which provides the vulnerability list.

I adapted an existing Docker container, wrapping a Github action around it.   One way to do this without overly leaking the Github Actions contract in to the container design is to map Github action parameters to environment variables and args that are agnostic and already expected by the container like so:

<!--kg-card-begin: markdown-->
```
env:
     SCAN_URL: ${{ inputs.scan-url }} 

```
<!--kg-card-end: markdown-->

... where `inputs.scan-url` comes from the Github Action contract (as a  'parameter')  and  'SCAN\_URL' is an environment variable that already works with the existing Docker container.   This is in contrast to having the container need to understand how to look for 'INPUT\_' prefixed vars that a Github Action provides by default (ref: [github docs](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputs)).  If you don't want to, or can't modify the existing docker container, this is an option.  

The container _does_ still need to exit with an error to cause a Github Action to fail though.   I had to modify the underlying Javascript code to accommodate that.  There would not be much value in an automatic check that always passes.

Now that we have the action, we use it by creating a workflow file in _.github/workflows/javascript\_vulnerability\_check.yml :_

<!--kg-card-begin: markdown-->
```
name: Test site for publicly known js vulnerabilities

on: 
  push:
    branches:
    - master # Check on every commit to master
  schedule:
    - cron: '0 13 * * 6' # Check once a week regardless of commits
  repository_dispatch:
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - name: Testing for public javascript library vulnerabilities 
        uses: mattorb/is-website-vulnerable@github-action_v1 # until PR to original repo is merged
        with:
          scan-url: "https://mattorb.com"

```
<!--kg-card-end: markdown-->

With that in place, we see the following check run after each commit, and once a week for good measure:

![Github Action for Javascript Vulnerability Scanning](https://mattorb.com/content/images/2020/01/Screen-Shot-2020-01-29-at-8.18.07-AM.png)

## Shift security left!

So.  Awesome.

Now we have _at least_ have some awareness if any of the following happens:

- A change we make introduces a library with a vulnerability
- A change introduced by 3rd party dependency introduces a library with a vulnerability
- No change is made at all, but a vulnerability is discovered and published for a JS library we were already using.

Automatic checks for the win!