coverage-analysis

coverage-analysis 技能概览

coverage-analysis 技能可以帮助你衡量 fuzzing harness 实际执行了哪些代码，从而判断覆盖率偏低到底是因为 harness 太弱、解析器太难推进，还是遇到了诸如 magic value 检查这类真正的阻塞点。它最适合安全工程师、fuzzing 实践者，以及在 Security Audit 的 coverage-analysis 工作中做审查的人——在这些场景里，“这个 harness 能不能跑到高风险代码”比原始执行量更重要。

这个技能适合做什么

当你需要比较不同版本的 harness、找出死路径，或者判断 fuzzer 是否真的在取得有意义的进展时，就该用 coverage-analysis 技能。它是用来辅助判断 harness 质量的，不是通用的代码质量检查器。

什么时候最适合用

当你已经有目标二进制、语料库，或者 fuzzing 环境，并且想从 coverage 报告里获得证据时，它最适合。若你只是想快速凭经验看一眼，普通 prompt 可能就够了；但如果你需要可重复的 coverage 解读，这个技能会提供更清晰的结构。

它的不同之处

它的核心价值在于聚焦：coverage-analysis 关注把 coverage 解释为一种信号，识别阻塞点，并利用这个信号去改进 harness。相比之下，直接让通用模型“分析 coverage”但不给工作流或判断标准，通常没有这么实用。

如何使用 coverage-analysis 技能

先正确安装 coverage-analysis

如果是 GitHub 托管的 skill pack，请使用你的 skills runner 期望的安装方式，例如 npx skills add trailofbits/skills --skill coverage-analysis。安装完成后，在开始写 prompt 之前，先确认这个技能已经在你的 agent 环境中可用。

先读对文件

先看 SKILL.md 里的工作流和适用范围，再检查你的环境暴露出来的任何关联仓库说明。对这个技能来说，最重要的信息通常就在主说明和示例里，所以在自己发明 coverage 流程之前，先把这些内容读完。

给模型足够的 coverage 上下文

一个高质量的 coverage-analysis 使用 prompt，应该包含目标、测量方法，以及你要做的决策。例如：“分析我这个 libpng fuzz harness 的 coverage，使用 LLVM sancov，对比 corpus A 和 corpus B；识别哪些变更扩大了可达代码，哪些剩余分支看起来像 magic-value 阻塞。”这比简单说“看看这个 coverage 报告”更好，因为它明确说明了系统、指标和预期结果。

用工作流，不要只问一次

实用的 coverage-analysis 指南，是把问题分阶段提出：先总结当前 coverage 状况，再识别阻塞点，然后建议如何改 harness，最后把下一轮结果和基线比较。这样输出会始终贴近行动，而这正是 fuzzing 过程中做 coverage analysis 的意义所在。

coverage-analysis 技能常见问题

coverage-analysis 只适用于 fuzzing 吗？

大体上是的。这个技能面向的是 fuzzing harness 的有效性和进展追踪，而不是通用的源代码审查。如果你并不是在用 coverage 去改进 fuzz target 或安全测试 harness，那它的适配度就会弱很多。

它和普通 prompt 有什么区别？

普通 prompt 也许能描述 coverage 数字，但 coverage-analysis 技能会给你一套更紧的工作流，帮助你结合 fuzzing 场景来解读这些数字。当你需要区分“harness 有问题”和“代码路径本来就很难到达”时，这一点尤其重要。

使用它需要专家水平吗？

不需要，但你至少要能说清目标、harness，以及 coverage 数据来源。对新手来说，最好的结果通常来自一份报告、一个基线、一个具体问题。

什么时候不该用它？

如果你没有可执行目标、没有 coverage 数据，或者根本没有改进 fuzzing 环境的意图，就不要用 coverage-analysis。因为在这些情况下，信号太少，技能很难给出可靠建议。

如何改进 coverage-analysis 技能

从基线和差值开始

最好的 coverage-analysis 输出，通常来自对比：修改 harness 前后、corpus A 对 corpus B，或者当前运行对比上一次稳定运行。如果你只提供单份报告，可以让模型指出缺失的上下文，并告诉你哪种对比会让结论更有说服力。

把你怀疑的阻塞点说出来

如果你已经怀疑是 checksum、格式检查、认证门禁，或者 magic constant，就直接说出来。这样模型就有了重点排查方向，也更容易区分“coverage 真停滞了”还是“这里本来就有一道刻意的门槛”。

提供准确的 coverage 来源

告诉模型数据来自 LLVM source-based coverage、SanitizerCoverage、gcov，还是其他采集器，并附上相关路径或报告片段。coverage-analysis 只有在结果能明确对应到测量系统时，才真正有用，而不只是几个百分比数字。

优化 harness 变更，不只是看报告

把第一次回答当作诊断结果。然后重新跑 harness，收集新的 coverage 报告，再问哪些地方发生了变化、哪些问题仍然阻碍进展。正是这个反馈闭环，让 coverage-analysis 技能在 Security Audit 工作流里真正发挥价值。