​多年来，传统安全保证方法已发生了显著变化，从瀑布式开发阶段最初的手动评估，发展到DevSecOps的自动化安全扫描。这些方法主要是在基础层做出设计决策后，针对单个应用程序在下游进行操作。随着共享工程基础的出现，如基础设施即代码（IaC）模板、应用框架、计算镜像以及平台工程团队为开发者复用而创建的其他可复用构建块，软件开发的速率急剧提升。这对传统安全保证方法的扩展性提出了挑战，并阻碍了开发者的生产力。

默认安全认证（Secure by Default Certification，一种针对共享工程基础的内部安全鉴证机制）可用作一种预防性风险控制措施，将安全保证工作前移至共享工程构建模块中。了解如何在企业层面实施这一方法，使用指标来衡量其成功程度，以及开发成熟度模型来跟踪进度，这些都是至关重要的。

安全保证中上游验证的必要性

安全保证控制通常嵌入在软件开发生命周期的预定义点。在设计阶段，产品安全团队参与架构设计和数据流审查。随后，渗透测试团队会通过输入验证测试、绕过身份验证和授权尝试、注入攻击以及配置错误测试等技术，尝试破解应用程序代码。如今，DevSecOps已成为行业常态，在构建和部署持续集成/持续交付（CI/CD）管道时，通常会集成自动化安全扫描和执行工具。治理、风险与合规（GRC）团队也可能在应用程序部署到生产环境之前对其进行审查。这些保证活动对于大多数企业来说是必要的，因为它们使人们相信软件应用程序符合组织的安全策略并遵守监管框架。

然而，所有这些活动的方法本质上都具有结构上的下游性。它们通常针对单个应用程序执行，而很少考虑到构建这些应用程序所依赖的共享工程基础。术语“下游”指的是在基础工程决策已经做出之后进行的保证活动，不应与事件响应或安全漏洞后的安全介入相混淆。

尽管一些组织会审查共享工程基础，但审查得出的保证结果未能有效传递给后续基于此基础构建的应用程序。在现代工程组织中，开发人员经常使用通用的工程框架和组件进行应用程序部署。谷歌云（Google Cloud）的2025年DORA报告指出，90%的组织至少采用了一个平台。这表明，共享的工程平台日益普遍，在许多组织中，这伴随着跨应用程序重用通用组件。因此，当安全审查不考虑共享工程基础时，就会对结构相似的应用程序代码重复进行审查。结果，审查团队多次重复评估同一底层风险，却始终未能解决系统性问题的根源。

鉴于现代软件开发的快速节奏，尤其是在云原生和人工智能驱动的环境中，这些局限性愈发凸显。高开发速度导致对相似代码和架构的反复审查，从而给安全团队带来延误和审查疲劳。随着审查队列的增长，开发人员将安全视为通向生产的障碍，而非推动因素。

默认安全认证与可扩展安全保证

默认安全指的是在共享工程基础（如基础设施即代码（IaC）模板、应用框架、计算镜像以及平台工程团队为开发者复用而创建的其他可复用构建块）中预先集成组织安全控制。这些基础通常由工程团队独立开发，安全方面的参与有限，导致安全配置不一致，在某些情况下甚至不存在安全配置。默认安全确保企业的安全策略能够准确转化为技术特定的要求，并嵌入到基础构建块中。

在此背景下，认证指的是内部安全证明，旨在建立对共享工程基础的信任。这一工作由安全保证、产品安全或GRC团队中的安全领域专家执行。这不应与外部产品认证或监管认证混淆。默认安全认证验证内部共享模板是否默认符合组织安全要求。在存在漏洞的情况下，安全团队会与工程团队合作，在下游应用程序使用模板之前实施适当的安全配置。一旦通过认证，这些基础就被视为工程开发的安全批准起点。这一过程使安全成为共享工程基础治理的一个积极组成部分，而不是在这些基础已经嵌入到生产环境的应用程序中后才被动添加的元素。

