交叉审计报告 — 灵知审计独立验证
审计类型: 交叉验证 (Cross-Validation Audit) 审计日期: 2026-04-13 审计人: 灵犀 (GLM-5.1 via Crush) 基准报告:
SYSTEM_AUDIT_2026-04-09.mdby 灵知 验证方法: 独立 grep 扫描 + 配置文件直接读取
一、验证结论摘要
| 发现ID | 灵知原始数据 | 灵犀独立验证 | 判定 |
|---|---|---|---|
| C1 覆盖率 | fail_under=40%, 实际36.5% | fail_under=36%, 实际41.85% | 需修正 — 灵知报告基于旧数据 |
| C2 宽泛异常 | 378处 except Exception | 390处 except Exception | 低估12处 |
| H1 f-string SQL | 14处 | 50处 (双引号) + 1处 (单引号) = 51处匹配 | 严重低估 — 但多数为日志非SQL |
二、逐项详细验证
C1. 测试覆盖率阈值
灵知报告: fail_under=40%, 实际覆盖率约36.5%
灵犀验证:
- pytest.ini 中 fail_under = 36 (灵知T1已修复: 40→36)
- coverage.json 实际覆盖率: 41.85%
- 灵知报告中声称36.5%是基于修复前的数据，已过时
判定: 灵知的T1修复（fail_under 40→36）已生效。但实际覆盖率已升至41.85%，比报告时改善了5个百分点。宪章要求80%/70%/60%仍严重偏离，但趋势向好。
灵犀建议: fail_under应从36提升到41（当前实际值），防止回退。
C2. 宽泛异常捕获
灵知报告: 378处 except Exception
灵犀验证:
超出灵知报告12处。原因可能是灵知审计时代码库有变动，或灵知使用了更窄的搜索范围。
进一步分析:
- 带 as e / as err / as exc 的（有日志捕获）: ~370处
- 裸 except Exception: 无变量绑定的: ~20处（更危险）
- 其中含 pass 的: 0处（grep无结果，说明没有最恶劣的 except Exception: pass 模式）
判定: 灵知低估了12处。但好消息是没有 except Exception: pass 模式。大部分已有 as e 和日志记录。实际风险低于灵知评估。
灵犀补充: 灵知报告中声称约50处 except Exception: pass 需P0修复，但实际grep结果为0。这是一个事实性错误——不存在裸pass模式。
H1. f-string SQL 查询
灵知报告: 14处
灵犀验证:
grep -rn 'f"' backend/ --include="*.py" | grep -i "select\|insert\|update\|delete\|WHERE"
→ 50处 (双引号f-string)
grep -rn "f'" backend/ --include="*.py" | grep -i "select\|insert\|update\|delete\|WHERE"
→ 1处 (单引号f-string)
→ 总计: 51处匹配
但需要重要修正: 51处匹配中大量是日志语句而非SQL注入风险。例如:
- logger.info(f"Found {len(updates)} updates from GitHub") — 包含"update"关键字但不是SQL
- logger.debug(f"Entity insert error: {e}") — 包含"insert"但不是SQL
实际SQL注入风险点（逐条核实）:
1. audio_service.py:408,411 — WHERE条件拼接 + COUNT(*) ✓ 确认
2. lingflow_book_search.py:116 — WHERE条件拼接 ✓ 确认
3. secure_search.py:306 — COUNT子查询 ✓ 确认
4. lingmessage/service.py:136,138 — WHERE + COUNT ✓ 确认
5. bm25.py:71 — LIMIT拼接 ✓ 确认（但LIMIT是内部常量，非用户输入）
6. extractor.py:368 — WHERE条件 ✓ 确认
7. intelligence/service.py:153,156 — WHERE + COUNT ✓ 确认
8. domains/mixins.py:51 — SELECT拼接 ✓ 确认
9. db_helpers.py:185 — COUNT子查询 ✓ 确认（通用工具函数）
10. api/v1/lifecycle.py:388,435 — SELECT/UPDATE ✓ 需核实
11. api/v1/sysbooks.py:70 — COUNT ✓ 需核实
判定: 灵知的14处数字基本准确（针对真正的SQL构建代码）。我用的grep模式过宽导致51处匹配，但其中多数是日志误匹配。实际SQL注入风险点与灵知报告一致，约14处。
灵犀补充: 这些f-string SQL多数是WHERE条件拼接，且值通过 $N 参数化传入，直接注入风险有限。但 bm25.py:71 的 LIMIT 拼接使用了内部常量 self._MAX_INIT_DOCS，虽然是安全的，但不符合宪章规范。
三、灵知报告未覆盖的发现
N1. evolution模块集中风险
services/evolution/ 是宽泛异常最密集的模块（~30处），且包含AI调用、缓存、限流等关键路径。该模块的异常处理质量直接影响系统稳定性，建议优先处理。
N2. 缺少类型注解检查
灵知未验证 §2 代码规范中"类型注解"的要求。快速抽检显示部分模块缺少返回类型注解。
四、综合裁定
| 维度 | 灵知评分 | 灵犀评估 | 差异说明 |
|---|---|---|---|
| 安全规范 §7 | 7/10 | 7.5/10 | SQL风险可控，实际注入面比报告暗示的小 |
| 测试规范 §5 | 5/10 | 5.5/10 | 覆盖率已升至41.85%，趋势向好 |
| 代码规范 §2 | 6/10 | 5.5/10 | 390处宽泛异常比灵知报告多12处，但没有pass裸异常 |
| 数据库规范 §6 | 8/10 | 7.5/10 | f-string SQL约14处确认 |
综合: 7.0/10 → 灵犀评估: 6.5/10
灵知报告整体质量高，发现准确。主要修正: 1. C1数据已过时（覆盖率已升到41.85%） 2. C2低估12处（390 vs 378），但不存在裸pass模式（比灵知评估乐观） 3. H1的14处数字准确（我的51处匹配含日志误匹配）
交叉审计完成时间: 2026-04-13 审计人: 灵犀 (LingXi) — 灵族十二子之四