Rogue Wave OpenLogic：一篇评论

没有人说他们不相信安全应用程序，但令人惊讶的是，许多开发人员只有在发生严重事件之后才会采取措施来保护他们的应用程序。给人的印象是，成本太高，或者有一种感觉，认为我们是无懈可击的。毕竟，我们不希望承认自己的弱点。

还记得 Heartbleed 吗？在当今时代，安全是每个人的问题。虽然这在功能上是 IT 的责任，但开发人员、QA 和发布经理也需要关注所有交付的内容。如果发生灾难性事件，他们也要承担责任。

在我们的代码中使用开源组件时，我们遇到的安全变量比其他任何地方都要多。这种担忧并不是要避免使用它们，但同时需要特别考虑，以免它们给组织带来麻烦。

技术可以分为两类：药丸或糖果。糖果是我们想购买和玩弄的新酷技术。药丸是我们避免麻烦的东西。我们都知道，吃降压药通常比吃棒棒糖更重要。对大多数人来说，安全流程和工具并不有趣，但这是我们所有人都必须服用的药丸。

让安全技术发挥作用，并让团队愿意为之付出努力的关键，在于确保它与现有工具和流程集成，并提供快速有用的指标来采取行动。

自带漏洞利用 - 开源组件

这样的工具确实存在，我最近花了一些时间研究 Rogue Wave OpenLogic 产品。他们不断给我提供酷炫的东西来玩。在我的所有测试和评估过程中，我一直在思考它如何融入现代软件交付流程。在那里，发布和测试是自动化的，并且是一个代码流，而不是分块交付。

OpenLogic 是一个“开源”组件审查工具。它会检查您的软件使用的所有组件，以确定它们是否符合您组织的治理策略，并确保您使用的软件包中没有已知漏洞。

通过使用常见的已知漏洞数据库 CVE、用于分析组件的内置数据库以及对常见开源许可证的分解，OpenLogic 具备了了解代码中发生情况的“逻辑”。我在这里将“开源”放在引号中，因为它们也允许您管理私有软件包。稍后我将解释为什么这很重要。

OpenLogic 具有基于 CVE 的有限免费增值功能。要进行全面分析，您需要购买企业版许可证。为了进行测试，我使用了爬行代理（crawl agent）来处理我的几个小型 Java 应用程序，并使用了 OpenLogic 团队提供的示例数据库。

测试 OpenLogic 很容易。一旦在他们基于云的门户（他们也提供本地部署选项）中设置了项目。要测试代码，您只需在代码所在机器上下载代理（扫描器）。假设是一个您有构建的位置。

当您运行扫描器时，它会将组件名称、版本等信息报告给您的 OpenLogic 帐户。所有这些信息都将用于将组件与策略、漏洞信息以及链接的开源依赖项进行匹配。

它还会快速告知您扫描结果。

看起来我需要仔细审查一下这个构建了……

现在，您评估所用组件安全性所需的所有数据都可以在基于 Web 的平台中找到。根据您的权限，您可以查看漏洞的风险级别，启动工作流请求批准新软件包，并查看运行历史记录。它还可以用作一个探索性工具，在实际使用之前查看外部软件包及其当前安全排名。

这是在几次代码运行和已建立策略后门户的截图。

看起来所有版本也一样。

让这个引擎工作的关键是漏洞数据库和组织的特定策略。策略告诉扫描引擎哪些组件是允许的。这可能很简单，比如“我们不希望您使用它”。或者直接就是“不行”。

漏洞数据库告诉团队哪些已使用的软件包在分析后是“一切正常”、存在风险或完全有问题。绿灯、黄灯和红灯。这不仅适用于命名软件包，也适用于使用的版本。因为很可能较新或较晚的版本是好的，而其他版本则不然。

当您开始一个新应用程序时，该平台允许您查询已批准的组件，并在原地下载它们。这可以防止通过 Google 搜索获取有害组件。这意味着开发人员所要做的就是比他们习惯的要多一些，只需注意组件的批准状态。如果未获批准，他们可以随时提交请求。

拥有所有这些有用的数据后，您就可以做出反应。这是利用 OpenLogic 等工具的要点：主动而非被动地处理安全。

该平台还允许业务用户（如开发经理或法律部门）参与策略创建和监控使用情况。这避免了 IT、开发和法律团队之间进行临时对话的需要。当然，如果您看到红色，您就会收到电子邮件。

除了用户界面，还有一个看起来相当全面的 API。一些值得注意的 REST 调用是

软件包分发。我实际上可以在发布自动化中使用此功能，在编排过程中下载已批准的软件包。需要大量的编码，但这太酷了。

GET https://olex-secure.openlogic.com/package_distributions/12086

审查和请求。我可以使用此功能查看软件包是否已批准，或请求在代码中使用。因此，这也可以是我用于发布自动化的内容，通过内联代码，我可以检查软件包是否已批准，这样我就不必担心扫描过程。或者，在首次集成构建中引入新软件包时，我可以请求使用它。这一切都是自动完成的！

GET https://olex-secure.openlogic.com/reviews/1034

API 最让我喜欢的部分是如何将此平台引入持续集成/自动化测试、编排和发布自动化。

分解

使用该平台后，我的想法是：

我喜欢的功能

