当新冠疫情发生时，很多公司不得不迅速改变他们的业务模式。事实上，许多人开始忽略了某些安全方面的问题，而这些问题是为拥有快速开发周期和为客户提供新功能所做的权衡。现在是时候回过头来重新审视安全政策和准则，以及如何最好地将它们整合到敏捷开发过程中。
当今许多组织面临的最大挑战是安全团队几乎总是与工程和运营组织分开。随着新兴的云和云原生技术的出现，安全团队需要集中管理、监控和处理工程团队的工作流。
为了在工程组织内建立安全思维，安全团队必须为工程团队提供适合其工作流程的工具。如果安全团队的解决方案只是将包装代码放在安全团队要求的工具之上，那么它将成为一种附加的管理技术，可能会减慢进度。
将安全融入敏捷和 DevOps 的工作方式中
很多人认为当安全被纳入流程时速度会降低，但这是一种误解。如果安全策略和闸门未集成或自动化到软件交付系统中，则上市时间通常会延迟。即使有一个集中的安全团队，让他们成为敏捷开发流程和整个 DevOps 转型之旅的一部分，也将帮助所有团队更快、更有效地解决出现的安全问题。
DevOps在很大程度上被象征为一个无限的连续反馈回路的概念。如果我们把安全实践放在这个无限的符号之上，安全策略就会从头到尾被整合起来--计划、构建、配置、测试、分析和监控。这描述了一组可以分配给不同应用程序团队的共同目标，并使他们能够对某些安全策略拥有所有权，而不是一个拥有安全策略责任和任务的集中团队。
以下是一些需要考虑的步骤和做法：
●首先，工程和运营团队需要预测威胁，不仅在应用程序层面，而且在基础设施层面。对出现的问题做出反应是很麻烦的，团队需要积极应对这种情况。这是人们现在正在创造的一种心态，而这种心态在新冠疫情刚刚发生时并不一定存在。
●集中式或联合式的安全模式是实用的，但不能在第一天就实施。在这种组织范围内的模式建立之前，它必须经历逐步的转变，以了解软件交付管理的整体观点。就像敏捷一样，它是一个框架，需要随着时间的推移进行审查和改进。
●构建一种通用方法，包括定义静态代码分析、动态代码分析和代码漏洞监控方面所需的关键安全策略。这些政策可以从平台的角度为应用团队实现自动化和协调化。这使得安全领导更容易从这些不同的团队中获得可见性和洞察力。它还创建了关于存在哪些差距以及如何改进的必要反馈循环。
●提供 API 集成作为平台方法的一部分——将代码从开发环境推送到生产环境，将有助于简化工程团队的工作流程，无需担心每个阶段添加的安全技术，因为它已经融入系统。无代码或低代码平台可以更轻松地插入安全工具并运行它。
●无论您是否授权工程和运营团队选择工具，一种新兴的做法是利用可扩展的、无代码的集成编排平台来补充工程和运营流程。这将使安全实践得以遵循，并且可以按照他们交付软件的速度进行管理和维护。
●研究每个应用程序的情况，包括使用的技术，以及消费者如何使用该解决方案。这为所有的应用程序创建了一个基线，而不考虑技术、云基础设施、平台等。这将有助于从安全威胁的角度根除误报，并为后续步骤提供更清晰的画面。如果误报始终是强制性的安全补救措施(即使它可能不是实际威胁)，软件交付的速度就会受到影响。
例如，使用 Spring Boot 微服务和 Node.js。在 Spring Boot 微服务中，你可能会有很多误报，作为一个高度警惕的关键漏洞。实际上，这些并不是阻止代码部署到生产的关键漏洞。这种考虑必须循环到安全策略中，以了解它的需求、授予异常并管理未来的安全异常。这提供了管理异常的基线，以允许代码首先投入生产。如果安全团队因为此类误报而继续停止流程，并且不了解应用程序环境和业务需求，那么安全性可能会成为执行团队和整个企业的麻烦事。
预料到陷阱，并避免它
最常见的陷阱是安全团队对应用环境没有足够的了解，以及在公司的产品组合和平台环境方面如何对业务下游产生影响。安全团队需要在所有这四种情况下接受培训，以了解需要实施哪些政策和准则。
从软件工程的角度来看，人们总是在推动更高的速度。但是，对安全框架的战略思考并不总是这种思维方式的一部分。
集中式的安全团队经常推动为每一段被推送到生产中的代码制定政策。但安全团队可能不提供API集成，例如，使这个过程更容易。仅仅实施安全策略是没有任何好处的。
最终，目标是在集中式安全团队和软件工程团队之间建立伙伴关系，以实现DevOps转型之旅的承诺。为了确保开发和部署的独特代码是安全的，需要一个渐进的学习过程，以及对应用团队和软件交付系统的需求有更多的了解。只有这样才能在此基础上建立一个安全框架。这种方法和思维的演变将使我们在未来更容易适应新出现的威胁，并在这个不确定的时代提供企业所需的可见性和控制力。
