选用 CNAS 须要对她们保护插件和虚拟化的形式展开重大发生改变。变革是一个旅途，每个组织机构都不相同，甚至同一个组织机构的相同部分也相同。
虽然优先选择恰当的道路是由你的决定，但为的是让它恰当，模式和最差实践早已开始出现。在责任编辑中，我提出了几个能考虑冲破现况的应用领域，和怎样冲破现况。
再次思索辅助工具
除了组织机构构架的发生改变，CNAS 和 ” 合作开发优先优先选择 ” 还须要再次评估结果你的辅助软件包。有鉴于这种科枫，你假如再次考虑在技术软件系统中找寻的最重要特点，和你希望怎样绑定辅助工具。
有很多形式能再次评估结果辅助工具，但我建议关注三个主要应用领域：合作开发辅助工具选用、网络平台范围和环境治理形式。
合作开发相关人员辅助工具舰炮
假如她们的最终目标是让合作开发相关人员在日常生活工作中能够构筑可靠性，她们须要保证为她们提供针对该最终目标展开强化的辅助工具。假如你购买专为审计工作相关人员设计的软件系统并要求合作开发相关人员采用它，那么你不大可能取得获得成功。
Rewa，合作开发相关人员惯于采用合作开发相关人员惯常的辅助工具。那些辅助工具代表了整个金融行业，紧紧围绕着什么是杰出的合作开发相关人员辅助工具这一主轴，早已在金融行业内发展了自己的最差课堂教学。为的是帮助你优先选择合作开发相关人员将选用的安全软件系统，你假如根据合作开发相关人员辅助工具最差课堂教学评估结果那些辅助工具，并了解它的表现如何。
以下是杰出的合作开发相关人员辅助工具的一些常用特点：
获得成功的自助式服务项目选用
实际上，所有获得成功的合作开发辅助工具都具备出众的自助式服务项目用语，包括随心所欲的上手专业培训、简单的组织工作业务流程和出众的文件格式。这是合作开发相关人员喜欢采用辅助工具的形式，它逼使供应商保证她们的辅助工具与合作开发相关人员相关，而无须产品销售相关人员推动它。假如你想成为向合作开发相关人员推展辅助工具的产品销售相关人员，否则请找寻具备合作开发相关人员自助式服务项目选用的良好历史记录的辅助工具。
点对点软件系统到组织工作业务流程中
在绝大多数情况下，合作开发辅助工具经常与合作开发相关人员打交道，而不是要求她们再打开另一个辅助工具。它优雅地软件系统到其 IDE、Git 和研发管道中，并在恰当的时间点提供价值。软件系统不仅仅是技术钩子 ; 她们须要适应环境组织工作业务流程和最差课堂教学，否则将被拒绝选用。
丰富的 API 和自动化友好
虽然须要固执己见的软件系统才能开始，但合作开发辅助工具也必须是瑞士军刀。丰富的 API 和自动化友好的客户端（CLI/ 软件合作开发辅助软件包 [ SDK ] ）是强制性的，既能将该辅助工具调整到每个管道，又允许社区在其上展开构筑。假如你不能在辅助工具上构筑，它就不是一个伟大的合作开发辅助工具。
开源和社区选用
合作开发相关人员希望其他合作开发相关人员来验证辅助工具的可信度，而开源选用是最好的指标。看到开源项目软件系统了安全辅助工具或基于此构筑的开源项目，那些都是很好的合作开发相关人员社区验证。在检查安全辅助工具时，检查它在开源中的选用情况并得出自己的结论。
那些只是众多合作开发辅助工具最差课堂教学中的一小部分。假如你想了解更多关于合作开发优先优先选择可靠性的特定安全建议，请继续往下看。此外，在评估结果任何辅助工具时，请保证让实际的插件合作开发相关人员参与进来，以便从现实生活中了解它与周围环境的契合程度（如下图所示）。
合作开发相关人员友好的安全辅助工具示例
网络平台范围
当前主流的 AST 网络平台主要关注自定义代码，也许还有应用采用的开源库。辅助工具套件主要由 SAST、DAST 和 IAST 组成，最近又添加了 SCA。当你拥抱更广泛的云原生植物插件范围时，请再次考虑网络平台的构成。
首先，让她们考虑一下哪些辅助工具从成为单一网络平台的一部分中受益。它能分为下面几个部分：
共享用户：假如相同的辅助工具是为相同的主要用户设计的，那么它几乎不须要成为单个网络平台的一部分，因为它们无论怎样都会单独采用。
共享组织工作流：假如以类似的形式采用多个辅助工具并软件系统到用户组织工作流的类似点中，则能通过组合它来节省软件系统时间和用户的时间和精力，而无须采用多个单独的辅助工具。
共享优先优先选择级：假如来自相同工具的行动项应彼此优先优先选择排序，则共享积压组织工作能提高效率和结果。
价值倍增：最后，辅助工具共享网络平台的最强驱动力是当辅助工具一起采用能增强每个辅助工具的价值。这个标准自然解释了为什么像 SAST 和 SCA 这样的技术非常适合单一网络平台。两者都为相同的合作开发相关人员用户提供服务项目，运行扫描并在相同的位置吸引用户，并共享同一个合作开发相关人员须要优先优先选择考虑的安全漏洞的积压。在高级 SCA 软件系统中，SAST 技术能指示你的自定义代码是否调用库中易受攻击的代码，从而提供更高的准确性，从而增加价值。
当你考虑将容器和 IaC 可靠性添加到 SAST 和 SCA 的同一个网络平台时，相同的逻辑也适用：
共享用户：容器和 IaC 现在由合作开发相关人员保护，就像 SAST 和 SCA 一样，她们宁愿没有多个相同的产品须要花时间学习和参与。
共享组织工作流：保护容器和 IaC 须要跨生命周期的软件系统，例如 IDE、Git 和构筑软件系统，就像 SAST 和 SCA 一样。
共享优先优先选择级：同一个个合作开发相关人员须要花费周期来修复容器或 IaC 漏洞，或者代码或库中的漏洞 —— 所有那些都是保护应用的积压组织工作。
价值倍增：保护那些组件有多种形式。扫描容器须要探索内部的插件，了解基础设施配置有助于确定代码和库的漏洞优先优先选择级，了解跨组件的业务流程有助于缓解问题；这正是你在对漏洞展开分类时所做的。
即使 CNAS 范围扩大，这种逻辑仍然有效，我鼓励你将 CNAS 辅助工具视为一个网络平台。一个简单的准则是，Git 存储库中的任何内容都可能与其周围的文件相关，并遵循相同的合作开发组织工作流。因此，CNAS 网络平台应有助于保护存储库中的所有内容（整个云原生植物应用）。
DAST 和 IAST 在这样一个网络平台上是有点尴尬的参与者。尽管它处理保护插件，但它通常须要相同的组织工作业务流程。由于运行它所花费的时间，很难将它放入构筑管道或 IDE 扫描中。在我看来，这是一个技术问题，而不是一个合乎逻辑的问题，一旦 IAST 和 DAST 解决方案发展到对管道更加友好，它有望得到解决。
环境治理和赋权形式
选用合作开发优先优先选择的安全形式须要相同类型的协作。她们须要的辅助工具不是专注于广播和执行自上而下的任务，而是帮助她们协作构筑安全插件的辅助工具。
这听起来可能很明显，但在课堂教学中，这与许多安全辅助工具的组织工作形式有很大的相同。让她们深入研究一些具体的例子，以了解这意味着什么。
首先，合作开发相关人员须要有能力平衡业务需求与安全风险。这意味着，例如，允许她们决定不修复发现的漏洞并继续将其部署到生产环境。对某些人来说，这是一个可怕的命题，但这是实现独立团队的唯一形式。请注意，忽略漏洞仍应要求提供（且可审核）原因，并且某些约束应为硬杠杠（通常出于合规性原因），但作为默认立场，决策应留给合作开发相关人员。
其次，合作开发相关人员须要能够管理她们的安全风险，这须要看到她们项目中的所有漏洞。这不仅须要包括漏洞列表，还须要包括确定优先优先选择级所需的所有信息，例如可利用性和资产映射。对此类信息保持透明可能会带来一些风险，但这是扩展可靠性的唯一形式；要赋予合作开发相关人员权力，你必须信任她们提供那些敏感数据。
第三，安全团队假如投资于跟踪和推动安全控制的选用，甚至超过她们的产出。合作开发团队假如管理其漏洞积压组织工作，但安全团队须要帮助她们获得成功做到这一点。合作开发优先优先选择安全环境治理意味着跟踪选用了哪些控件及其输出的处理情况，并与合作开发团队合作改进那些统计信息，而不是突出显示她们假如修复的漏洞。
那些只是评估结果环境治理辅助工具和技术时要考虑的几个示例。关键是要拥抱网络平台心态；它的最终目标是帮助合作开发团队获得成功构筑安全软件，而不是跟踪安全漏洞本身。
再次思索优先优先选择事项
最后但并非最不重要的一点是，CNAS 须要再次考虑插件安全优先优先选择级。假如合作开发相关人员需要保护整个云原生植物插件，你希望她们最关注哪些方面？
从历史上看，IT 安全控制主导了更大的预算，并且比插件安全控制获得了更多 CISO 的关注。这种不平衡可能有历史原因，但归根结底，它代表了 CISO 关于怎样最好地采用她们的资金来降低组织机构风险的观点。
换句话说，CISO 认为，由于未修补的服务项目器或配置错误的虚拟化而导致的违规风险大于代码中的自定义漏洞的风险。这种看法有相当多的数据来支持它，显示了历史违规行为及其原因。此外，它很容易理解 ; 对于攻击者来说，大规模运行已知的漏洞并找寻一扇敞开的门要比对插件展开逆向工程并找到自定义缺陷以使其通过要容易得多。
云不会减少这个等式；事实上，云加强了这个等式。选用云意味着采用更多的基础设施和更多的服务项目器，它往往更容易公开访问，并且它由不太熟悉管理它的团队（合作开发相关人员）定义，并配备了不太成熟的辅助工具。
然而，虽然以前的平衡是在 IT 安全预算和插件安全预算之间，但现在一切都在插件安全世界中。在构筑云原生植物插件时，相同的合作开发相关人员须要保护其自定义代码，管理其开源采用中的漏洞，并使服务项目器和虚拟化具备弹性。同一个个应用程序安全团队须要帮助她们做到这一点，并在她们之间分配相同的预算。
因此，她们回到开场白：你希望怎样分配宝贵的合作开发相关人员的时间和有限的 CNAS 预算？
丢掉合作开发相关人员自己的设备和插件安全预算并让合作开发相关人员的注意力集中在保护自定义代码上。插件安全成熟度模型、金融行业最差课堂教学和团队中个人的个人体验都锚定在云前的世界中，其中自定义代码是合作开发相关人员必须保护的大部分内容。购买 SAST 和 DAST 等辅助工具通常是插件安全新领导者名单上的第一件事，很少受到挑战。
但是，考虑到 CNAS 的范围，这仍然是你时间和金钱的最差利用吗？由于已知漏洞或配置错误而导致的违规风险仍然高于自定义代码缺陷的风险，即使合作开发相关人员是配置它的人。假如你同意，难道不假如告诉你的合作开发相关人员和插件安全团队首先要专注于保护那些层，然后才能处理她们的自定义代码吗？
这不是一个容易回答的问题。我不会假设知道你的优先优先选择事项假如是什么，因为那些优先优先选择事项会因组织机构而异。但是，有鉴于 CNAS 的范围更广，我强烈建议你在内部展开此对话并再次考虑你的优先优先选择事项。
结论
发生改变你处理插件可靠性的形式不仅仅是一种思索练习。它具备非常真实的下游影响，包括人们的职业生涯，预算分配和对保持组织机构安全的最差形式的再次评估结果。它须要摆脱一些关于你过去怎样做事的肌肉记忆，而不是在优先选择软件系统时回到第一原则，这须要宝贵的时间和精力。
好消息是，你不必一次完成所有操作。我在责任编辑中概述的变化相互关联，但能按照自己的节奏应用。我建议你优先选择与你最相关的那些内容，或者优先选择你认为更重要的其他变化，并让那些变化继续下去。你将逐步调整安全功能以适应环境云原生植物现实。
查看原文
