devops 开源工具链_7个适用于坚固的DevOps的开源工具

最新推荐文章于 2024-09-27 20:15:00 发布

cumj63710

最新推荐文章于 2024-09-27 20:15:00 发布

阅读量862

点赞数

文章标签： python java 人工智能编程语言 linux

原文链接：https://opensource.com/article/18/9/open-source-tools-rugged-devops

版权

devops 开源工具链

“ 我们不能只停留在Dev and Ops。 我们必须有安全感。” - 敏捷管理者 Ernest Mueller

2010年，欧内斯特·穆勒（Ernest Mueller）和詹姆斯·维克特（James Wickett）开始在快速发展的DevOps范例中应用“坚固”原则。如上所述，当时他们的核心关注点是： “我们不能只停留在Dev and Ops。 我们必须有安全感。”

Josh Corman的RuggedSoftware中表达的观点证实了Rugged DevOps作为一种技术。坚固的DevOps愿景是一种软件工程方法，可确保在工程生命周期的所有阶段都确保代码安全。

Gauntlt是最早的开源Rugged DevOps工具之一，其流行的口号是“对您的代码刻薄并喜欢它”。 这样做的实质是软件工程师应该设法像对手那样卑鄙地对待自己的代码，而不是仅仅破坏事物，而应着重于培养强调构建更具弹性的系统的学习文化。

无论您是刚刚开始还是要改善您的连续交付实践，这里都可以考虑使用7种开源耐用的DevOps工具。

Gauntlt ：DevOps的加固框架

Gauntlt提供了各种安全工具的挂钩，并使它们可以在安全，开发人员和运营团队的支持范围内进行协作，以构建坚固的软件。这些团体之间的合作推动了Gauntlt的初步发展。对于工具而言，这听起来有些奇怪，但是Gauntlt使用了一种称为行为驱动开发 （BDD）的开发测试风格，该风格使用易于阅读的纯文本测试，这种测试在开发人员和测试人员中同样流行。

Gauntlt通过使用纯文本且易于阅读的攻击文件来实现组之间的协作。攻击文件是Gauntlt独有的，但是它们是以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."

在通读以上攻击时，您会注意到逻辑上的进展顺序取决于“给定”，“时间”和“然后”。对于此示例，您无需成为安全专家即可了解所测试的内容和预期的输出。即使您不熟悉攻击工具Arachni，您也知道应该退出并检测到“检测到0个问题”，并且其他任何输出都将失败。

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

保险柜：秘密管理

Vault是HashiCorp的一种开源工具，其设计初衷是改善软件团队在其项目中存储重要密钥，令牌，密码和其他机密的方式。 Vault是专用于机密管理的与环境和基础结构无关的开源工具集。

令人惊讶的是，Vault仍然是大多数软件开发人员解决此问题的首选工具。由于Vault具有高度可扩展性和以软件工程师为目标的性质，因此它开发了强大的开源社区，详细的面向公众的文档以及大量示例。 Vault的动态机密功能通过其API即时配置，轮换和销毁机密，大大减少了机密管理的管理开销。

如果您尚未签出保险柜，我们强烈建议您这样做。从源代码或官方容器映像启动并运行仅需几分钟。

OWASP依赖性检查：软件依赖性安全性

您的应用程序有几行代码-100？ 1000？百万？

答案取决于您如何计算应用程序代码。您仅计算已编写的代码行，还是包括继承的库？现实情况是，我们的应用程序不只是代码。它们还包括我们无法控制甚至无法编写的库和依赖项。输入OWASP的依赖性检查。

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

Retire.js ：不安全JavaScript库

安全不会在您的应用程序服务器上停止；它通过您加载的所有JavaScript一直扩展到客户的浏览器。就像OWASP Dependency Check可以告诉您的那样，JavaScript经常有不良的卫生习惯以及已知漏洞的库和框架。

那就是Retire.js的源代码。此工具评估您JavaScript库和依赖项，并标记所有已知的不良库。这是一项简单的检查，您可以在发现不良版本的jQuery或任何其他依赖项时将其添加到开发测试套件中或放入CI / CD构建系统（例如Jenkins）中，以破坏构建。

ChaoSlingr ：混沌工程

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

混沌工程技术通过有意引起故障模式来确定我们的系统，团队和技术的攻击准备程度，从而帮助团队主动解决安全漏洞。 ChaoSlingr利用AWS Lambda完全在无服务器上运行，并且开箱即用，包括示例安全性混乱实验，用于创建自己的实验的标准框架以及Slack ChatOps集成。它可以通过按代码配置进行部署。

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

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

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

OpenControl 和合规性砌体：合规性作为代码

“我如何使这一伟大的开源软件安全且合规？” -Greg Elin，GovReady

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

OpenControl是一个开源平台，用于高度自动化，用户友好的自助服务符合性评估和文档编制。借助OpenControl 和合规性砌筑，软件工程师可以专注于软件工程，而不必成为合规性专家。

在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 
     
     )