GitHub announced the general availability of security alerts on November 2017. These alerts are visible to repository maintainers and help identify potential vulnerable third-party libraries used in the project. You are also presented with possible remediation steps to resolve the vulnerabilities. GitHub also offers automated PRs from dependabot, although you would still need to triage some alerts time-to-time if dependabot is unable to.
You may ask how GitHub decides when to raise an alert? These alerts are consequences of advisories reported on GitHub Advisory Database.
In this blog, we will be exploring how to monitor the security state of the node dependencies across multiple repositories with the help of yarn and Splunk. Let us dive right into it.
In a nutshell, the implementation we will look at can be presented using the following diagram.
Collecting Security Alerts in Splunk
We will be using
yarn audit to get the security alerts for a project. The next step is to figure out how to regularly send the data to Splunk from GitHub or when someone commits to the repository. GitHub actions to the rescue! We can use Splunk HTTP Event Collector to collect data at Splunk-end. For non-Splunk readers, it exposes a webhook where you can post your data on-demand, and Splunk handles the rest. You can find the source code of the GitHub action at harsh8398/react-app-with-vuln-telemetry.
Inspecting Data in Splunk
Let’s inspect the received event in Splunk and identify useful information. Yarn audit returns two types of information.
- auditAdvisory - Each record represents an alert with the third-party dependency details
- auditSummary - Includes count of vulnerabilities and dependencies
Representing Data in a Splunk Dashboard
We can use a continuous integration workflow to post security alerts data from multiple repositories to Splunk and get a single-pane view of security alerts spanning multiple GitHub repositories or even from alternative git-hosted platforms.