7 个用于增强型 DevOps 的开源工具

使用这些工具将安全测试构建到软件开发过程中。
418 位读者喜欢这个。
Through the looking glass: Security and the SRE

Opensource.com

我们不能只停留在 Dev 和 Ops 上。 我们必须要有安全性。” - Ernest Mueller, 敏捷管理员

2010 年,Ernest Mueller 和 James Wickett 开始将“增强型”原则应用于快速发展的 DevOps 范例。 当时,他们的核心关注点正如上面所说:“我们不能只停留在 Dev 和 Ops 上。 我们必须要有安全性。”

增强型 DevOps 是一种技术,源于 Josh Corman 在 RuggedSoftware 中表达的观点。 增强型 DevOps 的愿景是一种软件工程方法,可确保代码在工程生命周期的所有阶段都是安全的。

Gauntlt(第一个开源增强型 DevOps 工具之一)的流行标语是“对你的代码苛刻一点,并喜欢它。” 其本质是软件工程师应该像对手一样对他们的代码苛刻,并且不要只是破坏东西,而是专注于培养一种强调构建更具弹性的系统的学习文化。

无论您是刚刚开始还是希望改进您的持续交付实践,以下是 7 种值得考虑的开源增强型 DevOps 工具。

Gauntlt:DevOps 的增强框架

Gauntlt 提供到各种安全工具的钩子,并将它们置于安全、开发和运营团队的触手可及范围内,以协作构建增强型软件。正是这些团队之间的协作推动了 Gauntlt 的最初开发。 对于一个工具来说,这听起来可能很奇怪,但 Gauntlt 使用了一种称为行为驱动开发 (BDD) 的开发测试风格,它使用易于阅读的纯文本测试,这些测试在开发人员和测试人员中都很受欢迎。

Gauntlt 通过使用纯文本且易于阅读的攻击文件来实现团队之间的协作。 攻击文件是 Gauntlt 独有的,但它们是用 Gherkin 编写的,Gherkin 是一种 BDD 测试人员非常熟悉的语言和风格。

这是一个 Gauntlt 中的简单攻击文件

Feature: Look for cross site scripting (xss) using arachni against our site
Background:
 Given "arachni" is installed
 And the following profile:
   | name    | value                    |
   | url    | http://localhost:8008/login |
 
Scenario: Do a full xss check and verify no issues are found on the login page
 When I launch an "arachni" attack with:
 """
 arachni --checks=xss* --scope-page-limit=1 <url>
 """
 Then the output should contain "0 issues were detected."

当您阅读上面的攻击时,您会注意到一个逻辑的进展顺序,该顺序取决于 Given、When 和 Then。 对于这个例子,您不需要成为安全专家就能理解正在测试的内容和预期的输出。 即使您不熟悉攻击工具 Arachni,您也知道测试应该以“未检测到任何问题”退出,并且任何其他输出都将失败。

为了更深入地了解 Gauntlt,James Wickett 编写了一门名为“DevSecOps:自动化安全测试”的课程,可在 LinkedIn Learning 和 Lynda.com 上获得。

Vault:密钥管理

Vault,HashiCorp 的一个开源工具,其构思的目的是为了改进软件团队如何在他们的项目中存储重要的密钥、令牌、密码和其他机密。 Vault 是一种环境和基础设施无关的开源工具集,专门用于密钥管理。

令人惊讶的是,Vault 仍然是大多数软件开发人员解决此问题的首选工具。 由于 Vault 的高度可扩展性和针对软件工程师的特性,它已经开发了一个强大的开源社区、详细的面向公众的文档和大量的示例。 Vault 的动态密钥功能通过其 API 即时配置、轮换和销毁密钥,从而显着降低了密钥管理的管理开销。

如果您还没有查看 Vault,我们强烈建议您这样做。 只需几分钟即可从 或官方容器映像启动并运行它。

OWASP Dependency Check:软件依赖项安全性

您的应用程序有多少行代码?—100? 1,000? 1 百万?

答案取决于您如何计算您的应用程序代码。 您是否只计算您编写的代码行,或者您是否包括您继承的库? 现实情况是,我们的应用程序不仅仅是我们的代码; 它们还包括我们无法控制甚至没有参与编写的库和依赖项。 输入 OWASP 的 Dependency Check。

OWASP Dependency Check 检查您的源代码中是否存在任何已知的、公开披露的漏洞。 它目前支持 Java 和 .NET,并对 Ruby、Node.js 等语言提供一些实验性支持。 设置它很容易,并且它可以插入您选择的 CI/CD 构建系统

Retire.js:不安全的 JavaScript 库

安全性不会止步于您的应用程序服务器; 它一直延伸到您客户的浏览器,以及您友好加载的所有 JavaScript。 正如 OWASP Dependency Check 可以告诉您的那样,JavaScript 经常存在不良卫生习惯以及具有已知漏洞的库和框架。

这就是 Retire.js 的用武之地。 此工具评估您的 JavaScript 库和依赖项,并标记任何已知的坏库和依赖项。 这是一个简单的检查,您可以添加到您的开发测试套件或放入您的 CI/CD 构建系统(例如,Jenkins)中,以便在发现 jQuery 或任何其他依赖项的错误版本时中断构建。

