Hi @yogurt-ui

Thank you for this false positive report. Resolving this issue is not a current product priority, but we acknowledge the report and will track it internally for future consideration, or if we observe repeated instances of the same problem.

@yogurt-ui I would like to make sure that we understand your issue. I assume dl in your code excerpt is a mongo.Collection. We consider it a (no)sql injection if any user-controlled data can flow to the second argument to Collection.Find. Do you disagree with this? Or do you think that in your specific situation, user-controlled data cannot flow there? If so, I would need to see more information about the alerts to understand what is going wrong.

@yogurt-ui I would like to make sure that we understand your issue. I assume dl in your code excerpt is a mongo.Collection. We consider it a (no)sql injection if any user-controlled data can flow to the second argument to Collection.Find. Do you disagree with this? Or do you think that in your specific situation, user-controlled data cannot flow there? If so, I would need to see more information about the alerts to understand what is going wrong.
Sorry, I missed a condition，filterM is a structured map type, so it does not pose an injection risk.
type LogFilter struct {
ID []string
}
filter *LogFilter
filterM := bson.M{}
filterM["id"] = filter.ID
cur, err := dl.Find(ctx, filterM, opts)

Are you saying that if the second argument of Collection.Find has type bson.M then there cannot be a no-sql injection attack - perhaps because it will be escaped? If so, can you point me to some documentation of that? I wasn't able to find any. On the contrary, the documentation for bson.M says "There's no special handling for this type in addition to what's done anyway for an equivalent map type.", and I found this article which says that it is vulnerable.

It might help if you could point me to a FP detected by code scanning, if there is one publicly visible.