我们有一个 .Net 4.0 项目，正在被 Veracode 扫描以获得安全认证。
在静态扫描期间，发现了以下漏洞： SQL 命令中使用的特殊元素的不正确中和（“SQL 注入”）（CWE ID 89）请参阅https://cwe.mitre.org/data/definitions/89 中的详细信息。 html
似乎引用 Dapper 的报告详细信息文件和行号：
OurOwnDll.dll 开发/.../dapper net40/sqlmapper.cs 1138
App_Browsers.dll 开发/.../sqlmapperasync.cs 126
OurOwnDll 正在使用 Dapper。
App_Browsers.dll 我不知道它来自哪里，但似乎与站点项目有关，并且似乎与 asp.net 的浏览器功能检测有关。
我想知道是否有任何方法可以防止此漏洞。
我不熟悉 VeraCode，但是正如@Kristen Waite Jukowski 指出的那样，您的问题可能是由于您的某些查询没有参数化，在这种情况下，它们被正确地识别为易受 SQL 注入攻击。
或者，一个类似的问题（与同一问题有关，但与 OrmLite 相关）可能会对此有所了解。与 OrmLite 类似，由于 dapper 提供了编写原始 SQL 查询的工具，这些查询可以由未参数化的输入（例如通过字符串连接）组成，使用它可能被视为漏洞，即使您的特定项目中的每个查询当前都是完全参数化。该问题的答案（在您的情况下可能不可行）是用实体框架替换现有的 ORM：
在使用 VeraCode 读取代码期间，建议的适当补救措施是用 EntityFramework 6.1 替换 ServiceStack ORM。
从该问题的评论中：
不同之处在于 EF 中，执行上下文实现了 IDbCommand，但 CreateDataAdapter 和其他可以允许动态 sql 的 api 已实现抛出异常。EF 中没有允许动态 sql 的代码路径，而无需首先通过类似于 OWASP 的过滤机制。