可见性很重要（你无法保护看不见的资产） 最佳实践不是银弹（适合自己的才是最好的） 叙事和有效的数据支持是项目成功的关键（Web3 讲叙事，Web2 也一样。） 应用安全建设的指标要转化为业务价值（合规是应用安全建设的商业价值体现，但不是终点。） 合法合规是底线，端到端的打穿是推进项目落地的有效抓手（比叙事更直接的是秀肌肉。） LLM 会重塑应用安全范式（唯一不变的是变化）
| 类别 | 指标 | 概述 | 示例 |
|---|---|---|---|
| 风险收敛指标 | 严重漏洞数量 | 跟踪一段时间内的严重漏洞数量，趋势下降表明高风险威胁减少。 | 每月严重漏洞数量从 20 减少到 5。 |
| 漏洞修复率 | 测量在指定时间段内修复漏洞的速率，例如每月修复率。 | 每月发现 120 个漏洞，修复 90 个，修复率为 75%。 | |
| 高风险应用百分比 | 衡量对业务功能敏感或关键的应用的百分比，优先处理高风险应用的威胁。 | 公司有 50 个关键应用，其中 30 个被评估为高风险，高风险占比 60%。 | |
| 安全债务 | 跟踪随时间积累的未解决安全问题，时间越长风险越大。（存量漏洞） | 一年来未解决的漏洞从 500 减少到 200。 | |
| 业务团队覆盖率和参与度 | 安全测试覆盖的应用百分比 | 跟踪已经过安全评审的应用比例，比例越高，覆盖潜在差距越少。 | 所有 100 个应用中，80 个经过安全测试，覆盖率为 80%。 |
| 研发人员安全培训完成率 | 衡量有多少开发人员完成安全培训，提升安全编码实践能力。 | 500 名开发人员中，350 名完成了安全编码培训课程，完成率为 70%。 | |
| 每个应用的安全检测结果 | 跟踪每个应用识别的漏洞数量，高值可能表示测试彻底，也可能表明编码实践需改进。（具体问题具体分析） | 某应用在测试中发现了 15 个漏洞，而类似项目的平均值为 8。 | |
| 平均安全参与时间（MTSI） | 衡量安全团队在开发生命周期中参与的时间，越早越能提前解决问题。 | 安全团队平均在 Sprint 1（需求阶段）介入，而不是以往的 Sprint 3（开发后期）。 | |
| 应用安全态势 | 未修复漏洞数量 | 跟踪未修复漏洞的数量，趋势线向下表明漏洞逐渐减少。 | 未修复漏洞数量从 Q1 的 300 降至 Q4 的 120。 |
| 漏洞重现率 | 衡量相同漏洞在应用中再次出现的频率，高重现率表明需改进安全实践或测试流程。 | 某种类型的 SQL 注入漏洞在半年内重现了 5 次。 | |
| 没有已知漏洞的应用百分比 | 反映组织避免漏洞的能力，高比例更好，但不排除未知威胁存在。 | 公司有 100 个应用，其中 85 个没有已知漏洞，占比 85%。 | |
| 安全漏洞修复速率 | 衡量应用安全漏洞的修复速度，速率高表明组织主动解决漏洞。 | 高危漏洞的安全漏洞平均在 5 天内完成修复，而行业标准为 14 天。 | |
| 漏洞管理效率 | 平均检测时间（MTTD） | 测量检测漏洞所需的平均时间，时间越短说明方法越高效。 | 从漏洞出现到检测的时间从平均 30 天减少到 10 天。 |
| 平均修复时间（MTTR） | 测量修复漏洞所需的平均时间，时间越短说明管理流程更高效。 | 修复一个漏洞的平均时间从 45 天减少到 15 天。 | |
| 按严重性划分的漏洞解决百分比 | 衡量根据严重性优先级解决漏洞的程度，优先处理高严重性漏洞为优化标准。 | 所有漏洞中，高严重性漏洞的修复率为 95%，中等严重性漏洞的修复率为 70%。 | |
| 误报率 | 报告的漏洞中非真实威胁的比例，高误报率表明需改进测试工具或安全流程。 | 某次扫描发现 100 个漏洞，其中 30 个为误报，误报率为 30%。 |
文章来源: https://mp.weixin.qq.com/s?__biz=Mzg5NjAxNjc5OQ==&mid=2247484013&idx=1&sn=0320e2b2fac90d0c7a892bbf9d9c6784&chksm=c006ca9df771438b7163ec710abd4afcf2a7c91d75e6508413d190f187da80d7363f7a551a62&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh
如有侵权请联系:admin#unsafe.sh