CISO助手
完成度
0%(0/189)
评估报告
DSOM

DevSecOps 成熟度模型 2024

成熟度模式

DevSecOps成熟度模型,帮助组织实施和改进DevSecOps实践。

版本: 2024覆盖状态: 完整覆盖 (378/378)控制项/量表/总计: 189/189/378当前展示: 16 / 1895 个分类

应用的静态深度

16
T-SA-2-2软件成分分析(服务器端)成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽略,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估计被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在子维度“基础设施静态深度”中重复,但它同样适用于基础设施。风险:自动创建的依赖关系 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复内容。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析,以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会有意外行为。标准:对服务器端组件(例如后端/中间件)已知漏洞进行测试。

评估
评估状态:
评估备注:
T-SA-2-3测试补丁时间成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽略,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复,但它同样适用于基础设施。风险:自动依赖的拉取请求被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码的凭证和变量、敏感信息)。自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或晦涩的代码可能会有意想不到的行为。标准:修复时间的测试(例如基于自动拉取请求关闭的平均时间)。此活动在“基础设施的静态深度”子维度中没有重复,但同样适用于基础设施。

评估
评估状态:
评估备注:
T-SA-2-4测试 libyear成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽略,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在子维度“基础设施静态深度”中不会重复,但它同样适用于基础设施。风险:自动创建的依赖项 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复内容。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会有意想不到的行为。标准:测试 `libyear`,它能很好地反映补丁管理的有效性。

评估
评估状态:
评估备注:
T-SA-3-1API设计验证成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动依赖项的 PR 被忽略,导致生产环境工件中存在已知漏洞。测试 `libyear`,它可以很好地了解补丁管理的效果。风险:运行中的工件中的漏洞存在时间过长,可能被利用。使用接口描述语言(如 OpenAPI、AsyncAPI 或 SOAP)设计契约优先的 API,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码规范插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复,但它同样适用于基础设施。风险:自动创建的依赖关系 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能出现意外行为。标准:使用OpenAPI、AsyncAPI或SOAP等接口描述语言设计以合同为先的API,并使用特定工具验证规范。检查应集成开发环境(IDE)和CI/CD流水线。

评估
评估状态:
评估备注:
T-SA-3-2漏洞利用可能性评估成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动依赖项的 PR 被忽略,导致生产环境工件中存在已知漏洞。测试 `libyear`,它可以很好地了解补丁管理的效果。风险:运行中的工件中的漏洞存在时间过长,可能被利用。使用接口描述语言(如 OpenAPI、AsyncAPI 或 SOAP)设计契约优先的 API,并使用特定工具验证规范。检查应集成在 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复,但它同样适用于基础设施。风险:自动创建的依赖项 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码的凭证和变量、敏感信息)。自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析,以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会有意想不到的行为。标准:通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估计被利用的可能性。

评估
评估状态:
评估备注:
T-SA-3-3已执行本地开发安全检查成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽视,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码中的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在子维度“基础设施静态深度”中重复,但它同样适用于基础设施。风险:自动依赖的拉取请求被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会导致意外的行为。标准:将质量和代码检查插件集成到交互式开发环境(IDE)中。执行提交前检查,以防止将机密信息和其他安全问题提交到源代码中。

评估
评估状态:
评估备注:
T-SA-3-4软件成分分析(客户端)成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动依赖项的 PR 被忽略,导致生产环境工件中存在已知漏洞。测试 `libyear`,它可以很好地了解补丁管理的效果。风险:运行中的工件中的漏洞存在时间过长,可能被利用。使用接口描述语言(如 OpenAPI、AsyncAPI 或 SOAP)设计契约优先的 API,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复,但它同样适用于基础设施。风险:自动创建的依赖项 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码的凭证和变量、敏感信息)。自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会有意外行为。标准:通过前端的软件成分分析对组件已知漏洞进行测试。

评估
评估状态:
评估备注:
T-SA-3-5重要客户端组件的静态分析成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽略,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估计被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码规范插件与交互式开发环境(IDE)集成。实施提交前检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复,但它同样适用于基础设施。风险:自动创建的依赖项 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会产生意外的行为。标准:对前端重要部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。

评估
评估状态:
评估备注:
T-SA-3-6重要服务器端组件的静态分析成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽视,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码规范插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在子维度“基础设施静态深度”中不会重复,但它同样适用于基础设施。风险:自动依赖的拉取请求被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有的漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会产生意外的行为。标准:对中间件的重要部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。

评估
评估状态:
评估备注:
T-SA-3-7补丁部署时间测试成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动依赖项的 PR 被忽略,导致生产环境工件中存在已知漏洞。测试 `libyear`,它能很好地体现补丁管理的效果。风险:运行中的工件中的漏洞存在时间过长,可能被利用。使用接口描述语言(如 OpenAPI、AsyncAPI 或 SOAP)设计契约优先的 API,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的组件软件组成分析(SCA)对已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复,但它同样适用于基础设施。风险:自动创建的依赖关系 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有的漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复内容。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或模糊的代码可能会有意想不到的行为。标准:补丁部署时间测试。此活动在子维度“基础设施的静态深度”中没有重复,但同样适用于基础设施。

