专家们介绍了软件开发团队如何可以“将安全左移”（即在开发的早期阶段就注重安全），并改善使用开源组件、管理代码、部署服务和处理数据等方面的治理工作。


首席信息官及其IT部门面临来自业务部门的巨大压力，需要更新改造应用程序、改善客户体验、将应用程序迁移到云端，以及实现工作流程自动化。敏捷开发和开发运维（DevOps）包括相应的文化、实践、工具和自动化，它们使软件开发团队能够实现这些目标，并交付业务价值，拥有更高的质量和更快的发布周期。


最先进的开发团队采用完全自动化的持续集成和持续交付（CI/CD）管道，拥有集成的测试自动化功能，并以基础架构即代码这种方式进行部署。它们将变更管理和事件管理工作流程与敏捷开发工具联系在一起，并使用人工智能运维（AIops）平台更快速地找到生产环境中实际问题的根本原因。


然而，软件开发中的安全问题依然存在。行业分析公司ESG的《现代应用程序开发安全》报告显示，只有36%的受访者将其应用程序安全项目评为9分或10分，而66%的受访者表示应用程序安全工具保护的代码库不到75%，48%的受访者承认经常将易受攻击的代码推送到生产环境。


存在这些安全缺陷，倒不是由于缺乏技术、咨询或安全服务提供商。《2020年网络安全年鉴》列有3500多个潜在的安全合作伙伴。最终，要在尽量减少软件开发中安全风险的同时提供业务价值，关键在于明确定义安全原则，并将这些原则告知软件开发团队。


以下是首席信息官和IT负责人应关注的软件开发的六大风险以及应对方法。



第一大风险：没有将安全视为开发运维的一等公民


企业组织将安全放在首位，许多组织也的确遵循敏捷和开发运维中的最佳安全实践。但是与开发团队的人数相比，信息安全团队常常人手不足，不难看出业务和技术债务方面的其他优先事项占了敏捷团队待完成工作的大部分，以及为什么整个组织没有统一采用安全实践。


ESG的研究报告支持这一结论。虽然78%的受访者表示他们的安全分析员直接与开发人员互动，但只有31%的受访者逐个审查功能和代码。这个差距相当大，大多数企业组织不太可能聘请足够多的安全专家，并将他们长期分配给敏捷开发团队。但是许多企业组织可以做下列这些事：


·要求对整个软件开发团队进行持续的安全培训和教育。


·要求信息安全团队在Atlassian Confluence或Microsoft Teams等工具中记载安全验收标准，并要求敏捷团队在用户故事中提到这些标准。


·规范敏捷规划和发布管理方面的协作，以便信息安全团队可以在开发过程的早期标记高风险功能和用户故事。


·记录并发布迭代开发周期（sprint）评审结果，以便信息安全团队可以看到更多的评审结果，并标记有风险的实施。


·要求所有新开发的API、微服务、集成机制和应用程序在CI/CD管道中落实所需的安全测试。


定义原则、确保跨团队协作、改善文化和增进团队幸福感，这些可能是首席信息官有助于改善软件安全的几种最重要的方法。2020年的《开发安全运维（DevSecOps）社区调查》发现，心情舒畅的开发人员关注安全的可能性高出3.6倍。



第二大风险：开发专有的技术实施方法


软件开发团队酷爱编写和开发解决方案，企业组织需要他们的才能、创新和技术本领，以应对紧迫的业务挑战。但有时候，实际需求也会让开发团队陷入不断解决棘手的技术挑战和实施方法中，而这些原本是可以从第三方获得的。


低代码和无代码有时可能意味著更安全的解决方案，这至少有两个原因：首先，敏捷产品的所有者并不总是了解其主要功能的安全隐患。其次，许多人在未规定解决方案要素的情况下试图明确表达需求，这有时会导致团队实施的代码密集型解决方案带来安全风险。


敏捷开发团队应从向产品所有者询问功能优先事项方面的问题入手，并商议范围和需求。避免受到质疑的一种做法是，严格按照规范编写用户故事，并进行评估，以便复杂情况能在编程开始之前暴露出来。


一旦团队就优先事项和功能范围达成一致，开发团队应考虑实施时具体在哪些地方利用第三方技术。审核对象应包括低代码/无代码平台、开源代码库、商业框架、公共云服务和软件即服务工具。


当然，天下没有免费的午餐。使用第三方解决方案也会带来风险。


第三大风险：开源和商业组件的治理和管理不善


你是否听说过开发运维团队为何最有能力挑选自己的工具？这是高级开发运维团队经常提及的一个观念，我也听说过好几本倡导这个原则的著名的开发运维书籍。


然而，许多首席信息官、IT负责人和首席信息安全官警告不要让开发运维团队全权决定工具和组件方面的选择。与此同时，大多数负责人也承认，过多的限制和复杂的审批流程会阻碍创新，并让才华横溢的开发人员颇为沮丧。首席信息官、IT负责人和首席信息安全官必须围绕技术选择、升级和补丁，确定条理清晰、易于遵守的规则和明智的治理。


最近的调查结果表明了风险。有公司对1500名IT专业人员就开发安全运维和开源代码管理进行了调查，结果发现，只有72%的企业声称拥有开源代码使用方面的政策，只有64%的企业声称设有开源治理委员会。而这只是问题的冰山一角，因为只有16%的受访者认为，一旦发现某个高危的开源漏洞，自己有能力修复漏洞。


考虑到与开源组件有关的泄密事件数量众多，上述结果令人担忧。在2020年的《开发安全运维社区调查》中，21%的受访者承认遇到过与开源组件有关的泄密事件。这不仅仅是开源问题，因为任何商业系统也可能存在API安全漏洞或其他软件组件漏洞。


要缓解风险，就需要在开源代码的使用、工具选择和技术生命周期等方面制定明确定义的政策、治理和管理实践。但是企业组织在最佳实践上有所不同。有些企业依赖更开放的程序，而另一些企业则依赖更低的风险容忍度和更严格的程序。为了在安全与创新之间达成两者兼顾的政策，首席信息官应成立一个跨部门团队，以确定治理程序、实践标准、工具和度量指标。


拥有将开发者功能与安全最佳实践相集成的工具，可以缓解选择开源组件的一些挑战。Quick Base公司的首席产品和技术官Jay Jamison介绍了该公司在用开源进行创新这方面的做法：


“我们很早就采用了GitHub Advanced Security，有了该产品，可比较容易地揪出GitHub平台上管理的开源项目中的漏洞。这是让安全更早地进入软件开发生命周期（或用开发人员的术语来说就是左移）的重要一步。”


第四大风险：不受制约地访问源代码存储库和CI/CD管道


如何确保内部软件的安全？之前的方法是：严加保护版本控制存储库、扫描代码以查找漏洞、定义最小权限以便于部署、加密连接以及执行渗透测试。严加保护网络和基础架构是个全然不同的安全领域，牵涉IT运维部门管理的单独工具和准则。


如今有了更多的风险和更多的工具，但也有了更好的集成机制。我与Cherwell工程副总裁Josh Mason谈过Cherwell确保代码安全的做法。他说：“我们Cherwell添加了自动静态分析安全测试（SAST）、动态应用程序安全测试以及人工完成的渗透测试，这往往可以共同提高生产力。将SAST作为CI/CD管道的一部分来实施，使漏洞发现过程在软件开发生命周期中进一步左移，因而可以更快速、更省钱地解决问题。”


Mason还建议严加保管版本控制存储库。“遵循零信任模型和最小特权原则的指导是一种良好的做法，限制了对源代码控制存储库及其功能的访问。源代码控制存储库解决方案（比如Azure DevOps、GitHub和Bitbucket等）提供了细粒度的用户权限，从而将开发人员（或整个开发团队）限制在与他们的工作有关的一小部分代码库。”


戴尔科技旗下Boomi的工程主管Rajesh Raheja建议遵循几个安全准则，开发团队应肩负起责任。“如果软件开发不当，与单个系统遭到攻击相比，大规模环境下的安全风险会大幅放大。要想缓解风险，就必须确保CI/CD管道安全，以最小特权原则严加保护系统，借助多因子身份验证为自动化实施安全变通方法，提高团队成员的安全意识，并制定安全编程实践。”



第五大风险：保护和管理敏感数据


虽然许多开发运维团队精通开发、测试和部署应用程序方面的安全实践，但他们还必须添加数据管理和数据运维方面的安全实践。


DataKitchen首席执行官Chris Bergh解释了该问题以及更多的数据运维安全实现自动化的方法。“数据隐私和安全方面的挑战阻止公司利用其数据获得竞争优势。手动流程无法解决这个问题——太多的数据太快速地流入，来不及处理。数据安全运维（Datasecops）是一套使数据隐私和安全实现自动化的方法，它将隐私、安全和治理集成到与数据分析开发、部署和运维一起执行的自动化工作流程中。”


首席信息官和IT负责人在数据运维方面遇到的主要挑战是，采用主动的数据治理、标记敏感数据，以及对开发人员和数据科学家进行可接受的数据實践方面的教育。集中身份管理、定义基于角色的授权以及掩藏开发环境中的敏感数据，这些是确保数据安全和数据隐私的重要做法。


管理敏感数据超出了数据安全的范畴。比如说，许多公司（尤其是受监管行业的那些公司）必须记录数据沿袭（data lineage），表明谁变更了数据、何时更改、在何处更改以及如何更改。这些公司常常使用拥有内置数据沿袭功能的数据集成和数据管理平台。


第六大风险：DIY安全专业知识和解决方案


我管理风险和安全的方法向来是听取不同专家的建议。安全威胁的程度和复杂性在与日俱增，大多数企业组织不太可能拥有所有必需的专业知识。此外，真出现安全问题时，可以向一群人讨教如何降低风险、解决问题、收集取证分析结果以及堵住漏洞，对于尽量减小影响至关重要。


虽然诸多工具和实践帮助首席信息官解决当下的问题，但我们仍需要专家来应对下一批安全挑战。