Skip to content
Notifications
Clear all

Comparison: Scan times for FOSSA, SCA, and OSS Review Toolkit on the same repo.

6 Posts
6 Users
0 Reactions
0 Views
(@emilyl2)
Trusted Member
Joined: 2 weeks ago
Posts: 56
Topic starter   [#23555]

Has anyone done a real-world speed comparison between these tools? I'm looking at SCA options and scan time is a big factor for our team's CI pipeline.

I ran FOSSA CLI, Snyk, and ORT on a medium-sized Node.js repo. FOSSA finished in about 90 seconds, Snyk took 4 minutes, and ORT was over 7 minutes. This seems like a huge spread. Are my results typical, or did I misconfigure something? I'm curious what others have seen.



   
Quote
(@alexg)
Reputable Member
Joined: 3 weeks ago
Posts: 261
 

Those timings line up with what I've observed across several dozen repositories, though I'd argue your ORT time is actually on the low side for its default configuration. The disparity mostly comes down to architectural differences and what each tool considers a "scan."

FOSSA is generally fastest because it's primarily doing dependency resolution and fingerprinting locally, then shipping that manifest to its backend for heavy analysis. Snyk does more local analysis, hence the longer time. ORT is fundamentally a different beast; it's doing a full package curation, resolution, and download in its analyzer phase, which is why it's so much slower. If you ran ORT with `--skip-downloads`, you'd likely cut that time in half, but you'd lose vulnerability data for packages not in its local cache.

Your real bottleneck in CI might not be the raw scan time, but the overhead of caching and re-scanning unchanged dependencies. Have you looked at the actual pipeline duration versus the tool's runtime? For our monorepo, we saw a 300% pipeline time improvement just by implementing a proper dependency cache layer for Snyk, not from switching tools.



   
ReplyQuote
(@cost_optimizer_99)
Reputable Member
Joined: 3 months ago
Posts: 280
 

True on the caching point, but you're burying the real cost. The "300% pipeline time improvement" is a red flag.

That's not an optimization win, it's a confession your baseline was horribly inefficient. If you needed a custom cache layer to make Snyk's runtime bearable, you were paying for it in engineer hours and complexity from day one. FOSSA's speed comes from pushing analysis to their SaaS backend, which is a different trade-off, not a free lunch.

The real comparison is total cost: license fees plus pipeline minutes plus ops overhead. I'll take a slower open-source tool if it means I'm not locked into a vendor's opaque backend and my scan times are predictable.


show the math


   
ReplyQuote
(@infra_architect_rebel)
Reputable Member
Joined: 3 months ago
Posts: 224
 

Your numbers track with what I've seen, but you're measuring the wrong thing.

FOSSA's 90 seconds doesn't include the analysis latency on their backend. The clock stops for you, but the actual work isn't done. Snyk's local analysis is slower but gives you a full result right in your pipeline. ORT is doing more groundwork, like downloading packages to verify hashes.

If pipeline speed is your only metric, you'll pick the one that hides the work elsewhere. That's a vendor trap.


Simplicity is the ultimate sophistication


   
ReplyQuote
(@calebh)
Estimable Member
Joined: 2 weeks ago
Posts: 142
 

You've nailed the key distinction here. That backend latency is a real consideration, especially if you need a decision gate in your pipeline. FOSSA's results are pending until their systems finish, so your CI might pass a step that later fails in their dashboard.

It also highlights a vendor lock-in angle. That fast local time is great until you hit an API rate limit or their service has an outage, and suddenly your pipeline is stuck waiting anyway.


Trust the data, not the demo.


   
ReplyQuote
(@crm_hopper)
Reputable Member
Joined: 5 months ago
Posts: 229
 

Exactly. That "fast" scan is just kicking the can down the road. The vendor backend becomes your single point of failure for compliance. I've seen builds greenlighted because FOSSA's queue was backed up, only to get flagged for a critical CVE hours later. Makes your CD pipeline a joke.

Their API limits are the real kicker. Try running it on a dozen repos simultaneously and watch it throttle. Suddenly your 90 second scan is a 20 minute queue.


CRM is a necessary evil


   
ReplyQuote