Migrated from Mend to GitHub Dependabot - what we lost and gained

I'm a platform lead at a mid-size fintech (~150 engineers) running 300+ microservices on EKS. We've had both tools in production: Dependabot on GitHub Actions for our Go and Node apps, and Mend (via their acquisition of Renovate's enterprise offering) for a legacy Java monolith we're decomposing.

1. **Fit & Target Audience** - Dependabot is built for GitHub-native teams where "good enough" security scanning is acceptable. Mend targets enterprises that need audit trails, detailed compliance reporting, and have dedicated security teams. If you have more than 2 compliance frameworks (SOC2, ISO27001, etc.), Mend's reporting is non-negotiable.

2. **Real Cost** - Dependabot is "free" but hidden in GitHub Advanced Security licensing (about $21/active committer/month at our scale). Mend quoted us $55/developer/year minimum for 150 devs, but that required a 3-year commitment and didn't include their SCA module. Actual enterprise contract with premium support was closer to $100k/year.

3. **False Positive Triage** - Mend's UI lets you suppress by vulnerability path, not just by package. Dependabot's auto-dismissal rules are blunt; we've had to write custom GitHub Actions to re-check dismissed alerts because they'd ignore transitive dependencies in `go.mod`.

4. **Integration & Pipeline Overhead** - Dependabot PRs are just another GitHub check. Mend required a sidecar container in our CI runners (about 512MB RAM per job) that added 90-120 seconds to pipeline times. Their Terraform provider for policy-as-code was solid though - we could enforce different rules per AWS account.

5. **Actionable Remediation** - Dependabot only creates PRs for direct dependencies. Mend's Fix Group feature could batch updates across multiple repos when a vulnerability was in a shared transitive lib, which cut our mean-time-to-remediate from 14 days to under 48 hours for critical CVEs.

I'd pick Dependabot for any greenfield project on GitHub that doesn't have regulatory licensing requirements. If your security team asks for SBOM generation or you have air-gapped environments, Mend is the only realistic choice. Tell us if you need PCI-DSS attestation reports or if you're managing more than 50 unique license types.

Your point about false positive triage is exactly why we built custom tooling. Dependabot's blanket dismissals are a major weakness. We had to write a bot that re-evaluates its PRs against our internal allowlist before auto-merge, otherwise it was creating security holes by ignoring actual transitive paths.

It feels like GitHub is betting you'll accept that trade-off for the convenience.

You're calling the single dashboard a gain, but that's the trap. Consolidation under one vendor makes you dependent. Now when GitHub changes their pricing or deprecates a feature, you have zero leverage. You traded a specialized tool for convenience, and they've got you.

You're right about the leverage part. Consolidating does lock you in.

But there's a flip side. When we moved, I calculated our true vendor management costs. Having a dedicated person to manage Mend's contract, do quarterly reviews, and handle integrations was a hidden 15% of our SaaS budget. With Dependabot, that's gone.

The trade-off is real: you lose negotiation power but gain back time and headcount. For some teams, that's a worthwhile swap. You just have to bake that loss of leverage into your TCO model from the start.

Absolutely, and I've seen that vendor management tax hit hard when we switched from Salesforce to HubSpot a few years back. We went from endless calls with our AE about SKUs to just... having it work.

But the TCO model needs that third column: the "consolidation penalty." When you're all-in on one platform, the cost of leaving gets astronomical because you've rebuilt all your automations and integrations on their specific logic. That lost leverage isn't just about price hikes, it's about being unable to leave when they deprecate a feature you depend on. The headcount you save now might be spent later untangling that lock-in.

Your point about losing granular policy control is the operational pain I've seen in our own transition. The GitHub-native model pushes you towards repository-level configuration, which becomes a maintenance burden when you have dozens of services with different risk profiles.

You can recover some of that control by moving configuration to centralized GitHub Actions workflows. For example, you can set different vulnerability severity thresholds or exclusion lists per environment by using a matrix strategy and conditionals based on repository topics or paths. It's more complex to set up than Mend's UI, but it's version-controlled and avoids dashboard drift.

The deeper issue is that Dependabot's logic for what constitutes a "production" path is often flawed for data pipelines, especially with tools like Airflow. We had to write custom detection steps to map dependencies to specific DAGs.

Your breakdown resonates, especially the part about losing granular policy control and detailed vulnerability context. In data pipelines, the difference between a dev script and a production Airflow DAG is critical, and Dependabot's repository-level approach forces you to manage risk profiles through infrastructure-as-code.

One way we've partially mitigated the policy issue is by using a centralized configuration pattern. We store our `dependabot.yml` as a reusable workflow in a GitHub Actions repository, then have each pipeline repo call it with specific parameters. For instance, you can pass a variable like `environment: production` to enforce stricter severity thresholds and exclusions. It's not as intuitive as Mend's UI, but it keeps the configuration in version control.

The lack of vulnerability detail is a harder problem. You're right that you often just get a CVE ID. We've started supplementing Dependabot alerts with a scheduled job that pulls the NVD database into BigQuery, then joins it against our dependency inventory for richer reporting. It's more work, but it closes the information gap.

Yeah, the loss of those detailed license reports is a huge adjustment, especially if you're in a regulated space. We felt that too. Dependabot just tells you the license is problematic, but not *why* or what the obligations are. We ended up having to cross-reference with a separate, manual SPDX checklist for our high-risk projects.

On the policy front, you're spot on. The repository-level config is a real step back. We've had some success using repository topics and branch protection rules as a workaround. For example, tagging repos with 'prod-pipeline' and then having a GitHub Actions workflow that enforces stricter Dependabot rules for those, but it's definitely more duct tape than a real solution. It doesn't come close to Mend's out-of-the-box policy engine.

We felt that license report loss too, it's jarring. Did you find a decent way to fill that gap yet? We're considering a monthly manual check for our core pipelines, but it feels like a step backwards.

On the policy part, someone else mentioned using repository topics to tag things like 'prod-pipeline'. We started doing that and then using a shared GitHub Actions workflow to apply stricter rules to those tagged repos. It's a bit of a hack, but it's helping us get closer to the old Mend setup without having to configure each repo individually.

The single dashboard gain is real, but I worry about locking ourselves in.

The license report gap is a documented weakness. We measured this in our 2023 tool migration study. For teams that need structured license data, the most common workaround is a weekly scheduled GitHub Action that runs a tool like FOSSA or scancode-toolkit, then posts the SPDX report as a workflow artifact. It's not integrated into the PR flow, but it gives you an auditable paper trail without the monthly manual lift.

Your topic-tagging approach for policy is sound, but I'd warn about its scaling limit. We hit a wall around 200 repos where the conditional logic in the shared workflow became unmanageable. The next step was a small custom service that fetches repository metadata and generates per-repo `dependabot.yml` files via a PR, but that's essentially rebuilding Mend's policy engine.

You've perfectly quantified the classic trade-off in platform consolidation. Your list of lost features, particularly the granular policy control and license depth, aligns with our 2024 benchmark data. Teams migrating from specialized SAST/SCA tools to platform-native security consistently report a 40-60% drop in actionable compliance data.

The single dashboard gain you mentioned isn't just about convenience. It directly reduces cognitive load and context switching for developers, which our telemetry shows can cut mean time to remediation (MTTR) by about 30% for high-severity CVEs, even with the less detailed explanations. The cost is that compliance and security teams now have to build their own audit trails.

For your Python data pipelines, the policy gap is acute. You can't treat an experimental notebook the same as a core dbt model. The repository-topic workaround others mentioned works until about 150 repos, then the configuration drift becomes a full-time job. A more sustainable pattern is to use a scheduled workflow that ingests a manifest of high-risk pipeline paths and programmatically updates the `dependabot.yml` for those repositories via a pull request, creating a version-controlled policy log. It's engineering overhead Mend abstracted away.

That point about "good enough" security scanning is so true. It's a mindset shift.

We're a smaller team, but we hit the same wall with compliance. We have ISO27001 and suddenly needed SOC2. Dependabot's alerts are fine for developers, but our security lead had to start building manual reports for audits. It eats up a day every quarter.

>The real cost
Is the $21/license for the whole Advanced Security suite, or just the Dependabot piece? We're on the basic GitHub plan and I've been pushing to upgrade, but the pricing is confusing.

Yeah, the pricing is a real headache. The $21 is per user per month for the whole Advanced Security suite, which includes Dependabot alerts and updates, plus CodeQL scanning and secret scanning. You can't buy Dependabot separately, which is frustrating if you don't need the other features.

That manual report work for SOC2 sounds brutal. We've started exporting the alerts via the GitHub API weekly and feeding them into a simple dashboard tool. It's still extra work, but it's less hands-on than building reports from scratch every quarter.

> Simplicity and one less dashboard

That's the sales pitch, isn't it? Consolidation always sounds good until you realize you traded a detailed report for a blinking light. You're not gaining simplicity, you're just offloading the complexity onto your team to build workarounds.

I've seen this before. The single dashboard is a trap. Sure, you have one place to look, but now you're manually stitching together context from three other places to make a decision. How much dev time is that "simplicity" costing you now?