28、应用安全路线图与成效衡量指南

应用安全路线图与成效衡量指南

在当今数字化时代，应用程序安全至关重要。构建有效的应用安全路线图以及衡量安全项目的成效，是保障组织软件安全的关键环节。下面将详细介绍应用安全路线图的构建以及如何衡量安全项目的成效。

1. 工程与安全路线图的对齐

与工程组织的协作和路线图对齐看似抽象，但实际上极为重要。应用安全团队的职责是确保工程团队具备开发安全软件所需的信息和工具，因此创建支持这一努力的生态系统至关重要。应用安全团队需要构建一个路线图来实现这种对齐，具体分为以下四个阶段：
1. 阶段一：收集组织内的产品路线图
- 收集组织内现有的产品路线图，这有助于应用安全团队了解组织技术或产品即将发生的变化。
- 了解工程组织的优先级，因为产品和工程虽然优先级可能一致，但实现方式的视角不同。工程侧重于执行，而产品侧重于销售。
2. 阶段二：收集应用安全文档并建立着陆页
- 收集与阶段一中路线图项目相关的应用安全文档。
- 建立一个应用安全着陆页，为工程团队提供获取信息的清晰指导。着陆页常见的内容如下表所示：
| 示例页面 | 描述 |
| — | — |
| 参考架构 | 组织应使用的明确标准安全架构，作为所有通用架构的起点，例如认证流程。 |
| 流程文档 | 与应用安全中的安全流程相关的文档，例如生成安全对称加密密钥的流程。 |
| 提供的服务 | 应用安全团队为组织提供的服务列表，例如安全代码审查。 |
| 联系方法 | 联系应用安全团队的方式，可以通过Slack、电子邮件或其他沟通渠道。 |
3. 阶段三：构建文档并确定服务需求
- 根据阶段二的差距构建文档。
- 确定工程组织所需的服务列表。
- 为每个服务创建需求列表。
4. 阶段四：开发服务
- 根据阶段三的需求开发服务。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([阶段一]):::startend --> B(收集组织内的产品路线图):::process
    A --> C(了解工程组织的优先级):::process
    D([阶段二]):::startend --> E(收集应用安全文档):::process
    D --> F(建立应用安全着陆页):::process
    G([阶段三]):::startend --> H(构建文档):::process
    G --> I(确定服务列表):::process
    G --> J(创建服务需求列表):::process
    K([阶段四]):::startend --> L(开发服务):::process

此外，当工程团队考虑更换源代码管理（SCM）工具时，应用安全团队需要审查新平台，确保其符合组织的安全目标和要求，并提供相应的建议，这些建议应记录下来供工程团队参考。

2. 面向未来的规划

在Scrum和敏捷开发的时代，很难提前规划6个月甚至几年后的事情。但在应用安全中，制定路线图时需要考虑以下几点：
1. 差距分析 ：通过差距分析指导战略思考和目标设定。例如，安全工具覆盖可能存在漏洞，或者组织有现代化认证的指令，又或者采用了多云策略，新开发将利用多个云服务提供商（CSP）的服务。
2. 与组织目标对齐 ：应用安全团队的工作需要与组织的其他安全职能（如信息安全、网络安全和安全运营中心）以及业务目标对齐。大多数组织需要进行年度审计和渗透测试，这需要应用安全团队的支持。
3. 制定多年路线图 ：路线图应具有较高的层次，以项目为导向，而不是具体细节。可以使用差距分析或更正式的成熟度模型（如BSIMM或SAMM）来制定路线图，并且每年的能力应在前一年的基础上有所提升。

以Superior Products为例，Dashing Danielle为未来3年制定路线图。她首先收集当前的安全态势和组织的安全目标，并进行差距分析，确定了以下几个关键目标：
1. 工具覆盖 ：在3年内实现工具100%覆盖，目前SAST覆盖率为45%，DAST为70%，SCA为30%，目标是3年后均达到100%。
2. 安全培训 ：确保所有现有和新工程师完成应用安全培训课程，目前安全培训参与率为25%，目标是达到100%。
3. 数据分类 ：完成组织内数据的分类，以满足安全组织的加密要求，目前已分类数据占比为20%，目标是100%。
4. 安全代码审查 ：开发并实施代码审查平台和流程，目前每次发布的安全代码审查数量占比为10%，目标是75%。
5. 合规与监管 ：将合规和监管要求集成到编码中，以便于审计。
6. 安全测试 ：将安全测试集成到测试过程中，减少生产环境中发布的漏洞，目前代码安全测试覆盖率为30%，目标是75%。

此外，还有一些由业务和安全组织指导的其他项目：
1. 确保所有个人身份信息（PII）和关键数据在静态时加密。
2. 与安全运营团队和信息安全集成，提供漏洞管理的统一视图。
3. 为多云环境提供安全开发管道。
4. 增加内部渗透测试的覆盖范围。

