编译：代码卫士
我们似乎每天都会遇到新的网络威胁，而且它们的影响越来越大。现在，我们需要例行处理0day漏洞和混合攻击，而当遇到Log4Shell 等安全事件时，我们依靠的是一群志愿者来保护深深嵌入关键系统中的代码。
这些事件促使安全团队不得不重新思考自己如何应对，以及关注深嵌软件开发安全中的除“打补丁并祈祷 (patch and pray)”以外的主动方法。为此，安全团队应当思考2022年的如下关键软件开发安全趋势以及“最佳实践”响应。
1、不断增长的软件供应链攻击面
多数软件供应链威胁的媒体报道关注的都是开源包管理器、第三方程序包和少数常见系统如 Microsoft Exchange 和 SolarWinds 网络管理工具。我们还看到攻击数量和攻击宽度都在增长，针对的是供应链中每个不引人注意的角落。
程序包管理器是明显的入口点。但还存在很多其它入口点，始于开发环境，接着合并队列系统、插件/附件乃至代码仓库、持续集成/持续交付系统、应用安全工具和软件发布分发工具。所有这些因素的叠加导致开发进程中留下数十个甚至是数百个潜在的入口点，而随着更多自动化团队使用的工具和解决方案数量的增多，这一数字还在增加。因此随着攻击面的不断扩展，未来会看到更多新的供应链威胁。
最佳实践：每个公司应当创建软件供应链清单，补货每个潜在的插入点并采用编程方式解决整个供应链带来的风险。
2、SBOM 成为主流的元年
从概念上来看，软件物料清单 (SBOM) 已存在数年时间。SBOM 的基本理念很简单：每款软件应用程序都应具有“物料清单”，列出某应用程序的所有组件。它对应于物理世界中所有电子产品的物料清单。
两家著名组织机构 Linux 基金会和 OWASP 都拥有SBOM技术，它们分别持有SPDX和Cyclone 技术。然而，对这两种SBOM标准的采用进度缓慢。美国联邦政府正在督促行业加强对供应链的保护，其中包括要求对政府机构使用的软件提供SBOM。
最佳实践：还未使用SBOM的企业应当考虑将采用SBOM标准作为试点项目。这将使组织机构具有使用一种或两种标准的经验，并将SBOM作为软件发布和应用安全实践的门槛因素。
3、零信任嵌入软件工程
我们听到的零信任多数是在验证用户/请求/交易和持续进行身份验证的上下文中。然而，将零信任应用到软件供应链更左处、开发过程中和DevOps 周期中的说法不常听到。实际上，零信任并非时候想法。
攻击者攻击供应链时，几乎总是依靠系统中的信任，如程序包、版本控制系统或仅基于虚拟操作和注释的开发者身份等。因此，安全团队应当开始考虑在开发流程深处实现零信任策略和系统，更好地保护应用程序源代码的安全。
最佳实践：确保软件开发供应链中的每个链至少都使用双因素验证机制。之后探索如何增加其它因素以建立持续性验证。
结论
网络安全一直都是关于趋势识别和响应以及预测和准备好应对熟悉的和未知的攻击。2022年，安全团队应当专注于保护软件供应链安全，同时执行SBOM和零信任。如此，组织机构将领先于而非落后于重大发展趋势。
原文链接
https://www.darkreading.com/vulnerabilities-threats/3-critical-software-development-security-trends-and-best-practices
声明：本文来自代码卫士，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
