双管齐下：如何正确选择SAST和SCA？
现代应用程序越来越庞大和复杂，安全工具的复杂性也水涨船高。
开发人员和安全专家通常依靠两类关键工具来保护应用程序和数据安全。一个是静态应用程序安全测试（SAST），第二个是软件成分分析（SCA）。这两种工具有不同的目标——SAST用于测试内部开发的代码，SCA用于管理导入的开源组件。
理想情况下，开发者会同时使用这两种方法，以覆盖这两个领域可能存在的安全漏洞，但现实往往很骨感，很多企业直到最近才开始意识到双管齐下的必要性，但在行动之前，我们首先要懂得如何选择SAST和SCA产品。
SAST是一种行之有效的安全方法，市场上有数十种工具可供选择。国际市场上比较主流的SAST工具如下：
- CyberRes Fortify
- CheckMarx SAST
- Perforce Klocwork SAST
- Spectral SpectralOps Platform
- Veracode Static Analysis SAST
SAST扫描应用程序源代码或字节码以查找已知的软件漏洞——这些漏洞可能允许攻击者获得访问权限。SAST工具会自动覆盖应用程序可能存在的所有可能路径和事件，并且可以发现开发人员甚至没有意识到的漏洞。
我们也必须清醒地认识到，SAST工具确实存在一些缺点。SAST以速度慢、产生误报和难以使用而闻名。最终，开发者将不得不在运行测试所需的时间、测试的详尽程度以及被认为可以接受的误报数量之间做出妥协。当然，这些妥协中没有一个是可取的，但根据过去的经验，应用程序开发人员必须至少选择一个。
不可忽视的依赖关系
SCA的作用在于帮助降低源代码之外的风险。最近的Log4Shell漏洞凸显了攻击第三方和开源软件包的潜在破坏力，如今大量第三方和开源软件包被用作自主开发应用程序的底层构建模块。
现代软件可能依赖于数百个开源包，我们称之为依赖项。而且，这些依赖项还可能依赖于开发人员甚至可能不知道的其他开源包，称为传递依赖项。开源包可用于完成数千种操作和任务，这省去了开发人员自己编写代码的麻烦，毕竟重新发明轮子是没有意义的。因此，如今98%的应用程序包含开源软件也就不足为奇了，根据云原生计算基金会（CNCF）的报告，当今应用程序中超过75%的代码都是开源代码。
前不久npm开源包曝出的一系列维护者“删库跑路”，甚至出于个人原因（嫌报酬太低）或意识形态原因（俄乌战争）在代码中“投毒”的事件表明，开源包的安全性非常难以预测，其安全漏洞测试的严格程度也千差万别，尤其是许多不再积极维护的包。此外，许多开源软件包有多种变体，旧版本仍在活跃流通中。
SCA测试专门研究这个领域，扫描应用程序的依赖项和传递依赖项，并将其与漏洞数据库相关联，以了解从组织外部获取的代码中继承了哪些风险和安全漏洞。理想情况下，它将识别已知漏洞的类型和严重性，并就修复和变通方法提供建议。SCA还通过识别软件包中包含的许可证以及可能产生的任何责任或义务来帮助企业规避其法律风险。
SAST和SCA在软件开发生命周期中都扮演着重要的角色。通过将两者结合起来，开发人员可以全面了解其应用程序的安全性：SAST用于测试源代码以发现安全漏洞；SCA作为管理开源组件的应用程序安全方法。
不幸的是，许多SCA工具，就像SAST工具一样，以难以集成和产生大量误报而闻名，导致采用率仍然很低，报告显示只有38%的组织实施了开源安全控制。因此，过去开发社区对同时执行这两种安全测试方法并不热心，因为这可能意味着付出双倍的时间，得到双倍的误报。但现代开发安全技术的新工具克服了这些缺点，使得同时兼顾安全性和性能的安全开发测试方法成为可能。
选择SAST和SCA要注意什么
在完全接受CI/CD和devops方法的现代软件开发管道中，花一天时间进行安全测试，然后再等待几天来修复漏洞是行不通的。因为开发团队每天可能会进行数百次代码更改。为了便于管理，他们需要能够在编写代码时自己进行安全检查，并通过工具授权，这意味着他们不需要把自己一夜之间变成安全领域的专家。
在这种形势下，SAST和SCA工具首先要对开发人员友好，去主动适应开发人员使用的工作流程和工具，而不是强迫开发人员来适应安全工具。DevSecOps工作流程意味着开发人员需要尽最大努力确保代码在编写时是安全的，而不是将安全作为一个单独的后续步骤，这会造成延迟并导致代码在开发和安全团队之间不断地来回传递。
其次，在当今的软件环境中，这两组工具虽然功能不同，但是有一个共同目标，那就是让开发人员成为软件安全的领导者。因此，将这两种工具以某种方式合并、同时运行或在同一工具中提供，可以减少步骤环节、减少学习曲线和复杂性，具有极高的价值。
最后，优秀的测试工具需要基于云并优化代码，以免给开发人员造成延迟。安全工具还要能跟上现代软件开发的敏捷步伐。敏捷已经颠覆了传统的软件工程模式，但是软件的安全性需求不但没有削弱，反而更加紧迫和重要。根据Gartner的2021-2023企业新兴科技路线图，2022年SAST已经进入了部署完成期，而且实施风险较低。这意味SAST已经日趋成熟，而没有“上车”的开发团队需要尽快开始考虑选择适合自己的工具了。
