成熟度模型中的建筑安全 15 15

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。