DevSecOps五个需要关注的编码问题

导读	DevSecOps实现的一大关键在于“安全左移”理念。程序的安全不再只是在软件开发完成后进行测试进行，而需要全周期的分析，及时地发现和修复；而达成这个目标的工具之一就是静态分析（SAST）。

在过去的软件开发流程中，安全总是在开发的最终阶段进行——虽然这个时候发现的漏洞其实能在更早的阶段就被修复。如果要在当下复杂的开发环境中进一步加速的同时还能保障软件的安全性，开发者就需要将安全左移，更早地将安全融入开发周期中。

但是安全在开发周期的左移并不容易，开发人员会面对不少困难。以下是五个最常见问题——这些问题都能通过静态分析解决。

内存错误

内存读取错误会因为泄露敏感信息对机密性和完整性带来潜在的威胁，而内存写入错误则因为会改变工作流而对机密性、完整性和可用性都带来影响。比较常见的内存问题有缓冲区溢出、缓冲区不足和释放重利用。这些问题难以检测，甚至存在于一些经过反复测试，被认为是安全的代码里，因此即使是最有经验的程序员也难免会产生这些问题。尽管说一些代码标准被启用，试图减少内存错误，但是显然不那么有效。因此，在开发周期早期，需要深度静态分析、数据流分析、符号执行等方式检测内存错误。

编程错误

这类错误主要由C/C++的错误使用引起，比如未初始化变量、重复释放指针、以及间接在征兆数据和非征兆数据之间进行变化等。编程错误中有一部分会被利用进行攻击，而且即使这些错误会导致程序崩溃，可能也不会在功能测试和回归测试中显现出来。然而，它们确实会在部署的系统中引起严重问题。静态额分析可以识别在编程语义中存在的代码错误和歧义。

有风险的函数调用

有一些API函数被认为是有隐患，不安全的。比如C/C++中的gets()函数，就很容易产生目标地址的缓存溢出问题。其他函数调用也可能因为一些行为产生危害。这类有风险的函数调用很容易就在静态分析中通过风险函数列表的方式被识别。

密码学滥用

密码学在保障数据机密性的环境中尤为重要。但是，几乎没有开发人员在密码学层面是专家；更糟的是，滥用C语言本身库里的密码函数反而会导致安全问题，比如使用像DES和MD5那样的弱算法加密，或者用硬编码的密钥以及将盐数据进行哈希。密码学的滥用会影响机密性和完整性，不过他们也同样能被静态分析轻松识别。

污染数据

污染数据是指数据在进入系统时未被验证并去除有害内容，从而无法保证数据值是在合法范围。污染数据是对开发者最大的挑战之一，同样也会影响机密性和完整性。人工检查很难检测到数据注入问题。

如果要解决污染数据的问题，就需要对以任何形式（比如用户、设备、sockets等等）进入系统的数据都从来源到目标进行追踪。在数据被API调用、接入数据结构、或者进入任何编程逻辑前，都需要被验证。否则，就可能产生数据注入的攻击威胁。静态分析可以在工作流中进行计算，提供简明易懂的告警保住程序员规避这些危险情况。

静态分析检测漏洞

静态分析，或者说静态分析安全测试（SAST），通过检查源程序的代码来检测可能的安全问题——比如啥上述的五个代码问题。由于SAST可以被用于开发者的CI/CD工作流中，它不会减缓敏捷开发进程。实际上，因为它能在开发者编写代码的时候发现漏洞，从而减少发现问题的成本，并在应用上线前——甚至在进行测试前就进行修复，最终加速软件开发速度。因此，SAST对提升代码安全性有着关键的作用，需要成为在DevSecOps的安全左移过程中的一部分。

在安全左移的过程中，代码的即时分析、测试并发现漏洞是一大重点。本文提及了SAST在DevSecOps中能解决的一些代码问题，但是SAST并不是DevSecOps过程中的唯一工具，同样需要结合IAST、软件供应链管理等工具，才能完善DevSecOps工具链，逐渐增加自己的软件开发周期的安全度。

本文来自《Linux就该这么学》官方资讯站。