腌制补丁

关于补丁仓库以及安全专业人员和内部开发人员之间的紧张关系

George Neville-Neil

亲爱的 KV，
我最近遇到了一个软件仓库，它不是代码仓库，而是补丁仓库。该项目似乎是由几个其他组件构建而成，然后使用复杂的脚本按特定顺序应用补丁。我不得不查看这个仓库，因为我想修复系统中的一个错误，但是试图弄清楚在任何特定时间点代码的实际样子都令人困惑。有没有工具可以帮助像这样工作？我以前从未遇到过这种类型的系统，其中有超过一百个补丁，其中一些补丁包含数千行代码。

一堆腌制补丁

亲爱的腌制，

适用于此类系统的工具确实存在，但在美国许多州，它们需要进行背景调查，并在世界上更发达的国家被彻底禁止。

你现在面对的是一个项目，它可能应该 fork 它正在使用的项目，但实际上，它从一个补丁开始，然后是两个补丁，然后是四个补丁，直到你看到你面前的东西。当一个项目快速开发并且没有一开始就意识到它是一个重要的衍生作品时，源代码控制工具的正确使用可能不会在开发过程中尽早发生。这需要自律，花一些前期时间思考如何将现有代码与新开发集成，如果这项工作没有尽早完成，通常就根本不会完成。

如果你想修复系统中的单个错误，我建议你联系开发人员，因为他们应该足够了解他们所做的事情——以及他们所处的混乱状态——以便能够比你更快地解决你的问题，而不是你自己整理他们对系统所做的事情。另一方面，如果你需要对你正在查看的系统进行大量工作，你可能不得不采取更极端的措施。

你提到你正在查看的项目是一个补丁仓库，用于另一个项目。既然如此，你需要奠定我将称之为基础轨道的东西。系统所基于的最终上游软件必须是基础层。它还需要放入一个源代码控制系统，该系统允许你从最终来源更新该基础层。在基础层就位后，你应该从衍生系统中为每个补丁创建一个分支。你可以盲目地执行此操作，但最好——尽管可能非常令人沮丧——事先仔细阅读项目构建脚本。我敢打赌，你在衍生项目中看到的一些补丁不是独立的，而是相互依赖的，以修复一些潜在的错误或实现系统的复杂功能。一旦你将补丁收集到组中，你就可以创建补丁分支并从衍生仓库导入补丁。现在代码已正确包含在源代码控制系统中，你应该将基础层分支到其自己的开发分支中。永远不要直接修改项目仓库中的基础层，因为这将使从最终上游仓库集成更改几乎不可能。让我再说一遍，永远不要直接修改项目仓库中的基础层，因为这将使从最终上游仓库集成更改几乎不可能。

对于基础层，你将始终至少有两个分支，即仅包含来自上游更改的 pristine 分支，以及从 pristine 分支获取代码并将其与补丁合并的开发分支。你现在可以将补丁集成到开发分支中，并逐个测试它们，以确保它们单独工作，然后再尝试使它们全部协同工作。KV 经常谈论测试，但在你的情况下，这非常重要。除非你与你的上游提供商保持密切沟通，否则你不知道他们是如何测试这些补丁的，并且在没有增量测试的情况下全盘接受它们是最终会花很多钱请某人让你躺在沙发上并询问你童年的好方法。

当然，你最好的选择是找到创建补丁的人，然后给他们这个回复。你可能想先用金色的火焰将其刻在石碑上，但这取决于你。

亲爱的 KV，
许多组织可能正在使安全专业人员和内部开发人员之间的紧张关系制度化。在安全专业人员和内部开发人员位于不同组织单元，并且安全专业人员对安全负有最终责任的组织中，安全视角自然会主导这两个阵营之间的对话。

安全专业人员有明确的任务来保护组织，他们的工具集必然包括严格标准化的计算机设置和策略以及执行机制。

内部开发人员经常需要安全策略的例外，因为他们的工作可能需要访问标准办公套件（例如，集成开发环境）、安全测试工具（例如 OWASP Zap）和/或提升的权限中排除的软件工具。此外，从事多个项目（像我们大多数人一样）的开发人员可能需要多个虚拟机，以便管理多个开发项目上下文。

作为一名尽职尽责地考虑安全性的软件开发人员，当安全专业人员似乎很少关注内部软件开发人员的担忧时，我常常感到失望。当安全策略不灵活、有用的工具或方法被否定，并且内部开发人员无法应用软件开发最佳实践时，组织不一定更安全。

我希望你考虑用你的声音来激发关于这个话题的辩论。请考虑撰写一篇博客文章，讨论安全专业人员如何与内部开发人员协作，以使所有人受益。你可以考虑讨论替代方法，以协调公司政策（或 USGCB）与开发人员对其自身代码执行安全探测（例如使用 OWASP Zap）之间的关系。

Zapped

