ACM通信
Kode恶性
腌制的补丁
图片来源:Andrij Borys Associates / Shutterstock
亲爱的KV,
我最近遇到一个软件仓库，它不是代码的回购，而是补丁的回购。该项目似乎是在几个其他组件的基础上构建自己，然后使用复杂的脚本，以特定的顺序应用补丁。我必须查看这个回购文件，因为我想修复系统中的一个bug，但试图弄清楚代码在任何特定时间点的实际情况是令人困惑的。有什么工具可以帮助我们这样工作吗?我从来没有遇到过这种类型的系统，有100多个补丁，其中一些包含数千行代码。
挑一撮腌渍补丁
亲爱的泡菜,
建立这样一个系统的适当工具确实存在，但在美国的许多州，它们需要背景调查，而在世界上更发达的国家，这些工具是完全禁止的。
你所面对的是一个项目，这个项目可能应该从它所从事的项目中分出来，但是，相反，从一个补丁开始，然后是两个补丁，然后是四个补丁，直到你看到你面前的这个。当一个项目正在快速开发，并且在开始时还没有认识到它是一个重要的衍生工作时，在开发过程中可能不会很快正确地使用源代码控制工具。这需要一种原则，即预先花一些时间考虑如何将现有代码与新开发集成起来，如果这项工作没有尽早完成，那么它通常就根本无法完成。
如果您想修复系统中的一个bug，我建议您与开发人员联系，因为他们应该了解自己做了什么，以及他们做得不够好的混乱，从而能够比您能够更快地解决您的问题，而不是您能够更快地找出他们对系统做了什么。另一方面，如果您需要对正在查看的系统进行大量工作，则可能需要采取更极端的措施。
你提到你正在看的项目是一个用于另一个项目的补丁的回购。在这种情况下，你需要设定我所说的基础轨道。系统所基于的最终上游软件必须是基础层。它还需要放入源代码控制系统中，以便您从最终源代码更新基础层。基础层就绪后，应该为派生系统的每个补丁创建一个分支。您可以盲目地这样做，但这可能是最好的，尽管在此之前仔细阅读整个项目构建脚本可能相当令人沮丧。我敢打赌，您在派生项目中看到的一些补丁不是独立的，而是相互依赖，以修复一些潜在的bug或实现系统的复杂功能。一旦您将补丁收集到组中，您就可以创建补丁分支，并从派生的回购导入补丁。代码现在正确地包含在源代码控制系统中，您应该将基础层分支为它自己的开发分支。永远不要直接修改项目存储库中的基础层，因为这将使从最终上游存储库集成更改几乎不可能。 Let me say that again,从来没有直接修改项目存储库中的基础层，因为这将使从最终上游存储库集成更改几乎不可能。
对于基础层，您将始终拥有至少两个分支，原始分支只包括来自上游的更改，开发分支从原始分支获取代码并将其与补丁合并。现在，您可以将补丁集成到开发分支中，并逐个测试它们，以确保它们单独工作，然后再尝试使它们一起工作。KV经常与测试有关，但在你的情况下，它有很大的重点。除非你和你的上游供应商有密切的沟通，否则你不知道他们是如何测试这些补丁的，而不进行增量测试而全盘接受这些补丁是一种很好的方式，它最终会让你花一大笔钱，让别人把你放在沙发上，问你有关你童年的问题。
当然，你最好的办法是找到那些创造补丁的人，然后给他们这样的回应。你可能想先把它用金火刻在石碑上，但这取决于你。
KV
亲爱的KV,
许多组织可能将安全专业人员和内部开发人员之间的紧张关系制度化。在组织中，安全专业人员和内部开发人员处于不同的组织单元中，而安全专业人员对安全负有最终的责任，在这两个阵营之间的对话中，安全观点自然占据主导地位。
让我再说一遍，永远不要直接修改项目存储库中的基础层。
安全专业人员有明确的任务来保护组织，他们的工具集必须包括严格标准化的计算机设置、策略和实施机制。
内部开发人员经常需要安全策略的例外情况，因为他们的工作可能需要访问标准办公套件(例如，集成开发环境)之外的软件工具、安全测试工具(例如OWASP Zap)和/或提高的特权。此外，从事多个项目的开发人员(就像我们大多数人那样)可能需要多个虚拟机来管理多个开发项目上下文。
作为一名试图对安全性进行尽职调查的软件开发人员，当安全专业人员似乎很少关注内部软件开发人员所关心的问题时，我经常感到失望。当安全策略不灵活、有用的工具或方法不被批准、内部开发人员无法应用软件开发最佳实践时，组织不一定更安全。
我希望你能考虑用你的声音来激发关于这个话题的辩论。请考虑一篇讨论安全专业人员如何与内部开发人员合作以造福所有人的博客文章。您可以考虑讨论协调公司策略(或USGCB)的替代方法，开发人员可以对自己的代码(例如OWASP Zap)执行安全探测。
脸红心跳
亲爱的脸红心跳,
我曾经是一名内部安全专家，我现在还保留着印有我的头衔“偏执狂”的卡片。我从不保留旧的名片，但我保留了它们，因为它们是我拥有的唯一一张如此诚实的名片。我可以印制更诚实的卡片，但那样我就不能在有礼貌的公司里分发它们了。
我从来都不喜欢全面禁止任何东西，当然也不喜欢那些能帮助开发人员生成更好、更安全代码的软件。全面禁令通常来自一种被误导的信念，即交战规则可以由一小部分人来定义，如果每个人都遵守这些规则就不会出错。这种想法不仅是错误的，而且极其危险。任何有线索的安全团队都知道您制定了通用指南，然后以顾问的身份与开发团队合作，以确保这些指南具有意义。只有白痴才会创建一套既适用于开发团队又适用于会计团队的规则。唉，这个世界到处都是傻瓜，还有那些害怕未知的人。
粗略地看一下您提到的软件，并不表明它比开发人员可能使用的任何其他软件更危险，甚至包括编译器或调试器。在这些讨论中，重要的是能够提出合理的边界和保护措施，以便在使用相关软件时不会对系统造成意外损害。合理的指导方针是与工作团队一起制定的。一个好的保安团队的成员知道他们扮演的是一个辅助的角色，为了完成他们的工作，他们必须获得与他们一起工作的人的信任。
当开发人员需要做一些被认为特别危险的事情时，例如攻击他们自己的系统，在实验室环境中这样做通常是有意义的，至少一开始是这样。在公司网站上发布最新的渗透测试玩具可能很有趣，就像一些人认为观看车祸很有趣一样，但这不会提高网站的可靠性或安全性。大公司在安全团队中有专门的笔测试团队。如果有足够的资源可用，让一个小组与开发人员一起创建适当的安全测试场景，并安排它们在方便测试的时间运行，这是一个很好的解决方案。初创公司和小公司需要让他们的开发人员做这类工作，就像他们让他们做其他所有事情一样，从编码到测试和文档。廉价云计算的兴起实际上应该在这一领域有所帮助，因为服务可以被克隆、隔离和用工具“攻击”，而不会损害现有服务。对于这种类型的测试必须非常小心，因为一些云提供商可能会将您的攻击测试标记为真正的攻击并关闭您。您在信中提到了虚拟机，这是实现与云解决方案相同目的的另一种方法，通过在一个专用于安全测试的大型服务器上的虚拟网络上旋转一个虚拟机集群。
提升权限是安全团队和开发团队之间经常出现的另一个问题。
提升权限是安全团队和开发团队之间经常出现的另一个问题。基本的问题是软件系统，包括操作系统，但也延伸到数据库和其他关键软件，在设计时没有考虑到安全的想法。现在著名的XKCD漫画(https://xkcd.com/149/)关于sudo命令几乎说明了一切。大多数软件被编写为以个人用户或根用户的身份运行，个人用户通常有足够的权限运行服务，但没有足够的权限进行测试或调试。当开发人员在调试或测试时，他们希望以“root”或类似的超级用户类型的能力运行软件，因为这样“它就可以工作了”。虽然这两种级别的功能很容易理解，用户vs根用户，而且由于在最初的Unix操作系统中使用它们，它们确实支撑了许多现代计算，但它们的表现力不够。但这是另一个更长的讨论话题。
除了重写大量现有软件之外，我们还需要测试环境，将其与系统的其他部分隔离起来，或者需要特殊的命令来获得外部访问，从而为开发人员提供一个安全的沙盒来工作。
如果完成一项工作绝对需要提升的权限，那么该权限必须有一个超时。对我来说，只要开发人员与另一个人一起工作，并且他们的所有命令都被写入到一个文件中，那么给他们生产机器的根权限似乎是合理的。sudo程序实际上可以完成所有这些。我要么将超时设置为一天，要么将其设置为问题被解决的时间，以先出现的时间为准。这句话并不是我所有心甘情愿的奴隶都可以盲目采用的政策;这只是一个安全性团队和开发团队如何协作完成工作的示例。
KV
相关文章
在queue.acm.org
粉刷自行车棚
Kode恶性
http://queue.acm.org/detail.cfm?id=1557897
浏览器的安全
托马斯Wadlow
http://queue.acm.org/detail.cfm?id=1516164
修补企业
乔治Brandman
http://queue.acm.org/detail.cfm?id=1053344
数字图书馆是由计算机协会出版的。版权所有©2015 ACM股份有限公司
没有发现记录