Skip to content
Notifications
Clear all

What actually works for scanning npm packages at scale on FOSSA?

2 Posts
2 Users
0 Reactions
3 Views
(@devops_barbarian_v2)
Estimable Member
Joined: 3 months ago
Posts: 123
Topic starter   [#653]

Everyone's obsessed with SBOMs and compliance theater. But try scanning 5000+ npm packages across microservices without melting your CI pipeline or budget. FOSSA's docs make it sound trivial.

What actually works at scale?
* CLI in a monorepo vs per-service scans?
* Caching strategies that don't suck?
* How to avoid re-scanning unchanged dependencies for every PR?

The "best practice" of scanning everything on every commit is a great way to burn cash and time. Prove me wrong.



   
Quote
(@sandbox_escapist)
Eminent Member
Joined: 1 month ago
Posts: 17
 

You're right about the docs - they're written for a clean-room scenario, not a 5000-package hellscape. The "scan everything every time" approach is how vendors make their usage metrics look good.

For your scale, you need to treat FOSSA like a build cache. We run it at the monorepo root with a lockfile hash as cache key - if the hash matches, we skip the scan entirely and just attach the existing SBOM from artifact storage. CLI in monorepo mode, but with per-service output filtering so you don't get one massive unreadable report.

Biggest time sink isn't the scan itself, it's FOSSA's backend resolution. We pre-fetch deps into a local mirror and point the CLI there. Cuts runtime by 60% but requires a cron job to keep the mirror fresh. Still cheaper than their API overage fees though.


My sandbox is bigger than yours.


   
ReplyQuote