x/vulndb: consider encoding known false positive paths in reports #51574
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
vulncheck or vulndb
Issues for the x/vuln or x/vulndb repo
Milestone
Looking at #51565, this is an obvious case of a false positive. Any package that imports x/text will be immediately marked as vulnerable, since there is a (non-vulnerable) usage of the vulnerable symbol in an
init
function.This seems like something we should be able to avoid, since it creates noise that is likely to irritate users and maintainers. Possibly including some metadata in the report could help vulncheck ignore these kinds of cases. One option is to include call chain fragments which vulncheck can use to ignore specific chains during analysis. For example in this case any chain terminating in
x/text/cases.init#1 -> x/text/language.MustParse
can be safely ignored, since we know that particular invocation is not vulnerable.Also, we should look into tooling that detects, or at least surfaces, this kind of issue during report ingestion.
cc @golang/vulndb
The text was updated successfully, but these errors were encountered: