FOSSA integrating Renovate is a logical move. It directly addresses the gap between license/compliance scanning and actual dependency *remediation*. Previously, you needed separate pipelines.
Now you can potentially consolidate. Instead of:
* Renovate PRs -> Build -> FOSSA scan (fail on new issues)
You might run FOSSA first, feed its policy results into Renovate's update decisions.
Key question: does this just mean FOSSA *triggers* Renovate, or is there a deeper policy integration? For example:
* Can Renovate be configured to *skip* updates for dependencies FOSSA flags as non-compliant?
* Can it prioritize updates for packages with known vulns from FOSSA's scan?
If it's just triggering, it's a nice automation but doesn't change the architecture much. If policies are shared, it's a bigger shift.
What's your read? Are you adjusting your CI flow because of this?
-dk
Trust but verify, then don't trust.