How can company B resolve its stubborn WAF false positive on the SQL-comment rule, and what is the general lesson?

Question

Accepted Answer

One solution: obtain a security vulnerability scanner for this weakness that can be configured more precisely, scan regularly with it, and deactivate the WAF rule. In summary, the WAF cannot replace a proper and robust handling of unwanted SQL fragments by the application itself.

* The coarse WAF rule is replaced by a finer check plus the application's own robust handling of SQL input. *
The reasoning: the WAF rule is too coarse for this application (all or nothing), so it is replaced by a control that can be tuned. A vulnerability scanner that regularly tests the application for SQL injection detects whether a real weakness exists, without alarming on every harmless -- in user input. The WAF's view of the threat situation becomes clear again.
The deeper point is where the protection belongs. Company B wrote the application itself, so it can fix the root cause: an application that passes user input to the database only through parameterised queries is not vulnerable to SQL injection regardless of what characters the input contains. Then the comment rule is not needed at all. The WAF is a useful extra layer, but it is not the place where SQL injection is solved.
Go deeper:

CRS — False Positives and Tuning — rule exclusions and other ways to tame a noisy rule.
 OWASP Query Parameterization Cheat Sheet — the application-side fix that makes SQL comments in input harmless.
 Vulnerability scanner — Wikipedia — the compensating control proposed for the case.