DevSecOps 成熟度模型 2024

威胁建模是一种用于识别、评估和管理系统威胁、架构设计缺陷以及推荐安全缓解措施的结构化活动。它通常作为设计阶段的一部分或安全评估的一部分进行。威胁建模是一项团队活动，包括产品负责人、架构师、安全负责人和安全测试人员。在这个成熟度水平上，让团队和利益相关者接触威胁建模，以提高安全意识，并对系统安全形成共同的愿景。在成熟度水平1时，你会对高风险应用进行即兴的威胁建模，并使用简单的威胁清单，例如STRIDE。避免冗长的研讨会和对低相关威胁过于详细的清单。以迭代方式进行威胁建模，以适应更迭代的开发模式。如果向现有应用程序添加新功能，只需关注新增功能，而不是尝试涵盖整个范围。一个好的起点是现有的图表，在讨论研讨会上对其进行注释。始终确保保存威胁建模讨论的结果，以便日后使用。开始威胁建模时，你最重要的工具是白板、智能板或一张纸。目标是提高安全意识、采用简单的流程，并达成可执行的结果，这些结果需要与你的团队达成一致。一旦收集了需求并完成分析，就需要定义实施的具体细节。这个阶段的成果通常是一个图表，概述数据流和整体系统架构。这为威胁建模以及将安全考虑附加到这一阶段的每个任务和史诗提供了机会。来源：https://owaspsamm.org/model/design/threat-assessment/stream-b/ 这里有一些关于威胁建模的很好的建议，例如这篇文章或那篇文章。由 Adam Shostack 本人撰写的一个简明入门指南可以在这里找到。OWASP 包含一篇关于威胁建模的简短文章以及相关的速查表。此外，如果你在遵循 OWASP SAMM，它还有一个关于威胁评估的简短部分。在这个阶段，有一些项目可以帮助创建威胁模型，PyTM 是其中之一，ThreatSpec 是另一个。> 注意：威胁模型可以像数据流图一样简单，在每个流程和资产上标注攻击向量及相应的缓解措施。下面可以找到一个示例。png “威胁模型”) 最后，如果组织将特性映射到史诗（Epics），可以使用安全知识框架（Security Knowledge Framework, SKF）通过其问卷功能来促进此过程。 这一实践的副作用是，它可以训练非安全专家像攻击者一样思考。此阶段的结果应有助于奠定安全设计和考虑的基础。低成熟度示例场景：在模糊的功能需求下，设计包含将数据缓存到使用硬编码密码的本地未加密数据库中。远程数据存储访问密钥硬编码在配置文件中。后端系统之间的所有通信均为明文。前端通过 GraphQL 提供数据，作为缓存系统与最终用户之间的薄层。GraphQL 查询会被动态转换为 SQL、Elasticsearch 和 NoSQL 查询。数据访问通过基本认证保护，开发阶段设置为 1234:1234。来源：OWASP 项目集成项目 风险：技术相关威胁在开发和部署过程中发现得太晚。高级管理层对安全目标进行透明且及时的沟通，对于确保团队的认同和支持至关重要。风险：员工不了解组织的安全目标。因此，在开发和管理过程中，安全性未能得到应有的重视。在创建产品待办事项清单的过程中，会进行业务功能的威胁建模，以便及早发现安全缺陷。风险：与业务相关的威胁在开发和部署过程中被发现得太晚。在创建用户故事的过程中，会创建滥用场景。风险：用户故事大多不考虑安全影响。安全漏洞在开发和部署过程中被发现得太晚。通过在整个组织中创建威胁建模流程和标准，有助于增强安全文化，并为威胁建模演练提供更多结构。风险：业务和技术风险识别不足。高成熟度示例场景：基于通过代码定义和更新的详细威胁模型，团队决定如下：* 本地加密缓存需要设置过期时间并自动清理。* 通信通道需加密和认证。* 所有密钥都存储在共享密钥库中。* 前端设计集成权限模型。* 定义权限矩阵。* 输入经过转义，输出使用成熟的库进行适当编码。来源：OWASP 项目整合项目 高级滥用案例作为威胁建模活动的一部分创建。风险：简单的用户故事不够深入。相关的安全考虑已执行。安全缺陷在开发和部署过程中发现得太晚。标准：在产品冲刺规划期间，对技术功能进行威胁建模。