• 私有软件包 - 最初我担心商业组件会被豁免，我必须使用另一个工具，或者忽略它们的策略。但事实并非如此。虽然您无法获得相同的自动化漏洞检测（这取决于组件供应商），但您可以手动添加您的商业软件包，甚至添加用于下载的位或 URL。组织可以像对其他组件一样设置策略。
• 促进共享服务 - 在大型组织中，IT 为开发人员提供服务，趋势是将其转变为服务组织，而不是实施组织。基本上，他们会在使用工具之前对其进行审核和批准。并为开发人员提供组件库。这通常称为共享服务。它有助于 IT 和开发人员的流程，同时也能改善他们之间的关系。
• 开发人员请求工作流程 - 开发人员无需再事后请求原谅，他们可以非常轻松地请求使用组件，而无需任何会议（前提是 IT 和法律部门响应迅速）。这才是关键。开发人员可以在不引起波澜或违反任何规则的情况下得到答复。
• 仪表板 - 仪表板是必需的，并且 OpenLogic 平台拥有所有我期望的预构建仪表板。但我还假设可能有一些定制的可能性，以创建独特的仪表板。
• RSS Feed - 可用的流程 RSS Feed 非常好，但一个问题是您无法仅限于漏洞。我希望我的阅读器设置能够，如果列表中有任何内容，那就是坏消息。
• 出色的支持 - 我有机会见到 Rogue Wave 的 SE 团队，他们太棒了！这是任何产品或组织中非常重要的一个功能。

他们可以改进的地方

• 总体用户体验还有很大提升空间。这包括外观和感觉。几个对我来说特别突出的是工作流程、策略创建和过滤。他们只需要更新应用程序。它给人一种老旧的感觉。术语也需要时间来适应，并且并不总是有意义的。例如，“项目”通常是一对一的应用程序，而我习惯于只考虑应用程序。
• 我有点失望，它只针对拥有 500 多名开发人员的企业。但我也认为这是用户群的错。小型组织不太关心，因此对 Rogue Wave 来说不感兴趣。但是，我确实希望有一个下游版本供所有组织利用。
• 与常用工具的开箱即用集成将是很好的。我想看到以下集成。通讯工具，如 Slack。警报工具，如 PagerDuty 和 VictorOps。日志分析工具，如 LogEntries 和 Sumo Logic。以及源代码库，如 GitHub。这些供应商可能可以自己构建。但如果它们已经存在，那将是很好的。
• 代理是一次性使用的。我不确定这是最好的，并且在我设想的流程中，拥有已注册到系统并定期或按触发扫描的静态代理将非常有用。
• API 很好，但我想要更多。例如，我希望通过 API 可以访问一些历史和业务数据。
• 全局策略可能会很快变得混乱，而本地项目策略对我来说有点令人困惑。理想情况下，我希望看到能够更好地组织全局策略，以便大多数策略可以是全局的而不是每个项目。这将避免重复和混乱。但我也明白，在大型组织中，这是范围界定和权限问题，而本地项目策略可以解决这些问题。

由于安全性的性质，无论使用什么平台，都需要做出一些组织上的考虑。

• 确保流程、工具和人员设置能够实现全面覆盖。这意味着任何代码行都不能免于扫描。关于安全，重要的是我们做得对的地方，而不是我们遗漏的地方。如果你面对法官，你必须证明你的系统有效。而不是你选择性地或偶然地忽略某些东西。
• 无论使用起来有多容易，您仍然需要计划。组织需要考虑诸如命名约定之类的事情。如果您没有正确的信息架构，并且开始填充系统数据，您最终会陷入混乱。数据无用且无法追溯修复。
• 如果您有其他代码分析系统，它们必须连接在一起。分散的系统始终会在保持一致性和管理每个系统中的资产关系方面带来挑战。
• 提前制定审计计划。如果您有法律团队，相信我，这将由他们完成。但它必须是入职流程的一部分。

总的来说，我喜欢 OpenLogic，我喜欢它的方法和使组件安全变得简单的理念。主要是因为 DevOps 中的组织不会花时间进行如此深入的安全评估，而这可能是他们的灭顶之灾。OpenLogic 工具可以完成这项工作，并且易于使用。

我的梦想环境

您认为 DevOps 环境的节奏令人恐惧吗？现在我们有了容器，风险不仅可能存在于代码中，还可能存在于容器本身。很棒的是，通过一些额外的工作，所有手动任务都可以通过发布自动化工具实现自动化。

以下是我使用 OpenLogic 的梦想环境。

OpenLogic 分析将从持续集成阶段开始，一直到发布阶段。我将使用基础设施脚本语言（如 Puppet 或 Chef）自动化扫描器的下载和运行，并将在全新的 Docker 容器实例上执行集成构建。然后，我将通过 API 使用测试工具来识别发现的任何问题，并确保在交付之前得到解决，届时将再次运行所有测试。最后，我将设置警报通知值班开发人员。这将允许在每次提交的基础上发现所有问题，并节省大量时间，而无需人工干预。

我认为 100% 的组织都需要这个工具或类似的工具。我甚至会向小型、仅限开发人员的组织推荐在他们的流程中使用此类工具。生产中的一个问题就可能让他们破产。

安全可能感觉像做家庭作业或吃药，但它不一定需要花费那么多时间。

像 OpenLogic 这样的平台不仅可以挽救每个人的工作，它还可以克服 IT 的唠叨和开发人员厌恶的缓慢——以及 IT 对开发人员组件自助服务和缺乏安全意识的恐惧。这将改善他们的关系，以及所发布软件的整体安全性和质量。