devops 开源_保护开源DevOps的3个步骤

devops 开源

没人真正写自己的代码了，对吧？ 我们到GitHub，下载一些库，避免重新创建不必要的轮子，并将这些轮子与我们自己的胶水打包在一起以创建新软件。 然后，我们下载了六个前端框架，以使其外观漂亮且响应Swift，因此我们不参加比赛。 在对公司和其他公司的应用程序进行的审查中，我发现如今构成应用程序的代码中有90％以上是我们借用的，而不是自己编写的。

我们大多数人都使用静态分析工具扫描自己的代码中是否存在缺陷，但是我们没有写的所有东西呢？ 我们如何知道实际存在的东西？ 找到其中的内容后，您将采取什么措施对其进行清理或保持新鲜？ 您如何避免因使用该whiz-bang库在后门令人讨厌而被伪造，而这确实是您无法没有的真正酷的东西？

旧的方式

我从事编程已有近20年的时间，足以看到从传统的程序规划瀑布或螺旋模型到Xtreme编程，敏捷以及现在的DevOps模型的演变。

过去，漫长的开发周期，缺乏任何实际培训以及识别基于安全性缺陷的工具的真空意味着安全性评估主要在软件开发生命周期的后期进行，而大多数情况下是作为人工练习。 通常，触发审核的动力与审计或客户要求确保系统中数据的安全性有关（这种情况发生的频率更低）。

考虑到这种不经常使用的临时安全评估方法，通常不重视基于安全性的缺陷以及发现缺陷的测试。 信息安全小组关注“发现”，即一种运行工具，当被要求安抚审核员以确保一切正常时，它们会生成报告。 功能和功能优先于解决普通用户无法看到的缺陷，而“没人”可以真正看到它们，对吗？

甚至在这种情况下，即使每天都有新技术工人加入市场，但很少有人接受防御性编码实践方面的培训，您可以看到我们最终会遇到什么问题。

好消息是，现在有真正的策略可以使问题变得清晰，并可以解决这些问题。

新方法

当今世界是自动化和连续迭代的领域之一。 我们将流程称为“ DevOps”，因为它可以融合软件开发，基础架构的定义和自动化，从而创建用于自启用的部署和操作的模型。

当我们增加安全性时，我们会抱有相同的期望，即我们将一切自动化，并定义模式和过程，使它们可以连续重复。 我们最终得到了我喜欢的“ DevSecOps”。

这种新方法的关键是“左移”，将安全测试和开放源代码编写工作从后期生产转移到设计和开发。

就像在DevOps中一样，使开发人员能够定义基于软件的体系结构，对其进行版本化并使用自动化进行部署，DevSecOps为这些相同的开发人员提供了相同的工具，技术和流程，以实现软件安全性。

步骤1：开始设计

开源快速摆脱困境的最大途径是，在我们开始编码之前，不考虑应用程序的组成。 您是否仍在为新应用程序使用两年的Struts副本，仅仅是因为它是您工作站上已经存在的东西，而不是您之前所做的10个项目中留下的东西？ 每次启动新项目时，请确保您使用的框架是最新，最受信任的框架。 使用SourceClear之类的免费或廉价工具来识别应用程序中的物料清单（BOM），并确保它在开始工作之前达到等级。 它将为您免除以后的头痛。

第2步：自动执行所有操作。

作为开发人员，在我本来已经很忙的一天里，没有什么事情比其他人来找我时还要烦人的了。 如果您希望开发人员在每次部署时都使用该工具，在网站上浏览或要求某人许可，则他们不可避免地会找到避免该问题的方法。

另一方面，如果您可以自动化运行该事物，检查该列表或通知该团队的过程，那么开发人员将专注于使公司赚钱或为客户增加价值的事情。 InfoSec喜欢说“安全是每个人的工作”，但常常忘记了增值才是第一位。 如果我们无法为我们的客户或股东增加价值，那么就没有什么可以保证的。

这里的关键是带外处理并使它透明。 它必须是异步且不可见的，否则它将成为某人的痛苦点。

步骤3：培养“好公民”而不是“好身材”

最后，为了真正实现DevSecOps，我们必须努力改变围绕InfoSec策略和与之相关的部署过程的观念。

过去大多数涉及安全性的部署模型看起来都像这样：

设计–>代码–>集成测试–>质量检查–> InfoSec评论–>生产

但是，当DevOps周期可能只有几个小时甚至是几分钟时，如何使InfoSec在生产前进行审核？ 答案：你不知道。

让我这样说：如果开发人员因为您进行了自动化的静态代码分析而在早期就获得了良好的信息，并且为您的开源框架提供了自动生成BOM的自动化方法，那么您已经在软件开发生命周期的早期提供了此方法。由于开发甚至是设计，那么您在构建中到底要测试什么？

您只是在问他们是否对他们已经知道的采取了行动。

现在问自己一个问题，“你信任他们吗？”

看，如果您足够早地提供信息，那么到部署时，实际上可以删除“ InfoSec Review”！

什么！？

这是真的。 此时，您的变更控制过程可以简单地询问：

• “此应用程序的自动安全审查是否已在每个阶段完成？”
• “开发人员是否一直在按预期解决关键缺陷？”
• “最后完成的评估措施是否达到了我们的期望（政策）？”

如果您对这些问题的回答是“是”，那么您正在做的就是相信开发团队正在充当模范公民，谨慎生产高质量的产品，并以负责任的方式表现良好。 我们的新模型如下所示：

明智的设计–>自动化代码审查–> IT –>质量检查–>好公民？ –>部署！

杰里米·安德森（Jeremy Anderson）将在德克萨斯州奥斯汀举行的OSCON 2017上的演讲“ 保护应用程序中的其他97％的安全”中对该过程进行更深入的回顾。 如果您有兴趣参加会议，请在注册时使用以下折扣代码： PCOS 。

翻译自: https://opensource.com/article/17/5/secure-open-source-devops

devops 开源