VulnerableCode currently is one of the best data sources out there for vulnerabilities, although since our upstream data has a lot of inconsistencies/versioning issues/advisory quality issues etc, it makes it looks as though vulnerablecode is not exhaustive.
I'm proposing a VulnerableCode search engine that could search based on advisory's original text instead of purl or vulnerability/advisory. The output would contain all the unstructured advisories and the structured relationship among packages and vulnerabilities. In a sense, this will be Google for VulnerableCode.
For example, the package grocy has no matches in current vulnerablecode deployment, possibly because there was some problem parsing purl from the advisory. Although, we have multiple advisories fetched on grocy (12 in fact).
This is in no manner authoritative data source as VulnerableCode's default search since mere presence of a package name in the advisory does not prove that the package is vulnerable, but it does signal interest in the advisory if there's an interest in the package mentioned.
I've created a mock app that demonstrates this. For the above example, this is how it looks: https://advisory-search.hritik.sh/?q=grocy
VulnerableCode currently is one of the best data sources out there for vulnerabilities, although since our upstream data has a lot of inconsistencies/versioning issues/advisory quality issues etc, it makes it looks as though vulnerablecode is not exhaustive.
I'm proposing a VulnerableCode search engine that could search based on advisory's original text instead of purl or vulnerability/advisory. The output would contain all the unstructured advisories and the structured relationship among packages and vulnerabilities. In a sense, this will be Google for VulnerableCode.
For example, the package
grocyhas no matches in current vulnerablecode deployment, possibly because there was some problem parsing purl from the advisory. Although, we have multiple advisories fetched ongrocy(12 in fact).This is in no manner authoritative data source as VulnerableCode's default search since mere presence of a package name in the advisory does not prove that the package is vulnerable, but it does signal interest in the advisory if there's an interest in the package mentioned.
I've created a mock app that demonstrates this. For the above example, this is how it looks: https://advisory-search.hritik.sh/?q=grocy