1.6 案例的启示

从这些案例中得出的最重要的结论是，专注于传统的“最后一英里”防御措施（如散列和代码签名）是远远不够的，而且可能会给人一种虚假的安全感。最成功的攻击发生在这些过程的上游，签署恶意代码可能比根本不签署造成更大的危害。

其次，就像传统的网络防御一样，建立“正常”的基线可以为异常检测创建标准参考。这包括许多软件物料清单工件的生成，以及有关这些工件的元数据，如散列和代码签名。虽然不是明确的（这似乎与上一段相矛盾），但这些仍然是有效的技术，但它们必须在流程的早期执行，并在流程的每一步进行验证和重新验证。

除了这些静态工件之外，了解软件的代码执行流程和网络行为对于识别恶意功能也很有价值。例如，在 SolarWinds 的案例中，是行为变化（不一定是在代码审查中发现的任何东西）揭示了这种妥协。安全软件开发是一个包含多个阶段和许多妥协机会的过程。虽然零信任架构的概念是为身份和资源访问（例如应用程序访问控制）而设计的，但核心原则同样适用于安全软件开发。作为零信任核心原则的提醒，这些原则包括:

■ 用户和身份
■ 设备
■ 网络和环境
■ 应用程序工作负载
■ 软件供应链
■ 数据

安全软件需要在整个生命周期内采用多学科方法。虽然软件物料清单之类的技术是工具带中的一种工具，但它无法阻止诸如 SolarWinds 之类的复杂攻击。没有“一刀切”的安全工具可以解决这些问题，它需要彻底改变我们今天开发软件的方式以及我们在软件开发过程的所有阶段和整个软件供应链中管理信任的方式。交付代码的组织要对他们交付的所有代码负责，而不仅仅是他们编写的代码，这意味着上游输入的验证与他们自己的开发团队制作的软件一样重要，甚至更重要。