The rule of thumb is when your blocklist turns into a spreadsheet with 50 footnotes. That's your policy engine, you're just writing it manually.
You hit the nail on the head about SBOMs. If your tool makes you think about SBOMs *first*, it's backwards. You need to find problems first, then generate the artifact. The other way just creates busywork.
Your breaking point comes when a dev asks "why is this library blocked?" and you spend more than 5 minutes explaining the exception chain. If you're constantly making one-off excuses for your blocklist, you've outgrown it.
-- old school
The "still the best" question assumes there's a universal best, which is where you'll get burned. The real metric isn't feature lists, it's signal-to-noise ratio for *your specific stack*.
You mentioned containerized apps. Pull your five most used base images and run a free Grype or Trivy scan. The output will be a mess of transitive dependencies you can't change. If FOSSA's strength is its granular policy engine, but 40% of your initial alerts are from `alpine:latest` packages, you're paying a premium to ignore noise.
For a small team, start by quantifying that noise. The tool that wins is the one that lets you focus on the 10 licenses in your actual application code, not the 200 in the underlying distro.
Benchmarks or bust
Totally agree on the target fit - that's the biggest trap. Even at a 300-person shop, if the devs aren't the primary users, adoption craters. We tried FOSSA a few years back and the policy engine tuning became a full-time job for a month.
The "hidden cost is in configuration time" part is so real. But I'd add that the cost also comes when you *don't* tune it enough. We let some noisy rules slide initially, and then during a funding round due diligence, the audit report was a 200-page monstrosity of false positives. Spent a frantic weekend cleaning it up. The tool's strength becomes a liability if you're not prepared to govern it tightly from day one.
cost first, then scale
"Best" for a small team just starting out, on a budget, in 2026? Not a chance it's FOSSA.
They're the heavyweight audit champion, and you're asking about learning to jog. You'll pay a premium for a policy engine you won't use correctly for a year, and you'll drown in false positives from your base images.
The landscape has changed because the simple, good-enough tools are actually good now. Run Trivy once. If the sheer volume of license noise makes your eyes glaze over, *then* you have a case for needing a more granular policy tool. Until then, you're buying a crane to hang a picture.
Several of the replies have already pointed out that "best" is a dangerous framing, and they're correct. Your key phrase is "small team just starting with this," which moves the decision from a feature comparison to a scaling exercise.
The risk isn't that FOSSA isn't capable. It's that its primary value is in audit-grade reporting and granular policy, which are burdens you likely don't carry yet. Implementing it properly requires upfront policy definition that a new team often lacks, leading to the false-positive deluge others mentioned. You'd be paying for a powerful engine while running it on bad fuel.
For containerized apps specifically, I'd suggest a two-stage approach. First, run a free scan with Trivy ( `trivy image --scanners license your-image:tag` ) against a couple of your production images. The output will show you the volume of license data, and more importantly, how much of it comes from base image packages you don't control. That's your noise floor.
If that exercise yields a manageable list of 10-15 distinct licenses in your own code, you can likely handle it with simpler tooling and a documented blocklist. If it generates hundreds of lines and the thought of manually reviewing it makes you wince, *then* you have a data point that justifies investigating a policy engine like FOSSA's. Start with the problem's scale, not the tool's reputation.
Plan the exit before entry.
Your two-stage approach is sound, but I'd emphasize the intermediate step you hinted at: policy definition. Running Trivy first is excellent for quantifying noise, but that second stage - deciding what to do with the data - is where teams stall.
After getting that initial scan, the next action shouldn't be tool selection. It should be a one-hour session to document three things: your "must-block" licenses (e.g., AGPL), your "require review" licenses, and crucially, your accepted noise sources (like `alpine:latest` packages). This document, even as a simple wiki page, becomes your fuel. Then you can evaluate if a tool's policy engine cleanly encodes those rules or fights you.
Without that list, you're right, you'll be paying to run a powerful engine on bad fuel. But with it, you can test whether FOSSA's granularity is an asset or overkill by seeing how smoothly it implements your predefined exceptions.
This is exactly where we got stuck. We wrote down our must-block list, but the "accepted noise sources" category kept expanding until it felt useless.
How do you keep that from becoming a dumping ground for everything you don't want to deal with? If you're adding a new distro package to the noise list every week, doesn't that just prove the tool is wrong for your stack?
The question "is it still the best" sets up the wrong comparison. The best tool for a small team starting out is the one with the lowest activation energy that still solves your specific risk.
For containerized apps, start with a free CLI scan like Trivy. If the license report is under two pages, you don't need FOSSA's complexity. If it's twenty pages of transitive dependencies from base images, then you have a data problem, not a tool problem. No policy engine fixes that.