Mend's CLI scanning - any gotchas for monorepos?

Having recently undertaken a comprehensive evaluation of SCA and license compliance tooling for a large-scale data pipeline and analytics platform, I found myself deep in the weeds with Mend's CLI scanner. Our environment is predominantly a monorepo housing multiple microservices, shared libraries, and infrastructure-as-code modules, which presents unique challenges for dependency analysis. While Mend's documentation covers the basics, I've encountered several operational nuances that seem to be under-documented, particularly around performance and accuracy.

The primary issue revolves around the `mend sca` CLI's behavior when pointed at a monorepo root. By default, it attempts to traverse the entire directory tree, which can lead to excessively long scan times and, in some cases, memory issues. The `--recursive` flag is implicit, and controlling its depth or excluding certain paths requires careful configuration. For instance, we have a `vendor/` directory and generated proto files that are irrelevant for SCA scanning but are processed nonetheless.

A more subtle "gotcha" involves the aggregation and deduplication of findings. When multiple services within the monorepo use the same vulnerable library but at different versions, the CLI's output can become ambiguous. Does the aggregated report correctly attribute each finding to its respective service path, or does it flatten the results? Our testing showed that without proper project identification via the `-p` flag for each discrete component, the results merged, complicating remediation efforts.

Here is a snippet of the configuration pattern we adopted to mitigate these issues, using a wrapper script to effectively partition the monorepo:

```bash
#!/bin/bash
# scan_components.sh
# Iterate over known service directories within the monorepo
COMPONENTS=("ingestion-service" "processing-engine" "shared-lib" "web-api")

for COMPONENT in "${COMPONENTS[@]}"; do
echo "Scanning $COMPONENT..."
mend sca -p "monorepo-$COMPONENT"
--sourcePath "./services/$COMPONENT"
--exclude "**/test_fixtures/**"
--exclude "**/vendor/**"
--resultFile "./reports/$COMPONENT-results.json"
done
```

Key observations and questions for the community:

* **Performance:** Scan time scales non-linearly with the number of unique `package.json`/`pom.xml` files, not just total file count. Has anyone found an optimal batch size or a way to effectively cache intermediate scan results?
* **Configuration Drift:** The `.mend` scanning policy files seem to be picked up only from the current working directory or a user home directory. In a monorepo, we need distinct policies per component type (e.g., Node.js vs. Go). Is there a pattern for embedding policy files within subdirectories that the CLI will respect?
* **False Positives in Transitive Dependencies:** We've noted a higher incidence of false positives for vulnerabilities flagged in transitive dependencies of Go modules compared to our scans of a polyrepo setup. This appears related to how the CLI reconstructs the go.mod graph. Any similar experiences or mitigation strategies?
* **Integration Overhead:** While the CLI outputs machine-readable JSON, correlating findings back to the specific commit and path for CI/CD reporting requires additional scripting. Has anyone built a robust pipeline for monorepos that ties Mend results into granular pull request comments?

I am particularly interested in comparative insights from those who have also evaluated tools like Snyk, DependencyTrack, or FOSSA in similar monorepo contexts. The trade-offs often lie in the granularity of path mapping versus the sheer speed of the scan.