行业公认的默认安全配置的一个有力例证是互联网安全中心（CIS）基准，该基准为各种产品提供了规范性配置建议的具体示例。尽管像CIS这样的配置基准是一个良好的起点，但默认安全设置不应仅仅是强化配置。默认安全认证不同于传统的安全审查，因为它面向的是未来状态（即使用该基础构建的任何应用程序的行为方式），而不是针对单个部署。这使安全团队能够在软件开发生命周期早期影响工程和设计决策。影响范围不仅涵盖强制性安全执行，还包括自动凭据轮换、集中日志集成等安全增强——这些措施若等到下游阶段再通过安全保证控制实施，难度将大大增加。产品和应用团队从这种模式中受益匪浅：安全控制在早期通过认证过程"免费"继承。相比之下，若在下游处理，通常成本更高，还会增加已部署应用改造的复杂性。微软的安全未来计划（SFI）提供了可以默认以这种方式集成的安全性控制的示例：强制执行多因素身份验证（MFA）、通过集成硬件安全模块（HSM）功能实现硬件支持的密钥保护，以及增加跨平台服务默认启用的安全配置设置的数量。

默认安全认证必须定期更新，以确保在应对安全策略变化、平台功能更新、特性发布以及不断变化的威胁形势时仍然有效。由于共享组件的数量远少于单个应用程序的数量，因此这些重复的认证仍然具有可扩展性。此外，由于基础层的修复通常发生在特定应用程序开发开始之前，因此通常更快。通过将修复工作提前到软件开发生命周期中，并减少重复发现的问题，这种方法降低了工程团队的摩擦。

可复用保证工件

每次认证都会生成一个保证工件，该工件与经过认证的基础代码一起存储和维护（即存储在同一源代码存储库中）。保证工件记录了：

• 认证元数据，如基础版本、认证日期和范围

• 默认启用安全控制

• 与内部安全和合规要求的对应关系

审查团队将这些保证工件视为控制实施的可信证据，，帮助下游应用程序审查团队依赖共享工程基础的认证状态，而无需从头开始重新建立控制依赖。因此，审查团队可以大幅缩减单个应用程序评估的范围和深度。

默认安全认证因此将安全保证从下游验证转移到工程基础的上游安全增强。但要想使其作为可靠的企业风险控制手段发挥作用，默认安全认证需要明确的治理和运营模式，将GRC（治理、风险与合规）、安全和工程等多个团队的参与联系起来。

默认安全治理在实践中如何运作

默认安全认证是治理、风险与合规（GRC）、安全与工程团队之间的一种共享企业控制机制。每个团队负责并维护流程中的特定部分，以确保团队将安全策略作为安全控制措施整合到工程基础中。审查团队随后验证由此产生的可信保证工件。

1. 策略定义

GRC团队首先制定高级安全策略和标准，这些策略和标准特意与技术无关，通常适用于多个平台和系统。例如，一项策略可能要求所有存储服务在静态状态下使用高级加密标准（AES）-256等强加密算法进行加密。

默认安全认证需要明确的治理和运营模式，这些模式需将来自GRC（治理、风险与合规）、安全和工程等多个团队的参与活动联系起来。

2. 控制规范与设计

具备架构和平台专业知识的安全团队将这些高级安全策略转化为可操作且针对特定技术的要求。这种方法解决了将通用策略声明转换为特定平台实施配置的难题。例如，安全团队将整体加密策略转化为针对Amazon RDS的具体要求，即数据库必须使用客户管理的密钥管理服务，并启用最小权限密钥策略和自动轮换功能。

控制规范是安全对工程基础成果影响最大的环节。安全要求的早期规范直接影响基础架构决策，这使团队能够从一开始就解决安全问题，而非在后期被迫改造。

控制规范也是一个很好的机会，可以借此确定哪些控制是强制性的，哪些可以在下游部署中进行配置。安全和工程部门会根据风险等级（例如，高风险=强制性）和业务可变性共同确定这一点。

3. 控制实施

工程团队随后将翻译后的、针对特定平台的安全默认要求嵌入到共享模板中，如基础设施即代码（IaC）模块、应用程序框架或加固的计算镜像。这些默认安全配置不仅是政策强制执行的措施；它们还可能包含可选的安全增强功能（例如，密码自动轮换和集中日志记录）。这使得下游团队无需付出任何额外努力即可受益于某些控制措施。根据组织的成熟度，控制措施的实施可以由工程团队在安全审查的辅助下进行，也可以由安全团队在工程审查的辅助下进行。

默认安全认证指标将安全投资回报从已发现风险转变为已预防风险。

4. 控制保证

安全团队对每个共享代码模板进行默认安全认证，以验证其实现情况并创建保证工件。验证过程包括代码分析和部署测试，以确保共享模板正确执行安全控制。安全团队向工程团队通报并讨论默认安全违规情况，以便共同修复。对于因技术或业务限制而无法实现的要求，认证团队在认证过程中明确记录，并纳入现有的组织风险管理流程加以跟踪。认证团队将认证元数据、控制到策略的映射及验证结果与共享模板一并记录。，从而创建持久且可机器验证的审计跟踪。