威胁建模是一种用于识别、评估和管理系统威胁、架构设计缺陷以及推荐安全缓解措施的结构化活动。它通常作为设计阶段的一部分或安全评估的一部分进行。威胁建模是一项团队活动，包括产品负责人、架构师、安全负责人和安全测试人员。在这个成熟度水平上，让团队和利益相关者接触威胁建模，以提高安全意识，并对系统安全形成共同的愿景。在成熟度水平1，你会对高风险应用程序进行即兴的威胁建模，并使用简单的威胁清单，例如STRIDE。避免冗长的研讨会和对低相关威胁过于详细的清单。以迭代方式进行威胁建模，以适应更迭代的开发模式。如果向现有应用程序添加新功能，只需关注新增功能，而不是尝试涵盖整个范围。一个好的起点是现有的图表，在讨论研讨会上对其进行注释。始终确保保存威胁建模讨论的结果，以便日后使用。开始威胁建模时，你最重要的工具是白板、智能板或一张纸。目标是提高安全意识、采用简单的流程，并达成可执行的结果，这些结果需要与你的团队达成一致。一旦收集了需求并完成分析，就需要定义实施的具体细节。这个阶段的成果通常是一个图表，概述数据流和整体系统架构。这为威胁建模以及将安全考虑附加到这一阶段产生的每个工单和史诗提供了机会。来源：https://owaspsamm.org/model/design/threat-assessment/stream-b/ 外面有一些关于威胁建模的很棒的建议，例如这篇文章或这篇文章。亚当·肖斯塔克（Adam Shostack）本人提供的一份精简入门指南可以在这里找到。OWASP 包含一篇关于威胁建模的简短文章以及相关的速查表。此外，如果你正在遵循 OWASP SAMM，它还有一个关于威胁评估的简短部分。在这个阶段，有一些项目可以帮助创建威胁模型，PyTM 是其中之一，ThreatSpec 是另一个。> 注意：威胁模型可以像数据流图一样简单，在每个流程和资产上标注攻击向量及相应的缓解措施。下面可以找到一个示例。png “威胁模型”) 最后，如果组织将特性映射到史诗（Epics），可以使用安全知识框架（Security Knowledge Framework，SKF）通过其问卷功能来促进此过程。 这一实践的副作用是，它可以训练非安全专家像攻击者一样思考。此阶段的结果应有助于奠定安全设计和考虑的基础。低成熟度示例场景：在模糊的功能需求下，设计包含将数据缓存到使用硬编码密码的本地未加密数据库中。远程数据存储访问密钥硬编码在配置文件中。后端系统之间的所有通信均为明文。前端通过 GraphQL 提供数据，作为缓存系统与最终用户之间的薄层。GraphQL 查询会被动态转换为 SQL、Elasticsearch 和 NoSQL 查询。数据访问通过基本认证保护，开发阶段设置为 1234:1234。来源：OWASP 项目集成项目 风险：技术相关威胁在开发和部署过程中发现得太晚。高级管理层对安全目标进行透明且及时的沟通，对于确保团队的认同和支持至关重要。风险：员工不了解组织的安全目标。因此，在开发和管理过程中，安全性未能得到应有的重视。在创建产品待办事项清单的过程中，会进行业务功能的威胁建模，以便及早发现安全缺陷。风险：与业务相关的威胁在开发和部署过程中被发现得太晚。在创建用户故事的过程中，会创建滥用场景。风险：用户故事大多不考虑安全影响。安全漏洞在开发和部署过程中被发现得太晚。通过在整个组织中创建威胁建模流程和标准，有助于增强安全文化，并为威胁建模演练提供更多结构。风险：业务和技术风险识别不足。高成熟度示例场景：基于通过代码定义和更新的详细威胁模型，团队决定如下：* 本地加密缓存需要设置过期时间并自动清理。* 通信通道需加密和认证。* 所有密钥都存储在共享密钥库中。* 前端设计集成权限模型。* 定义权限矩阵。* 输入经过转义，输出使用成熟的库进行适当编码。来源：OWASP 项目整合项目 高级滥用案例作为威胁建模活动的一部分创建。风险：简单的用户故事不够深入。相关的安全考虑已执行。安全缺陷在开发和部署过程中发现得太晚。标准：高级管理人员透明且及时地传达安全目标对于确保团队的认同和支持至关重要。

