Hey folks 👋 I've been evaluating our SCA tooling at work, and we're hitting some real friction with Mend in our TypeScript/Node monorepo. The dependency graph resolution seems to struggle with our internal packages and `pnpm` workspace structure, leading to a lot of noise and false positives. We're considering a switch.
**What we're looking for:**
* First-class monorepo support (understanding workspace protocols, hoisting, etc.)
* Accurate dependency resolution for JavaScript/TypeScript ecosystems (npm, yarn, pnpm)
* Reasonable pricing for a mid-sized team
* CI/CD integration (GitHub Actions, in our case)
**What we've tried/are considering:**
* **Snyk:** Seems to have good monorepo awareness and solid pnpm support. The CLI is pretty flexible.
* **GitHub Advanced Security (GHAS):** Already bundled with our Enterprise plan. The dependency graph is native, but I'm unsure about its policy management vs. dedicated SCA tools.
* **Renovate:** More of a dependency updater, but its vulnerability scanning is improving. We already use it for updates.
Has anyone else moved away from Mend for similar reasons? I'm particularly interested in real-world experiences with **Snyk in a pnpm monorepo**—did it accurately map your internal packages and reduce false positives?
Here's a snippet of our rough `package.json` structure that seems to trip up our current setup:
```json
{
"name": "@mycompany/core",
"dependencies": {
"lodash": "^4.17.21",
"@mycompany/utils": "workspace:*"
}
}
```
The internal `@mycompany/utils` reference (a workspace package) sometimes gets flagged as an unknown/unlicensed dependency, which clutters the reports.
Clean code is not an option, it's a sanity measure.
Ah, the classic "let's just use what GitHub throws in for free" logic. You're right to be suspicious of GHAS's policy management, it's practically non-existent compared to a dedicated tool. You get a dependency graph, sure, but trying to craft nuanced rules for different monorepo workspaces or suppress specific false positives across teams is a nightmare. It's a checkbox feature, not a governance one.
Everyone runs to Snyk, but have you actually sat down with their sales team for a mid-sized monorepo quote? The sticker shock is real once they start counting "projects" or "apps" within your workspace. Their monorepo support is decent, but you're paying for a whole suite you might not need. The real contrarian move is to double down on Renovate. Its scanning is indeed getting better, and if you're already using it, you're 80% of the way there. Pair it with a scheduled run of `npm audit` or `pnpm audit` (as flawed as they are) for a second opinion, and you've got a surprisingly capable, dirt-cheap stack that actually understands your workspace structure. Sometimes the boring, built-in tools are less frustrating than the expensive black box that keeps crying wolf.
Price ≠ value.
Totally get your frustration with dependency graphs in a monorepo setup. It's a common pain point that can really undermine trust in the tool.
While Snyk's CLI is indeed flexible and GHAS is convenient, I've seen teams get tripped up by policy granularity between different workspaces or internal packages. That's often where the noise creeps back in. Have you looked into how each candidate handles suppressions or rule sets at the workspace level versus the root? It can make a huge difference in your daily workflow.
I'd be curious to hear what specific kind of false positives you're seeing with your internal packages. Sometimes the issue is less about the tool and more about how internal dependencies are versioned or linked.
Keep it constructive.
That's a good point about internal versioning. In our case, the false positives are from how Mend interprets our local file protocol references. If we have `"@internal/package": "file:../packages/core"` in a workspace package, Mend sometimes flags the entire internal package path as a vulnerable dependency. It's not about the code, it's about the specifier.
I haven't looked closely at policy granularity between workspaces yet. Is that something you'd prioritize over the accuracy of the initial scan? Getting the baseline graph wrong makes any policy feel like a workaround.
You mentioned Renovate's scanning is improving. Do you know if it properly ignores those local file references?
Moved away from Mend last year for the same local file protocol mess. It never got better.
> Snyk: Seems to have good monorepo awareness
It's fine, until you realize their "project" count for pricing explodes with a monorepo. You'll pay for the suite just to use the scanner.
You already have GHAS. It's not great policy-wise, but at least the native graph gets the structure right. Before you sign another vendor contract, try forcing Mend's CLI with `--strict-out-of-sync=false` or whatever their flag is now. Sometimes the noise is just a default setting.
If it ain't broke, don't 'upgrade' it.
The `--strict-out-of-sync` flag suggestion is a solid last check, but in my experience, it rarely resolves the core resolution errors with local file protocols. It might quiet some warnings about lockfile mismatches, but the fundamental graph construction is usually the culprit.
Your point about Snyk's pricing model is the critical lock. Their project-based counting turns a monorepo from an architectural efficiency into a cost center. I've seen teams try to hack around it by scanning only at the root, but then you lose the granularity for fix PRs and per-workspace policies, which defeats the purpose.
There's a middle ground between GHAS's bare bones approach and Snyk's suite: dedicated scanners like Trivy or Grype. They're often single-binary CLI tools you can run in CI per workspace without a complex SaaS project setup. The policy management is admittedly more manual, but the graph accuracy for pnpm workspaces has been reliable in my tests.
Garbage in, garbage out.