I'm working on some updates to the handbook and we're rolling out some (relatively minor) updates to the "Create a CQ" functionality on the PMI. My apologies to all that this is taking longer than I'd hoped.
The short version is that you don't need any tools to not create a CQ.
In this particular case, we know that the libraries in question have been approved by the IP due diligence process, so just don't create any new CQs. The challenging bit is how we make it easier for committers to know that they don't need to create a CQ; I'm working on a solution to that problem that I've committed to rolling out this quarter (at least part of which will be contributed to Eclipse Dash, so you all can help maintain it). I need you to be patient for a little while longer for this.
The slightly longer version is that I've spent a lot of effort to get our existing IP data into a state where we can do more in an automated manner. Over the years we've collected a lot of data, but--as you likely already know--it's not been collected in a form that makes it consistently queryable. I've got that (mostly) sorted out. We're also starting to leverage license data from Clearly Defined, a project which crowd sources license data from open source projects. My expectation is that we will still need to create CQs for third party content, we'll just have to create a lot fewer of them. Those that we do create will follow the same process that we do today. Again, I owe a longer explanation.
Regarding IP Logs, I've been experimenting using build tools to fill in the gaps. This works pretty well for Maven-, Gradle- and NPM-based builds, where you can build an accurate dependency list right out of the tool (e.g., "mvn dependency:list"). FWIW, the tools that I referred to have evolved from scripts that I've been using for a few months to map the results from that dependency list to license and CQ information. I'll start attaching the output from the scripts to IP Log CQs as a stop gap.