威胁建模是一种用于识别、评估和管理系统威胁、架构设计缺陷以及推荐安全缓解措施的结构化活动。它通常作为设计阶段的一部分或安全评估的一部分进行。威胁建模是一项团队活动，包括产品负责人、架构师、安全负责人和安全测试人员。在这个成熟度水平上，让团队和利益相关者接触威胁建模，以提高安全意识，并对系统安全形成共同的愿景。在成熟度水平1，您对高风险应用程序进行即兴的威胁建模，并使用简单的威胁清单，例如STRIDE。避免冗长的研讨会和对低相关威胁过于详细的清单。以迭代方式进行威胁建模，以适应更迭代的开发模式。如果向现有应用程序添加新功能，只需关注新增功能，而不是尝试涵盖整个范围。一个好的起点是现有的图表，在讨论研讨会上对其进行注释。始终确保保存威胁建模讨论的结果，以便日后使用。开始威胁建模时，你最重要的工具是白板、智能板或一张纸。目标是提高安全意识、采用简单的流程，并达成可执行的结果，这些结果需要与你的团队达成一致。一旦收集了需求并完成分析，就需要定义实施的具体细节。这个阶段的成果通常是一个图表，概述数据流动和总体系统架构。这为威胁建模以及将安全考虑附加到这一阶段产生的每个工单和史诗提供了机会。来源：https://owaspsamm.org/model/design/threat-assessment/stream-b/ 外面有一些关于威胁建模的很棒的建议，例如这篇文章或这篇文章。亚当·肖斯塔克（Adam Shostack）本人提供的一份精简入门指南可以在这里找到。OWASP 包含一篇关于威胁建模的简短文章以及相关的速查表。此外，如果你正在遵循 OWASP SAMM，它还有一个关于威胁评估的简短部分。在这个阶段，有一些项目可以帮助创建威胁模型，PyTM 是其中之一，ThreatSpec 是另一个。> 注意：威胁模型可以像数据流图一样简单，在每个流程和资产上标注攻击向量及相应的缓解措施。下面可以找到一个示例。png “威胁模型”) 最后，如果组织将特性映射到史诗（Epics），可以使用安全知识框架（Security Knowledge Framework, SKF）通过其问卷功能来促进此过程。 这一实践的副作用是，它可以训练非安全专家像攻击者一样思考。此阶段的成果应有助于奠定安全设计和考虑的基础。低成熟度示例场景：在模糊的功能需求下，设计包含将数据缓存到使用硬编码密码的本地未加密数据库中。远程数据存储访问密钥硬编码在配置文件中。后端系统之间的所有通信均为明文。前端通过 GraphQL 提供数据，作为缓存系统与最终用户之间的薄层。GraphQL 查询会被动态转换为 SQL、Elasticsearch 和 NoSQL 查询。数据访问通过基本认证保护，开发阶段设置为 1234:1234。来源：OWASP 项目集成项目 风险：技术相关威胁在开发和部署过程中发现得太晚。高级管理层对安全目标进行透明且及时的沟通，对于确保团队的认同和支持至关重要。风险：员工不了解组织的安全目标。因此，在开发和管理过程中，安全性未能得到应有的重视。在创建产品待办事项清单的过程中，会进行业务功能的威胁建模，以便及早发现安全缺陷。风险：与业务相关的威胁在开发和部署过程中被发现得太晚。在创建用户故事的过程中，会创建滥用场景。风险：用户故事大多不考虑安全影响。安全漏洞在开发和部署过程中被发现得太晚。通过在整个组织中创建威胁建模流程和标准，有助于增强安全文化，并为威胁建模演练提供更多结构。风险：业务和技术风险识别不足。高成熟度示例场景：基于通过代码定义和更新的详细威胁模型，团队决定如下：* 本地加密缓存需要设置过期时间并自动清理。* 通信通道需加密和认证。* 所有密钥都存储在共享密钥库中。* 前端设计集成权限模型。* 定义权限矩阵。* 输入经过转义，输出使用成熟的库进行适当编码。来源：OWASP 项目整合项目 高级滥用案例作为威胁建模活动的一部分创建。风险：简单的用户故事不够深入。相关的安全考虑已执行。安全缺陷在开发和部署过程中发现得太晚。标准：在创建产品待办事项列表期间进行业务功能的威胁建模，以便及早发现安全缺陷。

