2.2 记分卡设计
Compass 可以减少开发人员和治理团队的摩擦,在提高速度的同时帮助改善软件的运行状况和质量。记分卡可帮助开发人员社区预先了解期望,并提供完成这些期望的进度透明度。这意味着软件团队可减少因在交付周期后期传达合规要求而造成的返工。
记分卡提供的透明度意味着治理团队可以自助提供合规信息,使他们能够为有需要的团队提供支持,并让团队能够在“快乐路径”上更快地完成任务。这通常会减少治理会议和报告要求,消除软件团队常见的摩擦点。
以下是设计将在 Compass 中创建的记分卡的一些建议步骤。
2.2.1 确定现有的工程标准或治理要求
将现有工程标准或治理要求转换到 Compass 是开始使用记分卡的理想方式。使用现有标准意味着利用已经熟悉的标准,Compass 用户和治理团队就有了进入平台的软入口。
最好能列出软件团队必须遵守的所有标准和治理标准,并选择其中一项作为起点。
示例:漏洞标准MegaBank 要求所有软件组件保持少于 10 个严重性级别为“严重”的未解决漏洞和少于 10 个严重性级别为“高”的未解决漏洞。
2.2.2 确定记分卡的数据源
确定标准后,将需要相应的数据源。Compass 记分卡可从第三方应用和/或通过 API 获取数据,从而根据组织需求提供情景化视图。
最好能列出软件团队必须遵守的所有标准和治理标准,并选择其中一项作为起点。
示例:漏洞标准MegaBank 使用 Snyk 跟踪和管理整个软件资产的安全漏洞。Snyk 被确定为漏洞信息的数据源,并将用于填充 Compass 中的漏洞记分卡。Marketplace 中有 Snyk 应用,该应用将用于连接 Compass 和 Snyk。
2.2.3 定义标准和权重
Compass 记分卡允许您定义标准和每个标准的权重。权重用于根据应用于每项输入的重要性或权重来操纵总分。
示例:漏洞标准MegaBank 更关注严重性级别为“严重”的未解决漏洞的数量,而不是严重性级别为“高”的未解决漏洞的数量。因此,为严重性级别为“严重”的漏洞加上 75% 的权重,为严重性级别为“高”的漏洞加上 25% 的权重。

2.2.4 记录记分卡设计
在确定要在 Compass 中作为记分卡构建的现有工程标准或治理要求时,可使用以下格式捕捉记分卡设计细节。这样,您就能在构建 Compass 记分卡之前获得反馈并进行迭代。
相关标准 | 标准 | 权重 | 来源 | 数据源负责人 | 集成方法(应用/API) |
安全软件策略 | 少于 10 个严重性级别为“严重”的未解决漏洞 | 75% | Snyk | Charliotte Smith | 应用 |
安全软件策略 | 少于 10 个严重性级别为“高”的未解决漏洞 | 15% | Snyk | Charliotte Smith | 应用 |
安全软件策略 | 代码中少于 1 个公开机密 | 10% | Hashicorp | Daniel Charles | API |
相关标准 | 标准 | 权重 | 来源 | 数据源负责人 | 集成方法(应用/API) |
---|---|---|---|---|---|
Related standard(s) 安全软件策略 | 标准 少于 10 个严重性级别为“严重”的未解决漏洞 | 权重 75% | 来源 Snyk | 数据源负责人 Charliotte Smith | 集成方法(应用/API) 应用 |
Related standard(s) 安全软件策略 | 标准 少于 10 个严重性级别为“高”的未解决漏洞 | 权重 15% | 来源 Snyk | 数据源负责人 Charliotte Smith | 集成方法(应用/API) 应用 |
Related standard(s) 安全软件策略 | 标准 代码中少于 1 个公开机密 | 权重 10% | 来源 Hashicorp | 数据源负责人 Daniel Charles | 集成方法(应用/API) API |