ChaoSlingr:混沌工程

ChaoSlingr 利用混沌工程的力量,通过故障注入过程主动发现网络安全工具、技术和响应程序中的系统性弱点。 使用 ChaoSlingr,您可以根据您或您的团队遇到的独特观察结果创建自己的安全混沌实验。

混沌工程通过有意导致故障模式来帮助团队主动解决安全漏洞,以确定我们的系统、团队和技术在多大程度上做好了攻击准备。 ChaoSlingr 完全以无服务器方式运行,利用 AWS Lambda,并且开箱即用地提供示例安全混沌实验、用于创建您自己的实验的标准框架和 Slack ChatOps 集成。 它是通过配置即代码进行部署的。

InSpec:安全配置和合规性验证

InSpec,Chef 的一个开源工具集,提供了一个基础设施测试框架,该框架具有人类和机器可读的语言,用于指定合规性、安全性和策略要求。 此外,它可以用于测试和审核您的环境中的应用程序、基础设施和许多其他技术,以确保在整个构建过程中保持一致的配置标准。

InSpec 将您的系统的实际状态与您在易于阅读和易于编写的 InSpec 代码中表达的所需状态进行比较。 InSpec 检测违规行为,并以报告的形式显示调查结果,使您可以控制补救措施。 它提供了一些很好的方法来提高速度、质量和安全性,方法是创建自动配置验证测试,以验证您的构建是否始终如一地满足您设置的基线。 此外,InSpec 报告可以用作审计和评估团队的合规性工件,以减少发布周期中的摩擦。

OpenControlCompliance Masonry:合规性即代码

“我如何使这款出色的开源软件安全且合规?” - Greg Elin, GovReady

事实是,今天的网络合规性流程没有扩展。 维护书面文档对于现代系统工程的持续开发和交付性质来说太慢了。 我们的合规性需要跟上开源、云、敏捷和 DevOps 的速度。

OpenControl 是一个开源平台,用于高度自动化、用户友好的自助式合规性评估和文档编制。 使用 OpenControl 和 Compliance Masonry,软件工程师可以专注于软件工程,而不是成为合规性专家。

在 OpenControl 框架内,软件工程师可以轻松地表示应用程序或组织策略的各个部分,这些部分以简单的基于 YAML 的描述的形式处理特定的安全要求文档。

示例 OpenControl YAML 定义

documentation_complete: false
name: AWS Implementation
schema_version: 3.0.0
references:
- name: SC Policy
 path: https://github.com/opencontrol/freedonia-aws-compliance/wiki/Security-Controls
 type: URL
satisfies:
- control_key: AU-2
 standard_key: NIST-800-53
 covered_by: []
 implementation_status: none
 narrative:
  - text: |
  	AU-2 - Audit Events
  	All AWS events are sent to AWS CloudWatch.
  	This is implemented with our Terraform build using the
    `aws_cloudtrail` resource (https://www.terraform.io/docs/providers/aws/r/cloudtrail.html)

合规性 Masonry 文档是使用 OpenControl Schema 构建的,OpenControl Schema 是一种用于存储合规性文档的机器可读格式。 它通过提供以下方式简化了认证文档编制过程:

  • 用于存储认证(例如,FISMA)、标准(例如,NIST-800-53)和各个系统组件(例如,AWS-EC2)的数据存储

  • 一种供安全团队编辑现有文件并为其应用程序和组织添加新控制文件的方式

  • 用于生成清晰且标准化的认证文档的管道

多年来,合规性限制了工程团队将速度驱动到其软件交付实践中的能力。 是时候改变这种做法了。 OpenControl 允许软件工程师编写优秀的软件,而无需进行繁琐的合规性文档编制,同时为审计员提供最新的、相关的且易于使用的合规性工件。

有很多机会可以在整个 CI/CD 管道中添加安全测试。 这种方法体现了左移的智慧——将安全测试移近开发。 采用所有这些工具可能令人生畏,因此我们建议您从小处着手,进行成功的、可重复的安全测试,而不是尝试做所有事情。

如果您准备好做出改变,请尝试使用这些工具。 即使您只实施一个或两个,我们保证它也会产生很大的影响,并且可能会改变您的组织对安全性的看法。 一个好的起点是 Gauntlt。 本文的作者是该项目的核心贡献者,并希望您能 加入我们在其 Slack 社区

接下来要阅读的内容
User profile image.
DevSecOps,Security+Chaos Engineering=ChaoSlingr,企业家,RuggedSoftware,创新催化剂 @UnitedHealthGrp 🤠
James Wicket photo
James 花费大量时间在 DevOps 和安全社区的交汇处。 他在 Signal Sciences 担任研究主管,并且是 Rugged Software 和 Rugged DevOps 运动的支持者。 看到软件测试方面的差距,James 创立了一个开源项目 Gauntlt,作为 Rugged 测试框架。

1 条评论

gauntlt 示例中存在一个相当糟糕的逻辑缺陷,原因是缺少一个空格。 示例
那么输出应该包含“0 issues were detected.”
实际上应该是
那么输出应该包含“ 0 issues were detected.”

在 0 之前和之后都应该有一个空格。 否则,当检测到 10 的倍数的问题时,测试将通过。

© . All rights reserved.