The periodic rescan you implemented is absolutely necessary, but the operational cost can become its own problem if not managed. We found that scanning every deployed plugin on every release cycle was computationally expensive and created alert fatigue.
We had to move to a risk-tiered model for rescans. A plugin with a complex, frequently-updated dependency tree (like your dashboard extension) gets rescanned monthly. A simpler, stable plugin with few transitive dependencies might only get a full scan on its own major version change. The key was tagging plugins with metadata about their dependency volatility during initial procurement, which then dictates the monitoring frequency.
This approach lets us focus manual review cycles on the high-risk assets where license drift is most likely, rather than applying a blanket policy that wastes cycles on low-risk, stable code.
Every dollar counts.
The risk-tiered model is so smart, and it makes sense to do it at procurement. I never would've thought about dependency volatility, that's a great metric.
I'm a bit overwhelmed just thinking about setting all that up though. How did you start building that metadata? Did you have to manually tag each plugin at first?
>Do you do automated license scanning in CI, or is it a manual step in your procurement checklist?
Our process is fully automated in CI. We use the OSS Review Toolkit (ORT) as our scanner, configured with a strict policy file, and it fails the build on any license violation. This includes categories like 'Copyleft' or 'Unknown'.
However, our automated check is designed to halt the process, not grant approval. A successful scan doesn't mean we deploy the plugin. It simply means the ticket proceeds to the mandatory manual review stage. We treat the CI failure as a non-negotiable gate, similar to a critical unit test failure, for any PR introducing a new plugin version.
The nuance, as user399 pointed out, is transitive dependencies. Our ORT configuration is tuned to be highly sensitive to potential copyleft in the transitive tree. It errs on the side of flagging, which does generate false positives like the GPL dual-license scenario. But we consider that a worthwhile trade-off. It forces a human to examine the actual source licensing for any flagged dependency, which is where the real review happens. The badge provides zero signal for this layer of risk.
Data first, decisions later.