项目文章最初发表于Flux博客，作者Daniel Holbach
在我们关于Flux安全的博客系列中，接下来是我们如何在Flux及其控制器中实现模糊处理，以及如何使事情对你更安全。
Fuzzing或Fuzz测试是一种自动化的软件测试技术，包括向计算机程序提供无效、意外或随机的数据作为输入。然后监测程序的异常情况，如崩溃、内置代码断言失败或潜在的内存泄漏。通常情况下，模糊器被用来测试接受结构化输入的程序。这种结构是指定的，例如，在文件格式或协议中，并区分有效和无效的输入。一个有效的模糊器会产生半有效的输入，这些输入 "足够有效"，因为它们不会被解析器直接拒绝，但确实在程序的更深处产生了意想不到的行为，并且 "足够无效"，暴露了没有被正确处理的角落案例。
我们在整个控制器中已经有相当好的单元和端到端测试的覆盖率。将模糊测试加入到这个组合中，将进一步扩大测试的范围，使其覆盖到以前没有覆盖的场景和有效载荷。再加上已经在Kubernetes仓库中进行的模糊测试，例如kubernetes、client-go和apimachinery，我们对自己的代码更有信心。
我们很高兴地与大家分享，自从Flux的0.27版本发布以来，所有的Flux控制器和库现在都经过了谷歌对开源软件的持续模糊测试。
我们是如何做到这一点的
当我们在11月宣布安全审计的结果时，我们已经分享了ADA Logics的团队已经帮助为一些Flux控制器进行了初步的模糊测试。在这个最初的构想中，已经发现了三个问题（1个越界分片，2个零延迟），并立即进行了修复。自然，我们对合并模糊处理的集成非常感兴趣。
为了使我们能够完全登陆摸索器，我们需要对构建过程进行一些架构上的改变，特别是对于那些依赖C语言与libgit2绑定的控制器，如source-controller和image-automation-controller，它们现在是静态构建的。除此以外，我们还大大扩展了模糊器的范围。如果你看一下notification-controller的相关拉动请求，你就会对这一切有一个很好的了解，例如对所有通知器进行模糊处理。
现在，Fuzzers对每一个落入Flux控制器和库的提交都会运行。
再次感谢ADA Logics的贡献，也感谢其他帮助整合的人我们也非常感谢Google和OpenSSF，他们提供并维护了所需的基础设施。
下一步
由于Go将在1.18版本中看到内置的Fuzz支持，我们非常希望将所有的东西都紧密地按照新的格式来组织，以便从dvyukov/go-fuzz（目前正在使用）顺利地过渡。(我们可以推荐Jay Conrod的博文，关于Go的新模糊系统的内部情况，如果你很好奇的话！)
在这个问题上，我们正在跟踪Flux向原生模糊的转变。我们也希望能尽快添加新的模糊器，所以如果你想在这方面做出贡献：请到Slack上找我们！这是个很简单的方法。这是一个了解和扩展Flux代码库的简单方法。
这只是我们为保证你的安全而采取的又一项措施。
与我们交谈
我们喜欢反馈、问题和想法，所以今天请让我们知道你的个人用例。如果你有任何问题，请向我们提出，并请
- 加入我们即将举行的开发会议
- 在CNCF Slack的#flux频道中找到我们。
- 如果你还没有加入，请把你自己加为采用者。
再见!
3416
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
