我最近在使用 LLM audit musl 源码, 发现问题后手动审阅复现, 并古法编写修复. 这是第一个补丁[1] (该问题不属于安全问题的范畴). Rich 对 LLM 使用相关的回复如下,
Thank you so much for your disclosure. I don't see any problem with
what you've done here.
If you were making complex changes to code where the patch is more
elaborate, there is a question of whether that's derivative of any
LLM-suggested code you might have read. But this is a very simple
change. In the future please just disclose as you've done here. If
it's questionable we can always have someone rewrite a patch based on
an understanding of the bug you found.
换句话说, musl 维护者本人不反对这种审计方法. 但是如果修复本身过于复杂且参考了 llm 输出, 确实可能存在 copyright 上的风险. 这种情况下仍然可以通过根据问题报告由他人重新净室修复来解决.
我目前认为使用 llm 进行白盒审查开源软件是很不错的实践, 但披露 llm 的使用, 遵守漏洞披露的一般流程同时尽可能进行修复应该属于基本职业道德. 过程中也可能需要注意代码的版权问题.
[1]: https://www.openwall.com/lists/musl/2026/04/19/1
Thank you so much for your disclosure. I don't see any problem with
what you've done here.
If you were making complex changes to code where the patch is more
elaborate, there is a question of whether that's derivative of any
LLM-suggested code you might have read. But this is a very simple
change. In the future please just disclose as you've done here. If
it's questionable we can always have someone rewrite a patch based on
an understanding of the bug you found.
换句话说, musl 维护者本人不反对这种审计方法. 但是如果修复本身过于复杂且参考了 llm 输出, 确实可能存在 copyright 上的风险. 这种情况下仍然可以通过根据问题报告由他人重新净室修复来解决.
我目前认为使用 llm 进行白盒审查开源软件是很不错的实践, 但披露 llm 的使用, 遵守漏洞披露的一般流程同时尽可能进行修复应该属于基本职业道德. 过程中也可能需要注意代码的版权问题.
[1]: https://www.openwall.com/lists/musl/2026/04/19/1