现在没人真的自己写代码了，对吧？我们去 GitHub 下载一些库，避免重复造轮子，然后将这些轮子和我们自己的粘合剂打包在一起，创建新的软件。然后我们下载六个前端框架，让一切变得美观且响应迅速，然后我们就开始比赛了。在我的公司和其他公司的应用审查中，我发现如今构成应用的 90% 以上的代码是我们借用的，而不是自己编写的。
我们大多数人使用静态分析工具扫描我们自己的代码中的缺陷，但是我们没有编写的所有代码呢？我们如何知道那里实际有什么？一旦您找出其中包含的内容，您会采取哪些措施来清理它或保持其新鲜度？您如何避免因为您使用那个非常酷的库（您离不开它）让讨厌的东西从后门溜进来而被pwned？
旧方法
我从事编程工作已经快 20 年了，足以见证从传统的瀑布或螺旋式程序规划模型到极限编程、敏捷和现在的 DevOps 模型的演变。
过去，漫长的开发周期、缺乏任何真正的培训以及识别基于安全性的缺陷的工具真空意味着安全评估主要在软件开发生命周期的后期阶段进行，并且主要作为一项手动工作。通常，触发审查的动因与审计或客户要求保证其在您系统中的数据有关（这种情况甚至更少发生）。
鉴于这种不频繁和临时的安全评估方法，基于安全性的缺陷和发现它们的测试通常会被降低优先级。信息安全团队专注于“发现”，运行工具以生成报告，以便在被要求安抚审计员时，表明一切都还可以。功能和特性优先于解决普通用户永远不会看到的缺陷，并且“没有人”会真正看到它们，对吧？
在这种情况下，再加上一个事实，即即使每天都有新的技术从业人员加入市场，但很少有人接受过防御性编码实践的培训，您可以看出我们是如何最终遇到问题的。
好消息是，现在有真正的策略可以使问题变得清晰，并有解决问题的方法。
新方法
今天的世界是自动化和持续迭代的世界。我们将该过程称为“DevOps”，因为它融合了软件开发以及基础设施的定义和自动化，从而创建了自我启用的部署和运营模型。
当我们将安全性添加到其中时，我们应用相同的期望，即我们自动化一切，并定义模式和流程，以便它们可以持续重复。我们最终得到了我喜欢称之为“DevSecOps”的东西。
这种新方法的关键在于“左移”，将安全测试和开源组件构成工作从后期生产阶段转移到设计和开发阶段。
就像在 DevOps 中，开发人员可以定义基于软件的架构、对其进行版本控制并使用自动化部署它们一样，DevSecOps 为这些相同的开发人员提供了工具、技术和流程，以便对软件安全执行相同的操作。
步骤 1：从设计开始
开源快速失控的最大原因是，在我们开始编码之前没有考虑应用的构成。您是否仍然在新应用中使用两年前的 Struts 副本，仅仅因为它是在您的工作站上，是从您之前做的 10 个项目中遗留下来的？每次您开始一个新项目时，请确保您使用的是您所依赖的框架的最新、最受信任的版本。使用像 SourceClear 这样的免费或廉价工具来识别您应用中的物料清单 (BOM)，并确保它在您开始工作之前达到标准。这将为您省去以后的麻烦。
步骤 2：自动化一切。
作为一名开发人员，没有什么比有人来找我，让我在已经超负荷的一天中再做另一件事更令人恼火的了。如果您期望开发人员每次部署时都使用工具、查看网站或向某人请求许可，他们将不可避免地找到一种避免它的方法。
另一方面，如果您可以自动化运行该事物、检查该列表或通知该组的过程，那么开发人员就会专注于为公司赚钱或为客户增加价值的事情。信息安全部门喜欢说“安全是每个人的工作”，但常常忘记增加价值是第一位的。如果我们不能为我们的客户或我们的股东增加价值，就不会有任何东西需要保护。
这里的关键是异地执行并使其透明。它必须是异步的和不可见的，否则它将成为某人的痛点。
步骤 3：培养“好公民”而不是“好构建”
最后，为了真正实现 DevSecOps，我们必须努力改变围绕信息安全策略和与此相关的部署流程的思维模式。
过去，大多数涉及安全性的部署模型都类似于
设计 –> 代码 –> 集成测试 –> 质量保证 –> 信息安全审查 –> 生产
但是，当 DevOps 周期可能只有几小时甚至几分钟时，您如何在生产之前进行信息安全审查？答案：您不进行审查。
让我这样说：如果开发人员很早就获得了良好的信息，因为您自动化了静态代码分析，并且您提供了一种自动化方法来为您的开源框架生成 BOM，并且您从开发甚至设计开始就在软件开发生命周期的早期阶段提供了这些信息，那么您到底在构建中测试什么？
您只是在问他们是否对他们已经知道的事情采取了行动。
现在问问自己这个问题，“您信任他们吗？”
看，如果您足够早地提供信息，那么当到了部署的时候，“信息安全审查”实际上可以被删除！
什么！？
这是真的。此时，您的变更控制流程可以简单地询问
- “此应用程序的自动化安全审查是否已在每个阶段完成？”
- “开发人员是否按照预期持续解决关键缺陷？”
- “上次完成的评估是否符合我们的期望（策略）？”
如果您可以对这些问题回答“是”，那么您所做的就是信任开发团队充当模范公民，小心地生产高质量的产品，并且（在获得良好情报的情况下）以负责任的方式行事。我们的新模型如下所示
知情设计 –> 自动化代码审查 –> IT –> 质量保证 –> 好公民？ –> 部署！
Jeremy Anderson 将在他的演讲中更深入地回顾此过程，保护您应用的其他 97%，在德克萨斯州奥斯汀举行的 OSCON 2017 大会上。如果您有兴趣参加会议，请使用此折扣码在您注册时：PCOS。
评论已关闭。