到 2025 年，总计 全局数据创建 将达到 181 ZB。 对于企业来说，这些数据是一种资产，使他们能够利用各种技术平台来创建高度个性化的客户体验，从而提高忠诚度并吸引新业务。 然而，这些体验依赖于使用共享安全模式的云基础设施。 这就是风险所在，而且随着技术的发展，使用低代码和无代码平台的新公民开发人员队伍的出现，风险也在不断增加。
理解并克服继承心态
Gartner公司 预计到 2025 年，70% 的企业应用程序将由 Salesforce 和 ServiceNow 等低代码和无代码平台构建。 以基于继承的心态来应对肯定会让超过三分之二的企业应用程序面临失败。
“继承思维”是困扰基础设施问题的一个恰当描述。 它让人想起一个富有的、被宠坏的孩子，他们完全依赖于他们所做的工作和前辈。 这不是建立遗产的好方法，也是建立系统的同样糟糕的方法。
当你有传统思维模式时，你就会认为基础设施已经设置好了。 该平台是安全的，并且安全性是内置的。信任的假设仅仅是因为该技术在管理员之前就已经存在。
这种继承心态困扰着低代码和无代码平台。 用户依靠平台的安全性来承载他们通过整个企业基础设施。 相反，该平台的安全性应仅适用于该平台。
假设 Salesforce 开发人员为新潜在客户创建了一个自动分配程序。 他们在 Salesforce 中使用它进行内部分配，这很好。 他们可以信赖平台的安全性。 他们决定对其进行扩展以提高自动化程度。 他们将该程序连接到面向外部的 CRM（例如 ServiceNow、SAP 或 Oracle）。 继承思维占据上风：Salesforce 是安全的。 ServiceNow、SAP 或第三方都是安全的。
因此，Salesforce + 第三方 = 安全。
但是，这个加号中有很多未知的东西。 如何安全、合规地将Salesforce中创建的内部程序连接到第三方平台中创建的外部程序？ 这个单一的角色有很大的错误空间。
这只是一种联系。 在 Salesforce 中创建的许多程序都会影响数百个其他程序。 这是数百个未知数被几乎没有开发经验的人视为上面描述的加号。
唯一的解决方案是让开发回到现实，回归 DevSecOps 原则。
建立 DevSecOps 框架
开发安全 自从这个概念被创建以来，框架已经被编写、重写、再编写。 建立它们时没有必要重新发明轮子，尤其是当 SAFECode 和云安全联盟 建立了六大支柱：
- 集体责任： 安全是企业中每个人的责任，但人们无法满足他们不知道的标准。 应分配领导者来推动网络安全政策并确保其在整个企业内传播。
- 协作与整合： 知识必须共享和转移。 企业陷入遗留思维的一半原因是所有了解旧系统的人都消失了。 持续的知识共享有助于消除这个问题。
- 务实执行： 务实的实施与开发人员的体验息息相关。 困难、平凡和笨拙的流程不会被长期遵循。 安全性应该融入到开发实践中——也就是说，每一行代码都需要一行测试。 高性能企业会更进一步，使用工具来自动化每行测试代码。
- 合规与发展： 合规性要求应该以不允许开发人员偏离它们的方式指导开发过程。 例如，金融机构的开发人员将在一个旨在符合 Gramm-Leach-Bliley 法案的平台上工作。 开发人员不必了解该行为的各个来龙去脉即可合规，因为它们已内置于平台中。
- 自动化： 可预测、可重复和大批量的任务应尽可能实现自动化，以减轻开发人员的负担并降低人为错误的风险。
- 监控： 现代云基础设施不断变化和发展。 跟踪它至关重要——理想情况下，通过某种形式的编排，可以一目了然地查看所有各种互连。
在一个 低代码或无代码 环境方面，这些支柱并不像人们想象的那么简单。 使用这些工具的人通常是业务专家，对 DevSecOps 基础知识不太熟悉。
将人员、流程和技术结合在一起
使用低代码和无代码平台实际上可以帮助缩小这种技能差距。 员工希望学习新技能。 企业可以通过建立专注于人员、流程和技术的 DevSecOps 框架来支持这一点。
- 流程： 在零信任环境中，低代码和无代码开发人员不必担心建立危及系统完整性的连接，因为他们没有能力这样做。 他们在孤立的系统之外没有基线权威。
- 人物： 问责文化与指责文化不同。 问责制意味着个人可以轻松地提出问题或错误，因为重点是问题而不是人。
- 技术： 技术是正确实施 DevSecOps 原则的最大障碍，因为它不在开发人员的掌控之中。 他们必须使用组织提供给他们的东西。 如果该技术不起作用，开发人员将想出既不安全也不安全的解决方法。 从本质上讲，这项技术成为了一个巨大的影子 IT 发生器。
我们生活在一个激动人心的发展时代。 越来越多的人有机会构建软件、测试策略和提高业务价值。 但随之而来的是风险。 寻求将风险转移到技术上的企业将脚踏实地地发展，同时留出探索的空间。