威胁建模是一种用于识别、评估和管理系统威胁、架构设计缺陷以及推荐安全缓解措施的结构化活动。它通常作为设计阶段的一部分或安全评估的一部分进行。威胁建模是一项团队活动，包括产品负责人、架构师、安全负责人和安全测试人员。在这个成熟度水平上，让团队和利益相关者接触威胁建模，以提高安全意识，并对系统安全形成共同的愿景。在成熟度水平1时，你会对高风险应用进行即兴的威胁建模，并使用简单的威胁清单，例如STRIDE。避免冗长的研讨会和对低相关威胁过于详细的清单。以迭代方式进行威胁建模，以适应更迭代的开发模式。如果向现有应用程序添加新功能，只需关注新增功能，而不是尝试涵盖整个范围。一个好的起点是现有的图表，在讨论研讨会上对其进行注释。始终确保保存威胁建模讨论的结果，以便日后使用。开始进行威胁建模时，你最重要的工具是白板、智能板或一张纸。目标是提高安全意识、保持流程简洁，并产出你与团队达成一致的可执行成果。一旦收集了需求并进行了分析，就需要定义实施细节。这个阶段的结果通常是一个概述数据流和整体系统架构的图表。这为威胁建模以及将安全考虑附加到这一阶段的每个任务和史诗提供了机会。来源：https://owaspsamm.org/model/design/threat-assessment/stream-b/ 这里有一些关于威胁建模的很好的建议，例如这篇文章或那篇文章。由 Adam Shostack 本人撰写的一个简明入门指南可以在这里找到。OWASP 包含一篇关于威胁建模的简短文章以及相关的速查表。此外，如果你在遵循 OWASP SAMM，它还有一个关于威胁评估的简短部分。在这个阶段，有一些项目可以帮助创建威胁模型，PyTM 是其中之一，ThreatSpec 是另一个。> 注意：威胁模型可以像数据流图一样简单，在每个流程和资产上标注攻击向量及相应的缓解措施。下面可以找到一个示例。png “威胁模型”) 最后，如果组织将特性映射到史诗（Epics），可以使用安全知识框架（Security Knowledge Framework, SKF）通过其问卷功能来促进此过程。 这一实践的副作用是，它可以训练非安全专家像攻击者一样思考。此阶段的成果应有助于奠定安全设计和考虑的基础。低成熟度示例场景：在模糊的功能需求下，设计包含将数据缓存到使用硬编码密码的本地未加密数据库中。远程数据存储访问密钥硬编码在配置文件中。后端系统之间的所有通信均为明文。前端通过 GraphQL 提供数据，作为缓存系统与最终用户之间的薄层。GraphQL 查询会被动态转换为 SQL、Elasticsearch 和 NoSQL 查询。数据访问通过基本认证保护，开发阶段设置为 1234:1234。来源：OWASP 项目集成项目 风险：与技术相关的威胁在开发和部署过程中发现得太晚。高级管理层对安全目标进行透明且及时的沟通，对于确保团队的认同和支持至关重要。风险：员工不了解组织的安全目标。因此，在开发和管理过程中，安全性未能得到应有的重视。在创建产品待办事项清单的过程中，会对业务功能进行威胁建模，以便及早发现安全缺陷。风险：与业务相关的威胁在开发和部署过程中被发现得太晚。在创建用户故事的过程中，会创建滥用场景。风险：用户故事大多不考虑安全影响。安全漏洞在开发和部署过程中被发现得太晚。通过在整个组织中创建威胁建模流程和标准，有助于增强安全文化，并为威胁建模演练提供更多结构。风险：业务和技术风险识别不足。高成熟度示例场景：基于通过代码定义和更新的详细威胁模型，团队决定如下：* 本地加密缓存需要设置过期时间并自动清理。* 通信通道需加密和认证。* 所有密钥都存储在共享密钥存储中。* 前端设计需整合权限模型。* 定义权限矩阵。* 输入是已转义的，输出使用公认的库进行适当编码。来源：OWASP 项目集成项目 高级滥用场景是在威胁建模活动中创建的。风险：简单的用户故事没有深入。相关的安全考虑已经执行。安全漏洞在开发和部署过程中过晚被发现。标准：在用户故事的创建过程中会生成滥用场景。

