为什么 87% 的安全发现从未得到修复（以及我们是如何解决的）

发布: 1周前 (2025年12月17日 GMT+8 22:59)

6 min read

原文: Dev.to

Source: Dev.to

您的安全扫描器刚刚标记了 847 条发现。您的开发人员将恰好修复 12 条。
下周，扫描器发现 913 条问题。您的团队修复 8 条。循环重复。

这不是懒惰。这不是疏忽。这是破碎系统的可预见结果。

为什么开发者忽视安全发现

在分析了 20,000+ 拉取请求 并采访了数百名开发者后，我们发现了三个一致的模式：

1. 上下文缺口

安全扫描器告诉你什么是错误的，但很少告诉你 在哪里 重要，或如何在实际代码库中修复它。看到 “检测到 SQL 注入漏洞” 的开发者需要了解：

哪个具体查询存在漏洞
哪些用户输入可能到达该查询
如何在不破坏现有功能的前提下修复
该修复是否能通过代码审查

2. 误报税

当 60‑80 % 的发现是误报或与上下文无关时，开发者会学会忽视所有发现。这是对不合理信噪比的理性反应。

3. 摩擦问题

即使开发者想要修复问题，最省力的做法是：

标记为 “不修复”
加入待办列表（在那里被搁置）
创建工单（无人优先处理）

实际的修复需要切换上下文、调研、测试和审查。大多数安全发现并不够紧急，无法证明这种认知负荷是合理的。

Source: …

基于证据的方法

我们构建了一个不同的系统。我们不仅仅是标记问题，而是：

1. 生成实际修复

我们的修复引擎会分析你的代码库，并生成可直接合并的 Pull Request，内容包括：

与代码风格相匹配的上下文感知修复
防止回归的自动化测试
解释漏洞及修复方案的文档

2. 置信度评分

并非所有发现都同等重要。我们根据以下维度为每个发现打分：

可达性 – 不可信输入真的能到达这段代码吗？
可利用性 – 这只是理论上的漏洞，还是实际可被利用？
影响范围 – 若被利用，后果有多严重？
修复质量 – 对生成的修复我们有多大信心？

只有高置信度的发现会生成 Pull Request。其余的会提供解释，但不会自动化处理。

3. 开发者优先的设计

修复工作融入开发者已有的工作流：

# 之前：仪表盘中的安全发现
Finding ID: SEC-4721
Severity: HIGH
File: api/auth.py
Issue: Hardcoded secret detected

# 之后：收件箱中的 Pull Request
PR #842: Remove hardcoded API key from auth module
✅ Fix verified
✅ Tests passing
✅ Zero‑trust secret management configured
📚 Learn more: [Why hardcoded secrets are dangerous]

实际结果

在我们向首批 50 位设计合作伙伴 部署后：

87 % → 94 % 的高置信度发现修复率
3 天 → 4 小时 的平均修复时间
降低 60 % 的误报噪声
无需额外会议 或流程变更

The Code: Evolutionary Remediation Engine

我们已开源整个系统。它包括：

Template Engine

根据漏洞模式生成特定语言的修复方案。

# Example: SQL injection fix template
template = RemediationTemplate(
    vulnerability="sql_injection",
    language="python",
    fix_strategy="parameterized_query",
    confidence_threshold=0.85,
)

Evidence Analyzer

基于多种信号对发现进行评分。

scorer = ConfidenceScorer()
score = scorer.evaluate(
    reachability=reachability_analysis(code),
    exploitability=exploit_complexity(vuln),
    impact=blast_radius(code_context),
    fix_quality=test_coverage(generated_fix),
)

PR Generator

创建可直接合并的拉取请求。

pr = PRGenerator(
    finding=security_finding,
    fix=generated_fix,
    tests=automated_tests,
    docs=vulnerability_explanation,
)
pr.create(repo="your-org/your-repo")

亲自尝试

🔗 GitHub:

快速开始

git clone https://github.com/AuraquanTech/evolutionary-remediation-engine
cd evolutionary-remediation-engine
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# Run analysis
python analyze.py --repo /path/to/your/repo

# Generate fixes
python remediate.py --findings findings.json --create-pr

设计合作伙伴可永久免费获取高级功能

我们正在寻找 100 位设计合作伙伴 来帮助我们：

在真实代码库上测试引擎
提供关于修复质量的反馈
帮助确定语言/框架支持的优先级

作为回报：

永久免费使用高级功能（绝不诱导消费）
直接对接我们的工程团队
将您的使用场景列入路线图优先级
如有需要，可提供联合营销机会

感兴趣吗？ 请留言或直接联系我们。

结论

安全发现之所以没有被修复，是因为系统针对检测而非修复进行优化。我们构建了一个相反方向优化的系统：让修复变得如此简单，以至于忽视它们比合并它们需要更多的工作量。

代码是开源的。方法基于证据。结果不言自明。

您在安全修复方面面临的最大挑战是什么？

修复安全发现的最大障碍是什么？
让我们在评论中讨论。