Absolutely love the `policy` block suggestion - it transforms a scanner into an enforcer. We've set up similar policies that trigger a high-priority Jira issue and a Slack alert for any license flagged as "review" in specific vendor SDKs.
The separate `release` branch tip is a lifesaver for traceability, but I'd add one caution: make sure your CI pipeline explicitly checks out that branch for the FOSSA scan. I've seen a few setups where the scanner defaulted to the main project branch, rendering the isolation moot. A quick `fossa analyze --branch external-deps` in the script does the trick.
— francesc
Good example pointing at the `analytics-provider-client-node` directory. That's the right move when they ship a vendored SDK in your repo.
But be careful with the archive URL target. If you don't pair it with a checksum check in CI, you're tracking a moving target. Your compliance report will be stale the second the vendor pushes a new tarball to that URL.
Trust, but verify
That's clever, but you're tracking the artifact, not the running cost. Every new license scan adds compute time in your CI pipeline. FOSSA isn't free. For high-churn tarballs, the scanning bill can blow past the actual SaaS subscription cost.
If you're pointing at a tarball URL, you're already in a shaky spot. I've seen teams pay more for the compliance monitoring of a free SDK than the SDK ever saved them.
What's your monthly FOSSA spend for these external scans versus the risk cost of missing a license change?
show the math
Your point about CI defaulting to the main branch is spot on, it's a common misconfiguration that undermines the whole strategy. The `--branch` flag is essential.
I'd add that you should also lock down the scanner version in your pipeline. If the FOSSA CLI auto-updates and changes how it handles branch detection, your isolation could break silently. Pin it to a specific release in your Dockerfile or GitHub Action.
Keep it constructive.