Skip to content
Notifications
Clear all

best open source dependency scanner that works with FOSSA workflows

19 Posts
18 Users
0 Reactions
21 Views
(@chloer8)
Reputable Member
Joined: 2 months ago
Posts: 238
 

The noise from documentation and test fixtures is the real ScanCode tax. We solved it by running ScanCode with `--ignore` patterns first, but then you're back to tuning filters forever.

Your Java example hits the core issue: it's only worth that sprint of filter work for messy, critical legacy systems where the manifests are unreliable. For clean repos with modern package managers, that investment rarely pays off.

You end up maintaining two workflows anyway, one for legacy and one for everything else.


SLA is not a suggestion.


   
ReplyQuote
(@diego_h)
Honorable Member
Joined: 6 months ago
Posts: 313
 

> The real answer... after wasting more hours than I care to admit

That resonates. I'm just starting to look at this and the setup time is what scares me. If ScanCode needs a ton of massaging just to feed FOSSA, where does a beginner even start? Is there a recommended format, like SPDX, that works more cleanly with FOSSA's ingestion?


Still learning.


   
ReplyQuote
(@auditor_abby)
Reputable Member
Joined: 6 months ago
Posts: 363
 

Start with the FOSSA CLI's own analysis. It's their tool, so the output is built for their ingestion API. It's not as deep as a full ScanCode run, but it's reliable and gives you a baseline without the formatting headaches.

If you must use a third-party scanner for deeper inspection, SPDX is the way to go, but only version 2.2 or 2.3. FOSSA's documentation is quiet about this, but their parser chokes on older SPDX tag-value formats. The pain point isn't the format itself, it's the scanner's ability to output a clean, compliant SPDX document.

The real beginner step is to test the entire pipeline, end-to-end, with a single known dependency. Get that working before you scale. Otherwise you're debugging a mass of SPDX tags at 2 AM.


Where is your SOC 2?


   
ReplyQuote
(@amyw)
Honorable Member
Joined: 2 months ago
Posts: 427
 

Totally agree on starting with the FOSSA CLI for baseline. That got us unblocked in a day.

The > single known dependency test is the golden rule. We once tried to onboard a whole monorepo first and spent a week chasing phantom SPDX errors. Turns out one weird internal package had a malformed license field that broke everything.

I'd add that even with SPDX 2.2, check for those license expression strings. Some scanners output deprecated identifiers like `GPL-2.0` without the `-only` suffix, and FOSSA's API just silently drops those entries. The logs show nothing 😅


measure twice, ship once


   
ReplyQuote
Page 2 / 2