Dashing Danielle还为每个项目制定了基本的项目计划，以确定目标、里程碑和风险。例如，代码审查平台的项目计划如下：
| 季度 | 目标 | 里程碑 | 风险 |
| — | — | — | — |
| Q1 | 开发代码审查平台的需求，评估可与组织SCM集成的代码审查工具，对两个产品进行POC，收集许可证需求并创建3年的总体拥有成本。 | 完成需求开发、工具评估、POC和成本估算。 | 没有工具能够与SCM配合工作；与SCM集成需要大量工作；代码审查平台成本过高；关键工作干扰当前时间表。 |
| Q2 | - | - | - |
| Q3 | - | - | - |
| Q4 | - | - | - |

创建、跟踪和实施这些路线图并非易事，需要领导的支持和项目经理的协调。定期报告进度和风险，确保领导了解进展情况和可能需要解决的障碍。

3. 衡量应用安全项目的成效

开发了涵盖开发管道不同阶段安全的项目，并制定了应用安全团队的中长期目标路线图后，如何判断项目是否有效，以及团队的努力是否得到回报呢？收集指标对于任何项目或计划都至关重要，它不仅能确保项目达到预期目的，还能判断项目是否按计划进行并取得预期成果。对于安全项目而言，指标同样用于确定流程是否有效、组织的安全态势是否改善以及所使用的工具是否有效。

3.1 衡量工具的有效性

通过分析工具的输出，挖掘定量和定性指标来衡量工具的有效性。
- 定量指标 ：基于实际数字，例如一级支持团队响应客户问题的平均时间（以分钟为单位）。
- 定性指标 ：通过访谈、讨论或问卷调查收集，更多基于受访者的主观感受。例如，向与应用安全团队合作的工程团队发送调查，了解他们对合作的满意度。

需要衡量的应用安全工具包括：
- 静态应用安全测试（SAST）
- 动态应用安全测试（DAST）
- 交互式应用安全测试（IAST）
- 软件成分分析（SCA）
- 运行时应用安全保护（RASP）
- 网络应用防火墙（WAF）

衡量这些工具的有效性时，重点关注以下两个定量指标：
- 每个工具发现的漏洞数量。
- 发现的漏洞中真阳性与假阳性的比例。

有了这些信息，应用安全团队就可以对产生假阳性的工具进行调整。

3.2 根据反馈调整工具

以Superior Products组织为例，SAST工具集成到开发管道后，大部分规则和配置采用了供应商的默认设置。应用安全团队通过抽样审计评估发现结果，以确定是否为假阳性以及是否需要调整工具以减少假阳性。

例如，SAST工具对旗舰产品Stuff - For - You标记了多个竞态条件问题，但实际执行代码并非多线程，因此这些发现可标记为不适用。应用安全团队可以将该项目设置为忽略SAST工具的此类发现，避免未来输出此类结果。

然而，了解工具的假阳性情况固然重要，但工具发现真阳性的实际效果同样关键。如果组织在开发管道中使用了多个扫描工具（如SAST、DAST和SCA），如何确定这些工具发现的漏洞就是影响应用的全部漏洞呢？实际上，无论在管道中使用多少工具，都无法发现应用的所有漏洞，这些未被发现的漏洞称为假阴性。

可以通过其他工具和流程为扫描工具提供反馈。例如，根据外部渗透测试的结果，审查DAST或IAST工具的配置，以确定为何未发现某些问题。在Superior Products的年度外部渗透测试中，Stuff - For - You产品发现了XSS漏洞，但开发管道中使用的SAST和DAST工具却未检测到。经调查发现，受测试的特定模型未被SAST和DAST工具扫描，这是由于代码替换过程中的配置错误导致的。

对于运行时环境中使用的保护工具（如WAF或RASP），调整的重点是确保：
- 合法流量不被阻止。
- 非法流量不被放行。

大多数应用安全团队采用分阶段的方法集成保护工具。例如，Superior Products的应用安全团队与Stuff - For - You团队合作，先在预生产环境集成WAF，测试流量是否正常。集成过程中发现了流量下降和数字证书重用的问题，团队通过采购唯一证书解决了证书重用问题，经过进一步排查，发现是由于最大客户之一的转发代理上的DNS更改导致流量下降，最终通过联系客户解决了该问题。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(扫描工具发现问题):::process --> B(问题进入跟踪平台):::process
    B --> C(应用安全团队分类并确认是否为真阳性):::process
    C --> D{是否为真阳性}:::process
    D -->|是| E(应用安全团队配置扫描工具减少未来假阳性):::process
    D -->|否| F(忽略该发现):::process

综上所述，构建应用安全路线图需要与工程组织紧密协作，制定符合组织目标的长期计划，并通过有效的指标衡量安全项目的成效，及时调整工具和流程，以保障组织应用程序的安全。