威胁建模是一种用于识别、评估和管理系统威胁、架构设计缺陷以及推荐安全缓解措施的结构化活动。它通常作为设计阶段的一部分或安全评估的一部分进行。威胁建模是一项团队活动，包括产品负责人、架构师、安全负责人和安全测试人员。在这个成熟度水平上，让团队和利益相关者接触威胁建模，以提高安全意识，并对系统安全形成共同的愿景。在成熟度水平1时，你会对高风险应用进行即兴的威胁建模，并使用简单的威胁清单，例如STRIDE。避免冗长的研讨会和对低相关威胁过于详细的清单。以迭代方式进行威胁建模，以适应更迭代的开发模式。如果向现有应用程序添加新功能，只需关注新增功能，而不是尝试涵盖整个范围。一个好的起点是现有的图表，在讨论研讨会上对其进行注释。始终确保保存威胁建模讨论的结果，以便日后使用。开始进行威胁建模时，你最重要的工具是白板、智能板或一张纸。目标是提高安全意识、保持流程简洁，并产出你与团队达成一致的可执行成果。一旦收集了需求并进行了分析，就需要定义实施细节。这个阶段的结果通常是一个概述数据流和整体系统架构的图表。这为威胁建模以及将安全考虑附加到这一阶段产生的每个工单和史诗提供了机会。来源：https://owaspsamm.org/model/design/threat-assessment/stream-b/ 外面有一些关于威胁建模的很棒的建议，例如这篇文章或这篇文章。亚当·肖斯塔克（Adam Shostack）本人提供的一份精简入门指南可以在这里找到。OWASP 包含一篇关于威胁建模的简短文章以及相关的速查表。此外，如果你在遵循 OWASP SAMM，它还有一个关于威胁评估的简短部分。在这个阶段，有一些项目可以帮助创建威胁模型，PyTM 是其中之一，ThreatSpec 是另一个。> 注意：威胁模型可以像数据流图一样简单，在每个流程和资产上标注攻击向量及相应的缓解措施。下面可以找到一个示例。png “威胁模型”) 最后，如果组织将特性映射到史诗（Epics），可以使用安全知识框架（Security Knowledge Framework, SKF）通过其问卷功能来促进此过程。 这一实践的副作用是，它可以训练非安全专家像攻击者一样思考。此阶段的成果应有助于奠定安全设计和考虑的基础。低成熟度示例场景：在模糊的功能需求下，设计包含将数据缓存到使用硬编码密码的本地未加密数据库中。远程数据存储访问密钥硬编码在配置文件中。后端系统之间的所有通信均为明文。前端通过 GraphQL 提供数据，作为缓存系统与最终用户之间的薄层。GraphQL 查询会被动态转换为 SQL、Elasticsearch 和 NoSQL 查询。数据访问通过基本认证保护，开发阶段设置为 1234:1234。来源：OWASP 项目集成项目 风险：技术相关威胁在开发和部署过程中发现得太晚。高级管理层对安全目标进行透明且及时的沟通，对于确保团队的认同和支持至关重要。风险：员工不了解组织的安全目标。因此，在开发和管理过程中，安全性未能得到应有的重视。在创建产品待办事项清单的过程中，会进行业务功能的威胁建模，以便及早发现安全缺陷。风险：与业务相关的威胁在开发和部署过程中被发现得太晚。在创建用户故事的过程中，会创建滥用场景。风险：用户故事大多不考虑安全影响。安全漏洞在开发和部署过程中被发现得太晚。通过在整个组织中创建威胁建模流程和标准，有助于增强安全文化，并为威胁建模演练提供更多结构。风险：业务和技术风险识别不足。高成熟度示例场景：基于通过代码定义和更新的详细威胁模型，团队决定如下：* 本地加密缓存需要设置过期时间并自动清理。* 通信通道需加密和认证。* 所有密钥都存储在共享密钥库中。* 前端设计集成权限模型。* 定义权限矩阵。* 输入经过转义，输出使用成熟的库进行适当编码。来源：OWASP 项目整合项目 高级滥用案例作为威胁建模活动的一部分创建。风险：简单的用户故事不够深入。相关的安全考虑已执行。安全缺陷在开发和部署过程中发现得太晚。标准：在整个组织中创建威胁建模流程和标准有助于增强安全文化，并为威胁建模演练提供更多结构。

