One important feature that Dependabot is missing

GitHub’s Dependabot feature allows you to detect and fix vulnerabilities in code dependencies for all your repositories (public and private). Despite being a handy tool in securing software supply chain, it’s missing a very important feature.

TL;DR:

If you have hundreds or thousands of dependabot alerts across your org, it’s quite intimidating on what to fix and how to move forward. Dependabot lacks a central dashboard that provides useful insights like what are the 20% vulnerable dependencies accounting for 80% of the alerts, etc. For such a dashboard you need to pull the alerts using GitHub GraphQL endpoint and visualize on your own.

If you haven’t heard about Dependabot, let me introduce it to you.

If you are using GitHub.com for your public/private repositories or using GitHub Enterprise (Cloud/Server), you can enable Dependabot and get vulnerability alerts in your dependencies (if any) for free. The best part is it has an option to automatically raise PRs if there’s a fix for existing issues.

It uses GitHub Advisory Database for vulnerability data. GitHub Advisory DB has good coverage of public vulnerabilities as it uses multiple sources like NVD, npm Security Advisories DB, etc to gather data.

However, dependabot is not the best when it comes to tackling software supply chain vulnerabilities. For example, it very recently added transitive dependencies support for npm projects in GitHub.com. This feature is still not present in GHES.

You think - If it’s not the best why would you spend time on it?

Well, good question.

First of all, there’s a lot of development going on Dependabot. Every new GHES release you will see at least one Dependabot feature update. Some of the recent features include REST API for Dependabot, option to close and reopen alerts, etc. Enabling it across your GH Enterprise is just a single click away.

You’ll understand its value and ease-of-use when you compare it with other commercial vendors or even open-source tools like Dependency Track. There’s no need to set up integrations with your repositories, no need to host anything, and finally - no additional cost.

So, dependabot is a great start if you are securing your software supply chain vulnerabilities.

The one missing piece

Enabling dependabot and tracking dependency issues/fixes for a handful of repositories is easy. If you use GHES, you can head over to https://github-ent.yourdomain.com/advisories, search involves:@me and look at the list of security advisories and their severity.

The problem starts when you have 100s of repositories in 10s of GitHub orgs. The above search results becomes useless. You’ll have 100s of dependency issues and each issue can affect more than one repositories.

In such a scenario, you will have multiple questions like:

• How many CRITICAL/HIGH severity bugs do I have across repositories?
• Which GitHub org or repo has the most vulnerabilities?
• What are the 20% vulnerable dependencies that fix 80% of the dependabot security alerts?
• Am I (or my team) doing a good job fixing vulnerable dependencies?

GitHub doesn’t provide any insights that helps answer the above questions. If GitHub had a central dashboard that answers the above questions, that would have been a game changer.

GitHub has such a feature (reserved?) for GitHub Advanced Security (GHAS) customers.

A lot of GitHub Enterprise users (who don’t use GHAS) are looking forward for a Dependabot Dashboard feature.

Let’s Make Dependabot Great Again!

I checked if there’s any tool that helps fetch dependabot alerts. I think you probably guessed it right - there’s no such tool. Even Steampipe and CloudQuery don’t support querying dependabot alerts (yet).

In such situations, the last resort is to check API documentation and build something on my own.

When I started this visualization project GitHub didn’t provide any REST APIs. On 22 Sept 2022, GitHub provided REST API to query dependabot alerts in a public beta. On 18 Oct 2022, GitHub enabled Org level REST API to GitHub.com and GHES v3.8.

Fortunately, GitHub offers a GraphQL endpoint that can be utilized to search dependency issues in repositories. The RepositoryVulnerabilityAlert object returns the list of dependabot alerts for a repository. The object can be enhanced to include details like: the PR number of the fix for an alert, alert created and fixed/dismissed timestamps, etc.

The minimal GraphQL query I used looks like the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

{
    repository(name: "REPO", owner: "ORG") {
        vulnerabilityAlerts(first:100) {
            pageInfo {
                startCursor
                hasNextPage
                endCursor
            }
            nodes {
                createdAt
                fixedAt
                number
                dependabotUpdate {
                    pullRequest {
                        number
                        title
                        mergedAt
                    }
                }
                state
                dismissedAt
                dismisser {
                    login
                }
                dismissReason
                securityVulnerability {
                    severity
                    advisory {
                        ghsaId
                        summary
                    }
                    package {
                        name
                    }
                }
            }
        }
    }
}

Once you fetch these data and dump them into a database, you can use any BI tools to create a dashboard.

I have uploaded the sample code to fetch the alerts across organizations in my repo - https://github.com/Chan9390/Dependabot-Dashboard. This python code needs to be run every day (with help of cron or scheduled GitHub Actions 😉) to fetch metrics over time. The output is stored in a Postgres DB in the database dependabot.

The Dependabot Dashboard you’ll need

Once you have the dependabot alerts data in a DB, you can use any BI tools like Metabase, Looker, etc to create a dashboard. You can add your metrics to the dashboard.

For this blog post, I have used Apache Superset. The dashboard looks as follows:

The above image answers the questions I had:

• How many CRITICAL/HIGH severity bugs do I have across repositories?
• Which GitHub org or repo has the most vulnerabilities?
• What are the 20% vulnerable dependencies that fix 80% of the dependabot security alerts?
• Am I (or my team) doing a good job fixing vulnerable dependencies?

Hope you liked my blog post. Please share this blog post with others who would find this useful.

If you have any doubts, feel free to reach out on LinkedIn. I’m interested to learn about any automation you have done in your organization around securing software supply chain.