ADO流水线因Grpc.Core未启用控制流防护（CFG）触发BinSkim检测失败的核心包级修复方案咨询

嘿，这种第三方底层组件的安全合规问题确实挺闹心的，我来给你梳理几个核心包层面的可行解决方向：

• 直接推动Grpc官方修复编译配置
  Grpc.Core是官方维护的组件，你可以在它的官方代码仓库提交问题反馈，把你的场景说清楚：基于.NET 8的Azure Durable Function隔离模型、BinSkim抛出的BA2008错误详情、以及CFG这个Windows安全特性的合规要求。社区的真实生产场景反馈，通常会让官方团队评估并在后续版本中启用CFG编译选项，毕竟这是主流的安全防护要求。

• 排查依赖链是否有更合规的替代路径
  你当前的依赖链路是Microsoft.Azure.Functions.Worker.Extensions.DurableTask → Microsoft.DurableTask.Worker.Grpc → Microsoft.DurableTask.Grpc → Grpc.Core，可以检查一下Microsoft.Azure.Functions.Worker.Extensions.DurableTask的最新版本，看看是否已经把底层依赖从旧的Grpc.Core迁移到了更现代的gRPC .NET实现。不少Azure SDK的新组件已经逐步淘汰了旧的Grpc.Core原生包，这类新实现大概率已经满足CFG的编译要求。

• 向Azure Durable Functions团队反馈依赖问题
  除了找Grpc官方，也可以给Azure Durable Functions的维护团队提反馈，说明他们的扩展包依赖的Grpc.Core存在安全合规缺口，请求他们升级依赖到支持CFG的Grpc版本，或者切换到更安全的替代依赖。Azure生态的企业级组件通常会比较重视这类安全合规的用户诉求。

如果官方修复的周期比较长，你也可以考虑临时的规避方案（比如在BinSkim的检测配置里排除这个DLL），但这只是权宜之计，毕竟会削弱安全检测的覆盖范围，所以还是优先推动核心包层面的根本修复。

备注：内容来源于stack exchange，提问作者soumyadeb ghoshal