当DevSecOps出问题时：华为源代码的简短教训

有一种趋势是统一安全性和开发人员流程，这种趋势有多种名称，例如DevSecOps和“向左移动”。通常，安全团队似乎比开发人员团队更热衷于此，开发人员团队将安全性称为“烦人的琐事”或“令人厌烦的程序障碍”。如果开发人员不相信代码强化构想，那么有趣的事情可能会出错。

我最近在阅读2019年英国政府对华为的安全评估，该评估提供了一个幽默的例子：一个LTE基站的开发人员使用#define重新定义了诸如strcpy之类的unsafe_function到诸如strlcpy之类的更安全变量。特别：

最终，该报告发现在代码库中，大约11％的类似于memcpy的函数调用和22％的类似于strcpy的函数调用是最不安全的变体。并且仅从函数名称假设安全性就简单了-即使安全性变体仍然可能很危险。

在华为的辩护中，尽管他们受到了不同寻常的公开审查，但绝对不会让开发人员采用安全的编码准则。就memcpy案件而言，自2009年起就被Microsoft禁止使用，但我个人还没有看到FAANG以外的其他公司（Facebook / Apple / Amazon / Netflix / Google）也这样做。通过查看二进制文件，您实际上可以凭经验判断是谁禁止了POSIX的不良功能-一家名为CITL的非营利组织对此进行了详尽的介绍，并在IoT领域进行了更多介绍。您可能会猜到，结果令人沮丧。

我和Clint Gibler最近在Global AppSec SF 2020上发表了关于我们认为是成功弥合开发人员/安全性鸿沟的一些核心原则的演讲。如果您想快速入门，我们建议三个原则：

要快：扫描应该并行运行，并且比最慢的测试要快。否则，您将阻止开发人员的工作流程。

早点：如果您要抱怨，那么编辑器胜于提交时间胜于CI。

自动修复：不只是抱怨，提供修复。 即使是不完美的建议总比没有好。 附言 如果您周围有庞大的C代码库，并且想弄清楚使用了多少strcpy，则最快的两种方法可能是ripgrep（超快速grep（嘈杂，最快））或Semgrep（语义grep-for-code（ 精确，慢；完全公开-我从事Semgrep！）。 这两种方法都可以做到： 我们显然可以尝试改进正则表达式以避免在行的开头// //，但是我们还必须考虑/ *，如果我们真的想做对的话还需要考虑更多，因此，这样做可能会很不错 有一个正确的解析器，这就是Semgrep提供的。 如果您对语法感到好奇，可以花几分钟时间阅读在线教程，也可以阅读文档。 （请注意，Semgrep在Webkit上有一些解析失败； C支持仍在alpha中） 获取有关Semgrep最新功能和我们的安全性研究的最新消息。 我们承诺永远不会向您发送垃圾邮件。