I did something similar a while back to ensure we were keeping up with security updates. It's all manual, though: I can't help you automate it but I can tell you how long it took me and give an example of what I ended up using.
The initial setup took a couple days (we use > 75 libraries), and since then it's just been an hour or less per week to maintain it (not counting the time to actually update the libraries we use). I ended up with a matrix in a spreadsheet, with a row for each library we used. Then the columns were:
- version we use
- last version I checked
- NEWS file (any issues I identified from scanning the NEWS or other readme files provided by the library)
- CVEs (known to exist in our version)
- latest version available from our vendor (we don't pull directly from upstream)
- status, which says "OK" if NEWS and CVEs are empty and latest-version-checked matches latest-version-available, or I manually set it to some other status like "needs future fix" or whatever is appropriate
- notes
I filled out the table with our libraries and their versions, then downloaded the full CVE database in text format and used a good text editor to search it for each of our applications. If there were any CVEs for our libraries I listed them in the CVE column and added notes about the version where they were fixed and/or why they applied to us (or in the case of some well-known CVEs, why they didn't).
I also skimmed the NEWS files for most of the libraries that had newer versions available than what we were using, though I gave up on that after a while when it didn't yield anything useful that wasn't already captured in a CVE.
Then I subscribed to an RSS feed of newly-categorized CVEs. It's fairly low-volume, though bursty, so when new CVEs come in I quickly scan them for issues and update my spreadsheet if there's anything that applies to us.
I also made a cron job to scan a different list of newly-filed CVEs, but that didn't seem to add any value beyond what the NVD RSS feed provided.