I've been tasked with evaluating our open source license and vulnerability scanning for a fairly complex Node.js/Typescript monorepo. The goal is to automate compliance checks in CI and get a clear, actionable bill of materials without drowning in noise.
Two names that keep coming up are Apiiro and FOSSA. From what I gather, Apiiro seems to integrate risk assessment more deeply into the development workflow, while FOSSA has a strong reputation specifically for license compliance and policy enforcement.
I'm particularly interested in real-world experiences on a few concrete points:
* How do their scanners handle nested dependencies and lockfiles (package-lock.json, yarn.lock) in a monorepo setup? Any issues with path-based references or workspaces?
* For vulnerability reporting, what's the signal-to-noise ratio like? I'm wary of tools that flood us with CVEs for devDependencies or transitive dependencies that aren't actually bundled in production.
* How customizable are the policy engines? We need to allow certain licenses in internal tools but block them in customer-facing services.
If you've run either tool (or both) in a similar environment, I'd appreciate notes on setup complexity, the clarity of the dashboards, and how you've tuned them to reduce false positives. Our team lives in Grafana for other observability data, so any integration points there are a bonus.
- GG
- GG
I'm a senior platform engineer at a fintech with about 200 devs. We run a sprawling Node/TypeScript monorepo and we've been using FOSSA for three years in production; we did a full POC of Apiiro last year during a broader tool consolidation review.
My breakdown for a complex Node monorepo scenario:
1. **Scanner accuracy for monorepos**: FOSSA's CLI handles `package-lock.json` and yarn workspaces exceptionally well. It accurately maps transitive dependencies per service, ignoring dev-only paths when configured. Apiiro's agent-based approach struggled with our path-based references (`"lib-a": "file:../packages/lib-a"`), requiring custom scripting to resolve correctly, which added a 15-20 minute overhead to our CI scan time.
2. **Vulnerability noise reduction**: FOSSA allows you to set policies differentiating `dependencies` from `devDependencies` at the monorepo package level, cutting ~40% of irrelevant CVEs in our case. Apiiro's risk-based approach surfaces more, including transitive dev deps, arguing for "full context." You must use their risk scoring rules to filter, which took us two weeks to tune to an acceptable level.
3. **Policy engine granularity**: FOSSA's policy engine is license-first and highly deterministic. You can set policies like "LGPL-2.1 is allowed for internal-tools but denied for customer-facing," tied to path patterns. Apiiro's policies are more flexible, incorporating vulnerability age, exploit maturity, and code reachability, but are far more complex to author, requiring ongoing security team oversight.
4. **Pricing and operational model**: FOSSA starts around $5-7 per developer per month for their core scanning and compliance. Apiiro's model is enterprise-wide and risk-platform oriented, starting around $50k annual minimum. The hidden cost for Apiiro is the operational overhead of maintaining their risk database connectors and training developers on the IDE integrations.
We kept FOSSA. If your primary mandate is clean, automated license compliance and precise vulnerability reporting for production dependencies in CI, FOSSA is the more focused and operationally lighter tool. If you need a broader, risk-centric platform that ties open-source risk to code context and proprietary code scanning, and you have the team to manage it, evaluate Apiiro. To decide cleanly, tell us your annual security/compliance budget and whether your devs are expected to interact with the findings daily or just receive CI-blocking reports.
Right-size or die
Wow, the 15-20 minute CI overhead is a huge practical detail. Thanks for sharing that.
When you say FOSSA cuts ~40% of irrelevant CVEs by differentiating dev dependencies, does that policy automatically apply to new packages added to the monorepo, or does it need manual updating per package?
The policy needs manual configuration per project or sub-project, but that's half the problem. The other half is when devs decide a package is "needed for build" and shove it into devDependencies to make the security dashboard green, even if it ships in the Docker image.
So yes, it reduces noise initially, but you're just trading one type of management overhead (sifting CVEs) for another (policing dependency categorization). Tools can't fix messy human processes.
-- cost first