I've been conducting a detailed evaluation of FOSSA for our revenue operations and sales engineering teams over the last quarter, with a particular focus on its integration into our CI/CD pipelines for internal tooling. A persistent and significant operational hurdle has been the system's handling of our internal, private packages, specifically within our monorepo structure for sales automation and CRM analytics modules.
The core issue is a high rate of false-positive license and vulnerability flags. These are not edge cases, but foundational, internally-developed packages that have no external dependencies. For instance:
* Our proprietary **`forecast-model-utils`** package, which contains pure business logic for pipeline forecasting, is consistently flagged for a "missing license" and, on several scans, was incorrectly associated with a low-severity vulnerability in an Apache Commons library it does not and cannot import.
* The **`crm-event-schema`** package, a private TypeScript definition library shared between our front-end dashboards and backend services, is identified as having a "GPL-3.0" license, which appears to be a misidentification from a fragment of boilerplate documentation text.
The consequences for workflow are tangible. This creates noise that:
* Dilutes the credibility of critical, actionable reports on *actual* third-party risks, forcing manual triage and eroding developer trust.
* Introduces friction into the release process for our sales enablement tools, as these false positives must be documented and overridden, adding bureaucratic steps.
* Complicates audit trails and data governance efforts, as the compliance report is polluted with entries that require explanatory footnotes.
My configuration follows FOSSA's standard recommendations for monorepos, and I have attempted to utilize exclusion rules in the `.fossa.yml` file to no lasting avail—the flags often reappear in subsequent scans with different justifications. The total cost of ownership calculation is impacted by the manual effort required to maintain a clean bill of health.
I am seeking to understand if this is a common experience within the community, particularly for organizations with complex, private codebases. What strategies or configuration patterns have proven effective in suppressing these false positives for truly internal code, without compromising the detection of legitimate issues in our actual open-source dependencies? Is there a systematic approach to defining and scoping "internal" that the tool reliably respects?