False-Positive: I raised the topic on discord. I compared the DT, Depscan, and Grype analyzers. The results are presented in the table. I think it will be useful for correcting the quality of the analysis.

[almaz045]

PURL of wrongly matched component

stats-github.ods
depscan-bom.json
sbom-source-syft(1).json

Depscan findings

Of course, the method for determining FN may not be correct enough, since in some cases I determined it by context, and not by how the scanner searches.
I have scanned this before with cdxgen 10.2.2.
20 (report on cdxgen sbom) vs 245 (report on syft sbom)

From our conversation:
I counted the number of FNs based on context. In some cases of FN Depscan worked correctly relative to the SBOM report. For example, there was a PURL with pkg:poco/poco@1.9.4., and its CPE in the SBOM report is indicated as cpe:2.3:poco:poco:1.9.4:::::: :. But there is no such CPE in the NVD database, but there is something similar to cpe:2.3:pocoproject:poco:1.9.4:::::::.. And after analysis, I understood , that this is the same thing, it’s just called differently in Conan. In this case, the problem is not with Depscan, but still, relative to the context, it did not find it, and we lost one CVE. I understand that other tools have found due to a fuzzy match (I assume), but Depscan only looks for a clear match.
If we talk about CVE-2023-39323, then in NVD it refers to go (cpe:2.3:golang:go:::::::: - before 1.20.9), and in SBOM there was a component with cpe: cpe:2.3:golang:go:1.15.2:-::::::. That's why I decided that depscan should have found it by cpe.

[prabhu]

@almaz045, can you also test vdb6? You can run it with --bom argument. It supports searching by both cpe and purl so must perform a bit better than depscan v5.

https://github.com/AppThreat/vulnerability-db/blob/master/vdb/lib/search.py#L175-L178