采取主动安全计划 加强应用程序安全性

应对应用程序安全问题不仅是在漏洞被利用后采取的响应措施，更重要的是，有专门负责安全的决策者或团队积极协调内部有关人员贯彻预防性、主动的安全计划。

首席信息安全官（CISO）在软件安全方面发挥着关键作用。每家企业都需要一位有权对数据和软件组合进行治理的人员，并且他有明确的执行计划，这样有助于针对企业风险进行探讨。

IT和软件工程企业可能需要创建基础架构、设置访问控制、创建自定义应用程序以及配置环境以抵御攻击和保护数据。但是他们要怎么确定 “安全”意味着什么？如何做到安全？以及他们是否在实现安全？这些都是未知数。 “如何保障安全”的标杆必须来自代表业务的人，CISO是一个很好的选择。找到合适的人并为了他们的成功创造条件是提高软件安全能力水平的第一步。

请注意，我在这里用的是“软件”而不是“应用程序”。

当企业专注于“应用程序”时，他们往往会忘记所有框架、库、API、微服务、开源和其它软件组件。这些组件可能不止存在于最终包含它们的应用程序里。有时同一款软件，企业得担心数十次甚至数百次，因为，例如，相同的框架嵌入在许多应用程序中。此外，仅在应用程序级别考虑软件出处通常会模糊所有组件的来源 - 开源、定制软件以及其它所有组件。如果你不知道自己拥有什么，就无法做出有效的风险管理决策。

了解生产软件的所有组件，包括在构建时引入的组件，是软件安全能力的基础部分。除了资源充足的CISO和出色的软件库存之外，还有一些可信的软件安全功能的基础部分：

•   验证企业软件开发生命周期(SDLC)中安全依从性的方法。这不仅仅是对安全缺陷的测试，还必须包括遵守所有标准和策略；

•  说到这一点，企业将需要面向软件和数据安全的策略和标准。这些必须是不可协商的，其中不遵守策略和标准自动会被认定是安全问题，尽管异常过程可能允许安全小组有一些额外的时间来解决；

•  给软件安全风险排名，可以在时间、人力或者资金有限的时候确定重点应放在哪里？

•   对软件项目进行排名（改变加密算法的开发最小迭代周期可能比改变UI字体和颜色的开发最小迭代周期更值得仔细研究）

• 工程师需要一个明确的联系人来解决安全问题，并让他们了解安全责任。无论你将这些人称为软件安全卫星、忍者、安全冠军还是其他，他们都需要存在。

许多企业都有正式的软件安全计划（SSI），这些计划已经将他们从“渗透和修补”的心态转变为积极主动和可信的方法。在CI / CD和DevOps之前提高软件安全能力水平不会在一天内发生，但并不复杂。

SSI自21世纪初就已经出现了，与部署SSI的开发企业同步发展。软件安全团队经常实施耗时的测试，而工程团队瀑布式和敏捷级别流程大多数情况下都有足够的时间可以实现这些测试。这两个团队通常协调得很顺畅，每个团队都能充分发挥自己的工作，即使效率不高。软件安全能力通常关注测试过程可以找到多少错误。这对于那些执行治理和降低风险的人员来说是有效的，但却给工程人员带来了不可接受的摩擦，他们需要注重速度。

为什么摩擦像是一夜之间发生了变化？

自2014年左右开始，软件工程开始迅速发展。当然，敏捷、CI / CD和DevOps概念已存在多年，但它们最近才在许多企业里获得青睐。在CI / CD和DevOps后（可能伴随着仓促地对云迁移和云原生的开发），提高企业软件安全能力并不意味着使用传统的安全测试工具和新的工程流程。相反，它意味着与工程紧密结合，以提供节奏友好的CI / CD工具和文化友好的DevOps流程；这意味着多年来我们所讲、所学的SSI的“安全”，并使其适合CI / CD和DevOps，以创建企业自己的DevSecOps版本。（如果也有人告诉你DevSecOps意味着特定的事情以特定的方式完成，不要相信。他们试图向你推销一些东西。）卓越的DevSecOps确实提高了任何企业的软件安全能力水平。

当然，SSI仍需要坚实的基础。还记得我们之前谈过的软件库存吗？那么，当编排被提出，并拆除基于基础架构即代码自动化的容器和虚拟机时，你的库存流程是否仍然有效？如何在SDLC中检测是否正确使用了所需的框架和API？

对我们已知有了缺陷的软件进行渗透测试是没有意义的，因为它的设计或构建很差，可以在软件开发的早期检测和解决。事实上，在发布之前进行安全测试需要随着时间的推移而降低价值。每个企业都必须能够设置软件安全标准，并在不遵循时该标准时能够立即提示确认。