威胁建模是一种用于识别、评估和管理系统威胁、架构设计缺陷以及推荐安全缓解措施的结构化活动。它通常作为设计阶段的一部分或安全评估的一部分进行。威胁建模是一项团队活动，包括产品负责人、架构师、安全负责人和安全测试人员。在这个成熟度水平上，让团队和利益相关者接触威胁建模，以提高安全意识，并对系统安全形成共同的愿景。在成熟度水平1时，你会对高风险应用进行即兴的威胁建模，并使用简单的威胁清单，例如STRIDE。避免冗长的研讨会和对低相关威胁过于详细的清单。以迭代方式进行威胁建模，以适应更迭代的开发模式。如果向现有应用程序添加新功能，只需关注新增功能，而不是尝试涵盖整个范围。一个好的起点是现有的图表，在讨论研讨会上对其进行注释。始终确保保存威胁建模讨论的结果，以便日后使用。开始进行威胁建模时，你最重要的工具是白板、智能板或一张纸。目标是提高安全意识、保持流程简洁，并产出你与团队达成一致的可执行成果。一旦收集了需求并进行了分析，就需要定义实施细节。这个阶段的结果通常是一个概述数据流和整体系统架构的图表。这为威胁建模以及将安全考虑附加到这一阶段产生的每个工单和史诗提供了机会。来源：https://owaspsamm.org/model/design/threat-assessment/stream-b/ 外面有一些关于威胁建模的很棒的建议，例如这篇文章或这篇文章。亚当·肖斯塔克（Adam Shostack）本人提供的一份精简入门指南可以在这里找到。OWASP 包含一篇关于威胁建模的简短文章以及相关的速查表。此外，如果你在遵循 OWASP SAMM，它还有一个关于威胁评估的简短部分。在这个阶段，有一些项目可以帮助创建威胁模型，PyTM 是其中之一，ThreatSpec 是另一个。> 注意：威胁模型可以像数据流图一样简单，在每个流程和资产上标注攻击向量及相应的缓解措施。下面可以找到一个示例。png “威胁模型”) 最后，如果组织将特性映射到史诗（Epics），可以使用安全知识框架（Security Knowledge Framework, SKF）通过其问卷功能来促进此过程。 这一实践的副作用是，它可以训练非安全专家像攻击者一样思考。此阶段的成果应有助于奠定安全设计和考虑的基础。低成熟度示例场景：在模糊的功能需求下，设计包含将数据缓存到使用硬编码密码的本地未加密数据库中。远程数据存储访问密钥硬编码在配置文件中。后端系统之间的所有通信均为明文。前端通过 GraphQL 提供数据，作为缓存系统与最终用户之间的薄层。GraphQL 查询会被动态转换为 SQL、Elasticsearch 和 NoSQL 查询。数据访问通过基本认证保护，开发阶段设置为 1234:1234。来源：OWASP 项目集成项目 风险：技术相关威胁在开发和部署过程中发现得太晚。高级管理层对安全目标进行透明且及时的沟通，对于确保团队的认同和支持至关重要。风险：员工不了解组织的安全目标。因此，在开发和管理过程中，安全性未能得到应有的重视。在创建产品待办事项清单的过程中，会进行业务功能的威胁建模，以便及早发现安全缺陷。风险：与业务相关的威胁在开发和部署过程中被发现得太晚。在创建用户故事的过程中，会创建滥用场景。风险：用户故事大多不考虑安全影响。安全漏洞在开发和部署过程中被发现得太晚。通过在整个组织中创建威胁建模流程和标准，有助于增强安全文化，并为威胁建模演练提供更多结构。风险：业务和技术风险识别不足。高成熟度示例场景：基于通过代码定义和更新的详细威胁模型，团队决定如下：* 本地加密缓存需要设置过期时间并自动清理。* 通信通道需加密和认证。* 所有密钥都存储在共享密钥库中。* 前端设计集成权限模型。* 定义权限矩阵。* 输入是已转义的，输出使用公认的库进行适当编码。来源：OWASP 项目集成项目 高级滥用场景是在威胁建模活动中创建的。风险：简单的用户故事没有深入。相关的安全考虑已经执行。安全漏洞在开发和部署过程中被发现得太晚。标准：通过审查用户故事并生成以安全为导向的数据流程图来进行威胁建模。