亲爱的 Zapped，
很久以前，我也是那些内部安全专业人员之一，我仍然有卡片，上面印着我的头衔“Paranoid”（偏执狂）。我从不保留旧名片，但我保留了那些，因为它们是我拥有的唯一诚实的名片。我可以印更诚实的卡片，但那样我就不能在礼貌的场合发给别人了。

我从来都不喜欢一概而论的禁令，好吧，几乎任何事情都不喜欢，当然也不喜欢那些可以帮助开发人员编写更好、更安全代码的软件。一概而论的禁令通常来自一种错误的信念，即交战规则可以由一个小团体定义，如果每个人都遵守这些规则，那么就不会出错。这种信念不仅是错误的，而且极其危险。任何有头脑的安全团队都知道，你需要制定一般准则，然后在咨询的角色中与开发团队合作，以确保这些准则有意义。只有白痴才会制定一套适用于开发团队和会计团队的规则。唉，世界上既有白痴，也有那些只是害怕未知事物的人。

粗略地看一下你提到的软件，并没有显示它比开发人员可能使用的任何其他软件（包括编译器或调试器）更危险。在所有这些讨论中，重要的是要有能力提出合理的边界和保障措施，以便在不意外损坏系统的情况下使用相关软件。合理的准则是在与执行工作的团队协商一致的情况下制定的。一个好的安全团队知道他们正在扮演支持角色，并且他们必须获得与他们合作的人的信任才能完成他们的工作。

当开发人员需要做一些被认为特别危险的事情时，例如攻击他们自己的系统，通常在实验室环境中执行此操作是有意义的，至少在最初是这样。在公司网站上释放最新的渗透测试玩具可能很有趣，就像观看车祸很有趣一样，但这并不能提高网站的可靠性或安全性。大型公司有专门的渗透测试团队——通常在安全团队内部。如果资源充足，那么拥有一个小团队可以与开发人员合作创建合适的安全测试场景并安排他们在方便测试的时间运行是一个很好的解决方案。初创公司和小型公司将需要他们的开发人员来完成这类工作，就像他们让他们完成从编码到测试和文档的所有其他工作一样。廉价云计算的兴起实际上应该有助于这方面，因为服务可以被克隆、隔离，并使用工具“攻击”，而不会损害活动服务。在这种类型的测试中必须小心，因为一些云提供商可能会将你的攻击测试标记为真正的攻击并关闭你。你在信中提到了虚拟机，这是实现与云解决方案相同目的的另一种方法，即通过在一个专用于安全测试的大型服务器上的虚拟网络上启动虚拟机集群。

关于提升权限的案例是安全团队和开发团队之间经常出现的另一个问题。基本问题是，包括操作系统在内的软件系统，以及扩展到数据库和其他关键软件，在设计时并没有考虑到安全性。现在著名的 XKCD 漫画（https://xkcd.com/149/）关于 sudo 命令的内容几乎说明了一切。大多数软件被编写为以个人用户身份运行，个人用户通常具有足够的权限来运行服务，但没有足够的权限来测试或调试它，或者以 root 身份运行。当开发人员进行调试或测试时，他们希望以“root”身份或使用类似的超级用户类型权限运行软件，因为这样“它就可以正常工作”。虽然这两个级别的权限很容易理解，即用户与 root，并且由于它们在原始 Unix 操作系统中的使用，它们确实支撑了许多现代计算，但它们的表达能力不足。但这又是另一个更长的讨论的话题。

在不重写大量现有软件的情况下，我们最终需要测试环境，与系统的大部分其他部分隔离，或者需要特殊命令才能获得外部访问权限，以便为开发人员提供一个安全的工作沙箱。

如果绝对需要提升的权限才能完成工作，则该权限必须具有超时时间。对我来说，只要开发人员与另一个人一起工作，并且他们的所有命令都写入文件中，那么在生产环境中为开发人员提供 root 权限似乎是合理的。sudo 程序实际上可以做到所有这些。我会将超时时间设置为一天或问题得到解决时，以先到者为准。该声明并非旨在成为一项被我所有愿意效劳的人盲目采纳的政策；这只是安全团队和开发团队如何协同工作以完成工作的示例。

Kode Vicious，凡人称之为 George V. Neville-Neil，从事网络和操作系统代码的工作，以娱乐和盈利为目的。他还教授与编程相关的各种主题的课程。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。George 是 Marshall Kirk McKusick 和 Robert N. M. Watson 合着的 The Design and Implementation of the FreeBSD Operating System 一书的共同作者。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于 Queue 第 13 卷，第 8 期—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求，存在许多针对加密哈希的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者们试图在财政紧缩和人工智能等变革性技术的背景下优化软件交付。直观地，技术领导者普遍认为，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的提议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而提供关于该主题的新见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，在这个世界中，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在它匆忙地向前发展时，它会受到时尚潮流的影响，并且可能会忘记或忽略已证实的解决方案，以解决它所面临的一些永恒问题。用例，于 1986 年首次引入并在后来普及，就是这些已证实的解决方案之一。