5. 控制依赖

保证工件为传统安全保证方法提供了明确证据，证明默认安全控制已嵌入上游基础。审查团队评估下游应用程序时，可直接参考这些证据。

治理、风险与合规（GRC）团队和安全保证团队可根据以下因素确定他们能在多大程度上依赖这些控制措施：

• 认证的及时性和范围（包括涵盖哪些下游资源）

• 默认执行强制性安全控制

• 存在可能被覆盖的可选控件，以及用于检测此类覆盖的支持证据

• 已部署的实施方案是否使用了经过认证的模板版本

• 任何有记录的例外或偏差

这使得安全审查团队能够在不降低保证水平的情况下，减少或消除在单个应用程序层面的重复控制测试。

图1展示了政策定义如何转化为经过认证的共享工程基础，以及安全审查团队如何通过保证工件依赖这些基础。

图1 - 默认安全治理流程

衡量安全保证的影响

持续集成/持续交付（CI/CD）扫描工具的安全影响指标主要侧重于事后安全指标，如发现的漏洞、检测到的反模式和阻止的错误配置。虽然这些指标表明安全工具正在发挥作用并检测到了一些缺陷，但它们并不能保证应用程序中启用的安全配置是安全的。换言之，单靠自动化安全测试工具无法为系统注入软件保证。

默认安全认证指标将安全投资回报从发现风险转变为预防风险。该计划使用经过认证的模板计算部署的运行时资源数量，并根据代码中嵌入的安全默认设置验证其配置。通过这种方式，该计划可以生成可衡量的证据，证明认证已产生经过验证的安全配置，这对工程和安全都有益。

默认安全指标展示了该计划作为跨治理、风险与合规（GRC）、安全和工程团队的共享企业控制措施的有效性。很少有安全举措能同时产生可衡量的成果，既反映工程速度的提升，又降低系统性风险，并增强审计信心。

1 预防安全缺陷和避免工程投入

在认证过程中，当发现并修复共享模板中的安全缺陷时，这些缺陷在下游环境中永远不会出现。如果在基础层上未得到解决，一个单一的安全漏洞可能会导致成百上千的下游安全缺陷。默认安全认证不是反复修复同一个问题，而是从源头上消除缺陷。在上游消除的每一个缺陷，都为下游团队节省了工作负载。

每个认证模板预防的安全缺陷 = 认证模板中修复的缺陷数量 x 使用该认证模板部署的总资源

举个例子。如果通过认证默认启用审计日志记录，则所有下游数据库部署都将继承此配置。如果使用经过认证的模板创建了100个数据库，那么就可以从源头上防止100种潜在的日志记录配置错误，从而避免了在各个应用程序中重复进行修复。

2 通过有保障的工作负载消除风险

通过确保工作负载消除的风险与预防缺陷是不同的：它衡量的是通过设计消除的整个类别的安全风险。例如，默认安全认证的模板可能默认情况下就无法进行未加密存储或公开暴露。这些强制性控制措施无需开发人员额外努力即可自动继承。

每个认证模板通过有保障的工作负载消除的风险 = 认证模板中实施的强制性控制措施数量 x 使用该认证模板部署的总资源

在同一个例子中，如果经过认证的数据库模板强制执行五项强制性安全控制措施，并且使用此模板部署了100个数据库，那么通过设计就消除了500个安全风险实例。这些强制性控制措施默认已执行，无需开发人员额外实施。

3 避免安全审查工作

使用经过认证的资源构建的工作负载默认具有保障，并且作为共享工程基础的一部分，已实施安全配置。这些有保障的工作负载大大缩短了安全审查周期，因为用于配置安全控制的部分或全部证据已在默认安全元数据中进行了记录。因此，由于审查范围和深度减少，安全审查人员开展单独评估所需的时间也相应减少

每个认证模板避免的安全审查工作  = 收集证据的平均代码和部署审查时间 x 每个认证模板通过设计消除的风险

例如，如果一个经过认证的数据库模板实施了五项强制性控制措施，而每项控制措施在应用程序审查过程中通常需要数小时的验证，那么对于100次数据库部署，可以节省大量的审查工作。审查人员无需重复验证这些控制措施，而是可以依赖认证过程中生成的保证工件，仅关注与认证基线的偏差。

默认安全认证成熟度模型

随着组织的发展，默认安全实践会逐步得到采纳。通过成熟度等级来构建默认安全框架，有助于安全和工程领导者以结构化的方式评估当前状态并规划投资。

