How to Operationalize GitHub Dependabot

Vulnerability Alerts

Dependabot will create alerts when a new vulnerability is added to the GitHub Advisory Database or when the dependency graph for your repository (repo) changes, such as when a new commit adds a dependency to the project. Dependabot can also display information about vulnerable dependencies in a PR.

When a vulnerable dependency is detected, alerts are displayed on GitHub and dispatched to maintainers according to their notification preferences. The alerts include information about the affected version as well as the fixed version.

If Dependabot security updates are enabled the alert will also include an automatically generated PR that updates the dependency.

Dependabot is enabled in public GitHub repos by default. For private repos, an owner or person with admin access, can enable Dependabot by turning on Dependabot alerts. Dependabot can also be enabled at the user account or organization level.

Dependabot Vulnerability Silos and Prioritization Challenges

Dependabot is really phenomenal for continuously monitoring for vulnerabilities and automatically creating the PRs necessary to adapt your dependencies, development still is manually triaging the PRs to see what is changing, and if the change will break anything. Often, we find that development teams can be overwhelmed by the number of individual, unprioritized PRs, and will ignore or not merge the requests. And while Dependabot is great at showing security vulnerabilities at a repo view, it is difficult for a central security team to get an organization-wide understanding of risks identified by Dependabot, and its remediation status.

From a security perspective, when the number of your code repos grow, the following questions arise:

• How do you identify which repos Dependabot is enabled on?
• How can you ensure Dependabot is enabled on all the business critical code repos ?
• How do you get a complete picture of security vulnerabilities and risk across the entirety of all code repos?
• How can security team automate prioritization of dependencies that have mature exploits available, are direct dependencies vs transitive dependency and whether the dependency even has a fix available or not?
• Are the different development teams remediating vulnerable dependencies on time to manage risk and compliance requirements?

GitHub Dependabot and Tromzo  👭

GitHub Dependabot is a powerful developer focused tool for keeping your dependencies up-to-date however the key security use cases of centralized visibility and control are not solved by it. Typical application and product security teams are overwhelmed with a huge volume of security alerts and are no way equipped to keep up with agile development teams to manage risk.

This is where Tromzo can help operationalize Dependabot at scale with a unified Product Security Operating Platform (PSOP) to enable:

• Centralized Visibility – aggregates all Github code repos as software assets along with Dependabot vulnerabilities, their remediation statuses and associated metadata. This centralization of Dependabot data, and it’s consolidation with vulnerability data from other security scanners (SAST, DAST, IaC Scanners, etc) gives a real time and deduplicated view of security risk across the code repos.
• Security Guardrails – automatically implement guardrail whereby each code repo with active commits needs to have Dependabot enabled. In complex enterprise environments, it is not feasible to make enterprise wide changes and enforce Dependabot on every single repo. Tromzo’s Security Guardrails can ensure every existing or new code repo, with active commits and/or repos that are actively being deployed by CI/CD, have Dependabot enabled. For code repos missing Dependabot coverage, Tromzo can automate action in Pull Requests or notify using out of band channels like Slack, Jira, Email etc. This truly helps the security teams ensure every single code repo that is important to the business, has Dependabot enabled without any manual intervention from the security team.
• Workflow Automation – automatically triage, prioritize and consolidate vulnerabilities into actionable alerts. For example, you can run remediation campaigns to have developers focus only on updating dependencies that have vulnerabilities with mature published exploits and only alert developers on dependencies that have a fix available. There’s no point in alerting developers about dependencies that might be vulnerable but have no fix available. Additionally, Tromzo can automate remediation workflows where developers focus on fixing direct dependencies first, and once those are well managed then focus on vulnerabilities from transitive dependencies. These are common triaging and prioritization approaches that security teams already follow, however before Tromzo, there was no way to automate it at scale.
• Reporting & Analytics – enables central teams like product security or application security to enrich security risk with code ownership and clearly communicate the risk owned by various development teams or services. Measuring KPIs like MTTR, SLA Compliance, Remediation Rates and reporting these KPIs per team and as leaderboards, is instrumental in helping drive ownership and accountability of risk across the organization.

You can finally dream of a world where you understand:

• Which repos are important from a business risk perspective.
• Enable only important code repos to have risk appropriate security guardrails.
• Empower your development team to remediate what matters.
• Automate triaging and prioritization so you:
  • Only fix what can actually be fixed, thus reducing the noise (ie. patch might not be available – so don’t chase it).
  • Only focus on direct dependencies, so you can make the most impact, the fastest.
  • Prioritize fixes of vulnerabilities that have active exploits available.
  • Narrow down the sheer volume of vulnerabilities based on real business context so you don’t have to run around like a chicken without your head.
  • Understand where one dependency has multiple CVEs and communicate the one action item, i.e update the dependency instead of reporting tens of CVEs related to the same dependency
  • Meet developers and development leadership where they are, with metrics so your organization can drive ownership and accountability.

Additionally, in this series of how Tromzo can help with visibility and control within GitHub, we will be covering:

GitHub CodeQL, and
GitHub Secret Scanner

Additional resources:
GitHub and Application Security
How GitHub Uses Dependabot
What are Software Dependencies