Unfortunately, sometimes navigating CPE's actually is difficult. CPE's have a common structure (bits of information that must be present), but there's not really any body that governs correctness or completeness of the data submitted from the vendors - e.g., Microsoft submits CPE's for their own products, and while what they submit is reviewed, it's often ambiguous.
This frequently happens with client libraries for server products. You'll see this with websphere client libraries, database drivers (as you see here), etc. While the driver itself is not necessarily vulnerable, if I'm not the developer, I tend to NOT suppress those - the client libraries can be a means by which we discover what the development teams are running on the server - which should also be updated.
In the case of NLog, the challenge here is that the Nuspec only has the package name (nlog) and the DLL reports the company name as NLog and the package name as NLog and the version as 188.8.131.52. This is the information that the vendor put in the assembly. If you look at the CVE mentioned, the CPE's that match that are cpe:/a:nlog:nlog - and any version. So this one is one that would need to be suppressed.
There's not currently a global suppression list, although I'm trying to figure out the best way to manage that - whether we deploy a known set of things like this that should simply globally be set, or if we can use other analyzers to limit it. I think that this maelstrom of false positives we're getting are primarily in .NET stuff, which is not surprising since the .NET analysis is brand new. We'll have to figure out some better ways to handle .NET stuff, but as of right now, for your specific questions, I don't have good answers except to use the suppression file, and *thank you* for pointing these out to us. The ability to make the findings more accurate is only improved by scanning MORE stuff and getting more intel back from the community.