在图2中，第1级和第2级代表在默认安全认证发生之前，即工程基础缺乏安全治理时的组织状态。第3级、第4级和第5级则反映了默认安全认证后的状况。

图2 - 默认安全认证成熟度模型1-5级

第一级：预认证（去中心化DevOps）

在第一级，没有可重用的代码模板或由工程团队正式维护的共享构建块。产品开发人员独立从头开始开发基础设施和应用程序代码，这导致环境之间存在高度可变性。

在缺乏共享模板的情况下，类似的安全问题会反复出现，导致需要重复进行修复工作。安全保证在很大程度上依赖于对单个应用程序的手动验证和自动化安全扫描，而这并没有有效的扩展方法。

第二级：预认证（未经保证的共享工程基础）

 

在第二级，平台团队为通用代码和部署模式创建并维护共享模板。因此，代码和架构的差异得以减少，但这些共享工程基础在默认情况下并未得到安全认证或从保证角度进行治理。

尽管存在共享模板，但其安全态势无法在下游得到可靠继承。因此，安全保证仍然严重依赖于对单个应用程序的验证。

第三级：默认安全认证共享工程基础

在这一层面，存在一个正式的默认安全认证流程，并针对共享工程基础进行。认证验证默认启用的控制措施是否符合安全策略，并生成与共享模板一起存储的保证工件。

安全审查人员将认证视为可信赖的保证来源。然而，共享工程基础目前尚未覆盖所有开发需求，部分现有基础也尚未通过安全认证。此外，对于已认证基础是否偏离了默认安全状态，我们所能提供的保证有限。因此，对认证的依赖控制范围仍然有限。

第四级：持续保证、认证的共享工程基础

在第四级，通过自动化机制持续监控经过认证的工程基础是否偏离预期的安全状态。安全策略、平台能力或威胁形势发生变化时，事件驱动的重新认证机制随即启动，确保认证和保证工件持续有效。

指标会自动生成，并量化认证计划的影响力和覆盖范围。它们在待办事项和投资决策中也发挥着积极作用。在这一层面，安全审查人员已开始使用经过认证的基础设施作为目标控制依赖，从而节省了审查工作的时间，并加快了审批周期。

第五级：对认证基础的控制依赖

在这一级，所有共享工程基础（包括基础设施和应用模板）均已默认安全认证。产品安全、安全保证证、治理、风险与合规（GRC）以及审计团队大量使用认证保证工件，以大幅减少单个应用审查的范围和深度。

组织政策现规定，对于适用的用例，必须使用经过默认安全认证的基础设施。若产品团队未使用经过认证的基础设施，平台团队将与产品团队合作，将工作负载迁移到经过认证的来源。

在这一层面，默认安全认证作为企业风险控制手段，其提供的保证力度与传统预防性控制相当。

结论

随着共享工程平台成为现代软件开发的范式，组织必须将默认安全认证视为一种企业风险控制手段，默认将安全控制嵌入共享工程基础。这是一种实用的默认安全认证操作模式，通过可重用的保证工件将工程基础与安全治理联系起来。这种方法减少了安全和工程方面的冗余工作，并建立了一个可扩展的风险和合规性保证流程，该流程能够与开发人员的工作效率保持同步。

希望采用这种模式的组织可以分三步起步：首先，确定一组广泛使用的共享模板或平台组件；其次，为这些组件定义默认的基线安全控制要求；最后，与工程团队一起开展试点认证。建立轻量级的保证工件，并将这些试点组件的认证输出集成到现有的安全审查和风险管理流程中，这可以展示早期价值，并随着时间的推移实现更广泛的采用。早期试点应侧重于减少重复发现，并提高下游安全审查的效率。

作者：Anunay Bhatt，他是一位首席安全工程师，拥有十多年的大型组织云安全控制设计经验。

翻译：杨皓然（AdySec），CISSP，CISM，CISA，CDPSE，CRISC，CGEIT，PMP，CCSK，CZTP，CDSP，CCSSP，RHCA，CCNP，ISO27001 Auditor，ISACA中国翻译工作组成员，ISACA中国特邀专家，ISC2北京分会会员，致力于云安全、数据安全、安全运营、安全攻防、开源威胁情报、AI应用开发等方向。

校对：姚凯（Kevin Yao），CISA，CISM，CRISC，CGEIT，CDPSE，ISACA中国翻译工作组成员，拥有二十余年IT从业经验，近年来关注IT安全，隐私保护和数字化。

​