Six months into our FOSSA migration, and I can finally give a verdict on the "policy management" promise that sold us. The marketing pitch was all about "developer-friendly," "dynamic policies," and "shift-left." Reality? It's a mixed bag with some sharp edges.
First, the good: the shift-left integration is genuinely better than Black Duck's clunky plugins. Developers see license warnings in their PRs without having to leave GitHub. That part works. The policy *configuration* is also more flexible. You can write rules based on license families, risk scores, or even specific package patterns. Here's a snippet from our `fossa.yml` that Black Duck would have required a support ticket to implement:
```yaml
version: 3
policy:
rules:
- license: GPL-*
action: block
message: "GPL family licenses require legal review."
- license: MIT
action: flag
conditions:
- "package.age > 3650" # Flag ancient MIT packages
```
Now, the sardonic part. The "dynamic" policy engine feels like a leaky abstraction when you need complex logic. Want to block a package only if it's *both* GPL-licensed *and* has a known critical CVE? You'll be stitching together webhook workflows and custom scripts, which brings us right back to the infrastructure we were trying to simplify.
The biggest gap? **Incident audit trails are weak.** When a policy blocks a build, finding out *which specific rule* triggered it, and the historical context of that rule's decisions, is a multi-click hunt. In Black Duck, that postmortem trail was atrocious, but I expected better here. For a compliance audit, I need a clear, immutable log of policy evaluations, not just a "denied" status.
Other observations:
* The cost model based on "policy evaluations" can get murky. A scan that touches 1000 dependencies and runs 10 rules isn't 10,000 evaluations, but the billing breakdown isn't as transparent as I'd like for a cost audit.
* The "auto-remediation" suggestions are often naive (upgrade to latest major version) and ignore real-world dependency hell.
* The dashboard for policy violations over time is useful for trending, but lacks the granularity to tie spikes to specific CI/CD or developer events.
Bottom line: It's an improvement for developer experience and configuration flexibility, but don't believe the hype that it's a fully baked, auditable policy engine. You'll still be building parts of the monitoring and incident response pipeline yourself.
- Nina
- Nina