Flux项目谈安全：通过Fuzzing增强信心

CNCF

发布于 2022-03-28 14:20:53

4500

发布于 2022-03-28 14:20:53

文章被收录于专栏：CNCFCNCF

Flux Security 博客系列的下一篇是我们如何在 Flux 及其控制器中实现 fuzzing（模糊测试），以及如何让项目变得更安全。

维基百科[1]是这样解释 Fuzzing 的：

Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks. Typically, fuzzers are used to test programs that take structured inputs. This structure is specified, e.g., in a file format or protocol and distinguishes valid from invalid input. An effective fuzzer generates semi-valid inputs that are "valid enough" in that they are not directly rejected by the parser, but do create unexpected behaviors deeper in the program and are "invalid enough" to expose corner cases that have not been properly dealt with.

我们已经很好地覆盖了各个控制器的单元和端到端测试。添加模糊测试将进一步扩展测试的范围到以前没有覆盖的场景和有效负载。连同 Kubernetes 库中已经完成的 fuzzing，例如 Kubernetes、client-go 和 apimachery，我们对我们的代码越来越有信心。

我们很高兴地告诉大家，自 Flux 0.27 发布以来，所有 Flux 控制器和库现在都通过谷歌的开源软件连续模糊测试[2]。

现况回顾

当我们在 11 月宣布安全审计的结果[3]时，我们已经分享了ADA Logic[4]的团队帮助为一些 Flux 控制器整合了 Fuzzing 的初始实现。在第一阶段，已经发现了三个问题（1x slice out-of-bounds，2x nil-derreference），并立即修复。当然，我们对集成 fuzzing 非常感兴趣。

为了让 fuzzer 完全运行起来，我们需要对构建过程进行一些架构上的更改，特别是对于依赖于 libgit2 的 C 绑定的控制器，例如 source-controller 和 image-automation-controller，它们现在都是静态构建的。除此之外，我们大大扩展了模糊器的使用范围。如果你看一下notification-controller 的相关 PR[5]（pull request），你就会更详细了解这些，例如 fuzzing for all notifier。

现在对于 Flux 控制器和库中的每一个提交，都会运行 fuzzer。

再次感谢 ADA logic 的贡献，以及所有帮助整合这个的人！我们也非常感谢谷歌和OpenSSF[6]提供和维护所需的基础设施。

下一步

由于 Go 将在 1.18 中内置支持 Fuzz，因此我们非常有兴趣将所有内容都紧密地构建在新格式，以便从 dvyukov/go-fuzz[7]（目前正在使用）顺利过渡。（如果你好奇的话，我们可以推荐 Jay Conrod[8] 关于 Go 的新 fuzzing 系统内部原理的博文！）

这个问题[9]跟踪关于 Flux 转向原生 fuzzing 的情况。我们也希望尽快添加新的 fuzzer，所以如果你想在那里做出贡献：来 Slack 上找我们吧！这是了解和扩展 Flux 代码库的一种简单方法。

这只是我们为确保你们的安全而采取的又一项措施。