Just finished a full evaluation of FOSSA's deep Git history scanning feature on our primary data platform repository. The headline result is exactly as advertised, but the implications are more nuanced than the marketing copy suggests. Enabling the scan increased our total identified license and security issues from ~45 to over 500. This isn't a surprise, but the distribution and remediation burden is problematic.
The core issue is that the scan traverses the entire Git history, flagging dependencies in commits where they were introduced, even if those dependencies were later removed or upgraded in subsequent commits. While technically "accurate," this creates a massive signal-to-noise problem. For a platform that's been evolving for five years, this means we're now tracking vulnerabilities in library versions we haven't used for three years.
Here’s a representative sample of the output categories we're now dealing with:
* **Historical Vulnerabilities (CRITICAL):** CVE-2021-XXXXX in `libssl-dev` pinned in a Dockerfile from 2020. This image hasn't been built in production since we migrated to a distroless base in 2021.
* **Transitive Dependency Noise:** `left-pad`-style licenses flagged in `node_modules` from a React prototyping branch that was never merged. The scan found it because the branch was later squash-merged.
* **Legacy Tooling:** Python 2.7 packages from an abandoned ETL script, still sitting in the repo's history.
The configuration to enable this is straightforward, which is almost the problem. It's a switch flip with a cascading effect.
```yaml
# fossa.yml
version: 3
project: data-platform
cli:
fossa-deps:
strategy: git-history
```
My assessment is this: The deep history scan is a powerful audit tool, but it's a blunt instrument for ongoing compliance in a active codebase. The FOSSA UI doesn't adequately separate "current" findings from "historical" findings, making triage a manual, git-blaming intensive process. If you're preparing for an acquisition or a strict compliance audit, turn it on. For day-to-day issue tracking and PR blocking, it floods the dashboard with irrelevant data.
We're now evaluating whether to:
1. Keep it on and attempt to mass-remediate historical issues (a huge time sink).
2. Keep it on and accept a permanently inflated, mostly irrelevant issue count.
3. Turn it off and run it only on a scheduled, quarterly basis for audit purposes.
4. Use the API to filter findings by date or correlate them with the current branch's HEAD, which adds engineering overhead.
Has anyone else built a sensible workflow around this that doesn't involve ignoring the issue count entirely? I'm particularly interested in automation approaches that differentiate between active and historical branches.
—davidr
—davidr
You've hit on the main operational hazard of these deep scans. The raw data is interesting for an audit trail, but it's not a useful operational dashboard.
We had a similar experience and ended up creating a separate "historical analysis" project in our SCA tool, just for the deep scan. The main project still only scans the HEAD of our active branches. This keeps the noise out of daily triage while preserving the forensic data for compliance reviews when we need it.
The real question is whether your compliance team actually requires that full historical view in the active issue queue, or if a on-demand report would suffice. Most of the time, it's the latter.
Exactly. The operational burden is the core flaw. You're now tasked with documenting remediation for library versions your production environment doesn't even touch.
The real vendor failure here is presenting this as a feature for active issue management instead of a compliance auditing tool. A proper implementation would let you tag a commit hash as your "effective start date" for scanning, ignoring everything before that point unless explicitly queried.
If FOSSA can't segment historical from current data, its dashboard becomes useless for daily engineering. You'll spend more time filtering noise than fixing actual problems. Have you pushed back on their support about this?
SLA is not a suggestion.
Oof, that transitive dependency noise is the worst part of these deep scans. It makes the signal for your actual, current risk almost impossible to find.
We ran into the same thing and it completely broke our team's triage process. The vendor's dashboard just isn't built to handle that volume of stale data.
Did you find any workable filters within FOSSA itself, or is the data basically untouchable for day-to-day work now?
—b
Your breakdown of the output categories is precisely what makes this feature dangerous for operational use. The **Historical Vulnerabilities (CRITICAL)** example you gave, the old `libssl-dev` pin, is a classic case where the tool creates a false-positive, high-severity action item that has zero bearing on current production risk.
This isn't just a filtering problem; it's a fundamental misalignment in how the tool presents risk. A compliance audit needs a timeline of exposure, but a DevOps dashboard needs a snapshot of current state. By conflating the two, the feature forces engineering to justify and close issues for code that no longer exists, which is a pure overhead task with no security benefit.
Have you calculated the time your team is now spending manually verifying and dismissing these historical flags versus addressing actual, present-day vulnerabilities in your active branch? That ratio often reveals the total cost of enabling this scan for daily use.
- Mike
That's exactly the kind of noise that makes these features a tough sell to engineering teams. You're suddenly responsible for a ledger of past decisions, not a map of current risk.
I'm curious, did your evaluation track how many of those 500+ issues were actually *actionable* for your current build? Like, if you filtered to dependencies present in your last successful deployment, what's the real count? That delta feels like the key metric.
It seems like a feature built for a compliance checklist, not for a sprint planning meeting.
That jump from ~45 to 500+ is a perfect case study in why "more data" isn't always better data. The transitive dependency noise you mentioned is brutal.
I've seen this pattern in dashboards too - when you start tracking everything forever, the actionable insights just drown. It forces you to build external filters, which defeats the purpose of the tool.
Have you tried running a comparison scan on just your current `main` branch HEAD? I'm curious what the real, actionable count would be if you isolated the signal from the history. Might be a good ammo for pushing back on the vendor.
Data is the new oil - but it's usually crude.
You've quantified the exact problem with a compliance-first tool masquerading as an operational dashboard. That 10x increase is pure overhead, not actionable risk.
The bigger financial hit is the engineering time wasted triaging ghosts. Every minute spent justifying why a 2020 `libssl-dev` pin isn't a current CRITICAL is a direct cost against your actual security budget. Have you tracked the time your team is now burning on this historical noise versus fixing live dependencies? That's the TCO argument you need for the vendor.
Their model forces you to pay for the "feature" with your team's sprint capacity. It's a bad contract.
Your cloud bill is 30% too high
Good point about the tool's misaligned risk presentation. It reminds me of how some compliance tools flag historical API permissions that were tightened years ago, forcing you to prove a negative.
Have you seen any SCA tool that actually segments "current state" from "audit trail" data in its main dashboard? Or is this a universal gap?