威胁建模是一种用于识别、评估和管理系统威胁、架构设计缺陷以及推荐安全缓解措施的结构化活动。它通常作为设计阶段的一部分或安全评估的一部分进行。威胁建模是一种团队活动，包括产品负责人、架构师、安全负责人和安全测试人员。在这个成熟度水平上，让团队和利益相关者接触威胁建模，以提高安全意识，并对系统安全形成共同的愿景。在成熟度水平1时，你会对高风险应用进行即兴的威胁建模，并使用简单的威胁清单，例如STRIDE。避免冗长的研讨会和对低相关威胁过于详细的清单。以迭代方式进行威胁建模，以适应更迭代的开发模式。如果向现有应用程序添加新功能，只需关注新增功能，而不是尝试涵盖整个范围。一个好的起点是现有的图表，在讨论研讨会上对其进行注释。始终确保保存威胁建模讨论的结果，以便日后使用。开始进行威胁建模时，你最重要的工具是白板、智能板或一张纸。目标是提高安全意识、保持流程简洁，并产出你与团队达成一致的可执行成果。一旦收集了需求并进行了分析，就需要定义实施细节。这个阶段的结果通常是一个概述数据流和整体系统架构的图表。这为威胁建模以及将安全考虑附加到这一阶段产生的每个工单和史诗提供了机会。来源：https://owaspsamm.org/model/design/threat-assessment/stream-b/ 外面有一些关于威胁建模的很好的建议，例如这篇文章或那篇文章。由亚当·肖斯塔克本人提供的一份简明入门指南可以在这里找到。OWASP 包含一篇关于威胁建模的简短文章以及相关的速查表。此外，如果你在遵循 OWASP SAMM，它还有一个关于威胁评估的简短部分。在这个阶段，有一些项目可以帮助创建威胁模型，PyTM 是其中之一，ThreatSpec 是另一个。> 注意：威胁模型可以像数据流图一样简单，在每个流程和资产上标注攻击向量及相应的缓解措施。下面可以找到一个示例。png “威胁模型”) 最后，如果组织将特性映射到史诗（Epics），可以使用安全知识框架（Security Knowledge Framework, SKF）通过其问卷功能来促进此过程。 这一实践的副作用是，它可以训练非安全专家像攻击者一样思考。此阶段的成果应有助于奠定安全设计和考虑的基础。低成熟度示例场景：在模糊的功能需求下，设计包含将数据缓存到使用硬编码密码的本地未加密数据库中。远程数据存储访问密钥硬编码在配置文件中。后端系统之间的所有通信均为明文。前端通过 GraphQL 提供数据，作为缓存系统与最终用户之间的薄层。GraphQL 查询会被动态转换为 SQL、Elasticsearch 和 NoSQL 查询。数据访问通过基本认证保护，开发阶段设置为 1234:1234。来源：OWASP 项目集成项目 风险：技术相关威胁在开发和部署过程中发现得太晚。高级管理层对安全目标进行透明且及时的沟通，对于确保团队的认同和支持至关重要。风险：员工不了解组织的安全目标。因此，在开发和管理过程中，安全性未能得到应有的重视。在创建产品待办事项清单的过程中，会进行业务功能的威胁建模，以便及早发现安全缺陷。风险：与业务相关的威胁在开发和部署过程中被发现得太晚。在创建用户故事的过程中，会创建滥用场景。风险：用户故事大多不考虑安全影响。安全漏洞在开发和部署过程中被发现得太晚。通过在整个组织中创建威胁建模流程和标准，有助于增强安全文化，并为威胁建模演练提供更多结构。风险：业务和技术风险识别不足。高成熟度示例场景：基于通过代码定义和更新的详细威胁模型，团队决定如下：* 本地加密缓存需要设置过期时间并自动清理。* 通信通道需加密和认证。* 所有密钥都存储在共享密钥库中。* 前端设计集成权限模型。* 定义权限矩阵。* 输入是已转义的，输出使用公认的库进行适当编码。来源：OWASP 项目集成项目 高级滥用场景是在威胁建模活动中创建的。风险：简单的用户故事没有深入。相关的安全考虑已经执行。安全漏洞在开发和部署过程中过晚被发现。标准：高级滥用故事是在威胁建模活动中创建的。