评估
评估状态:
评估备注:
T-SA-4-1所有自编组件的静态分析成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动依赖项的 PR 被忽略,导致生产环境工件中存在已知漏洞。测试 `libyear`,它可以很好地了解补丁管理的效果。风险:运行中的工件中的漏洞存在时间过长,可能被利用。使用接口描述语言(如 OpenAPI、AsyncAPI 或 SOAP)设计契约优先的 API,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施提交前检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复,但它同样适用于基础设施。风险:自动创建的依赖关系 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会产生意外的行为。 标准:对中间件和前端的所有部分使用静态分析工具。 静态分析例如使用字符串匹配算法和/或数据流分析。

评估
评估状态:
评估备注:
T-SA-4-2使用多个分析器成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动依赖项的 PR 被忽视,导致生产环境工件中存在已知漏洞。测试 `libyear`,它可以很好地了解补丁管理的效果。风险:运行中的工件中的漏洞存在时间过长,可能被利用。使用接口描述语言(如 OpenAPI、AsyncAPI 或 SOAP)设计契约优先的 API,并使用特定工具验证规范。检查应集成在 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码规范插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复,但它同样适用于基础设施。风险:自动创建的依赖关系 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码的凭证和变量、敏感信息)。自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析,以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会有意外的行为。标准:使用多种静态工具来发现更多漏洞。

评估
评估状态:
评估备注:
T-SA-5-1死代码消除成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽略,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复,但它同样适用于基础设施。风险:自动依赖的 PR 被忽视,导致生产制品中存在已知漏洞。使用静态分析工具对中间件和前端的所有部分进行分析。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析,以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或模糊的代码可能会有意想不到的行为。标准:收集未使用的代码,然后手动删除未使用的代码。

评估
评估状态:
评估备注:
T-SA-5-2排除源代码重复成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽略,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估计被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复,但它同样适用于基础设施。风险:自动依赖的 PR 被忽视,导致生产制品中存在已知漏洞。使用静态分析工具对中间件和前端的所有部分进行分析。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有的漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析,以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或模糊的代码可能会有意想不到的行为。标准:自动检测并手动移除源代码中的重复部分。

评估
评估状态:
评估备注:
T-SA-5-3所有组件/库的静态分析成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动生成的依赖项拉取请求可能被忽略,导致生产工件中存在已知漏洞。测试 `libyear`,它能很好地展示补丁管理的效果。风险:运行中的工件中的漏洞可能存在较长时间,并可能被利用。设计以合同为先的 API,使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施提交前检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在子维度“基础设施静态深度”中不会重复,但它同样适用于基础设施。风险:自动依赖的拉取请求被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码增加了攻击面(使用硬编码的凭证和变量、敏感信息)。自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或混淆的代码可能会有意外行为。标准:对所有使用的组件进行静态分析。

评估
评估状态:
评估备注:
T-SA-5-4风格分析成熟度实践
测试与验证 / 应用的静态深度

对服务器端组件(例如后端/中间件)已知漏洞进行测试。风险:服务器端组件可能存在漏洞。补丁响应时间测试(例如基于自动 PR 的平均关闭时间)。此活动不会在“基础设施静态深度”子维度中重复,但同样适用于基础设施。风险:自动依赖项的 PR 被忽略,导致生产环境工件中存在已知漏洞。测试 `libyear`,它可以很好地了解补丁管理的效果。风险:运行中的工件中的漏洞存在时间过长,可能被利用。使用接口描述语言(如 OpenAPI、AsyncAPI 或 SOAP)设计契约优先的 API,并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险:创建不安全或不合规的 API。通过使用过去的数据(CISA KEV)或预测模型(EPSS)来估算被利用的可能性。风险:如果没有适当的优先排序,组织可能会在低风险漏洞上浪费时间和精力,而忽视关键漏洞。将质量和代码检查插件与交互式开发环境(IDE)集成。实施预提交检查,以防止将敏感信息和其他安全问题提交到源代码中。风险:创建和开发的代码可能包含代码异味和质量问题。通过前端的组件软件组成分析(SCA)对已知漏洞进行测试。风险:客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险:中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复,但它同样适用于基础设施。风险:自动创建的依赖关系 PR 被忽略,导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险:前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险:每个漏洞分析工具都有不同的优势。仅使用一个分析工具,可能会发现不到所有的漏洞。收集未使用的代码,然后手动删除未使用的代码。风险:死代码会增加攻击面(使用硬编码凭证和变量、敏感信息)。 自动检测并手动删除源代码中的重复代码。风险:源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险:使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守(例如缩进、循环等)。风险:不清晰或模糊的代码可能会有意外行为。标准:分析源代码是否符合样式指南,确保源代码的格式化规则得到遵守(例如缩进、循环等)。

评估
评估状态:
评估备注: