devops 代码拉取_作为代码的安全性：为什么安全DevOps需要精神转变
devops 代码拉取
惯性是“无所事事或保持不变的趋势”。 它是物理学中的强大力量。 它还经常在技术行业中占主导地位。
到1996年，创建了Internet协议版本6（IPv6）的第一个正式定义。 在20多年后，IPv4仍然是使用的主要版本。 IPv6的增长缓慢，但是在可预见的将来它不会成为主要的IP版本。 在技术方面，惯性很强。
心理模型也是如此。 某种思维方式常常扎根，改变思维方式变得越来越困难。 最终，那些刚接触该行业的人将只会跟随其他人正在做的事情。
但是，环境的变化需要思想的改变。 DevOps就是这种环境变化之一。 DevOps实践正在彻底改变软件的构建方式，从而比以往更轻松地更频繁地交付高质量的软件。
不幸的是， 有些人认为在此过程中遗留了应用程序安全性。 如果安全性要跟上DevOps实践的步伐，那么开发人员和安全专业人员都需要改变观念。 开发人员需要采用安全性，而安全专业人员则需要采用开发实践。
让我们看一下传统安全性思维为何不适合DevOps领域，以及需要采用哪种新的思维方式。
传统安全惯例
首先，让我们从传统的应用程序安全性的“日常生活中”开始。
一个开发团队奴役了最新的应用程序，这将使公司赚很多钱。 它使用了最新最好的技术。 开发人员迫不及待想要发布它。 直到应用程序安全团队来看看。
在发布应用程序的一个月前，安全团队检查了体系结构和代码。 他们找到安全问题的清单，然后将其交付给开发团队进行修复。
现在发生两件事之一。 要么必须推迟应用程序的发布，要么发布具有多个可利用的漏洞的应用程序。
DevOps实践与传统安全之间存在着相反的作用。 开发人员希望尽快交付价值（DevOps做法），而安全团队希望暂停并确保一切在发布之前都是安全稳定的（传统的安全做法）。
那么如何解决这种反对？
安全即代码
DevOps的基本原则之一是“ 基础架构即代码” 。 诸如Ansible ， Chef和Puppet之类的技术使您可以使用编程语言定义服务器和基础架构，并以自动化方式进行部署。 使用这些工具，您可以为服务器的每个实例自动部署相同的设置。
将基础架构视为代码已成为DevOps实践的主要推动力，但也需要那些实践基础架构的人进行思维上的转变。 系统管理员正在遵循开发实践，并将代码保留在源代码控制中。 开发人员现在可以了解有关服务器设置的更多信息。 它使双方都可以说相同的语言。
自动化测试一直是DevOps运动的强大催化剂。 将功能测试推到开发生命周期的“左侧”或更早，这一点很重要。 这样一来，您就可以更快地查找和修复错误，并将更少的错误投入生产。
应用程序安全性是自动测试的下一个方向。 现在可以前所未有地自动化应用程序安全问题。 但是，为了使这些自动化实践解决安全问题，开发人员和安全专业人员需要进行一次精神上的转变。 我们需要将安全性“左移”。 我们需要安全性作为代码。
开发人员，思考安全性
在最近关注敏捷实践和自动化测试之前 ，开发人员倾向于编写代码而不自己进行测试。 通常将代码交给质量保证团队，让他们发现错误。
最终被接受的是，在开发周期的后期发现并修复错误要比早日发现它们花费更多的钱。 开发人员现在必须考虑如何测试他们的代码。 测试驱动的开发试图确保代码与所需的功能匹配。
安全性应该没有什么不同。 安全是质量的一部分，应该像功能一样进行测试。
从项目一开始就考虑安全性的开发人员将练习“测试驱动的安全性” 。 这是通过编写安全测试用例来完成的，这些用例从一开始就以自动化的方式验证软件的安全性。
实施安全测试案例
看起来像什么？ 开发人员根据应用程序的要求创建功能测试。 对于安全性要求也是如此。
例如，如果您要构建需要身份验证的REST API，那么您将创建测试以确保没有首先进行正确的身份验证就不会访问任何受限的URL。
请看下面的例子（有更多的在这里 ）。 这是Node.js REST API中的一项测试，该测试可确保在未随请求一起发送身份验证令牌时确保返回401 HTTP代码。
如果此代码失败，则说明您的身份验证代码存在重大问题，需要查看一下。 在开发过程中以及在构建管道中本地运行这些测试。 他们会让您有信心满足系统的基本安全要求。
这是否意味着您不需要代码审查？ 不，人类仍然更善于发现导致漏洞利用的复杂漏洞。 自动化基础知识，使人们能够找到复杂的问题。
开发人员和质量保证测试人员可以使用的另一种测试工具称为Gauntlt （发音为“ gauntlet”）。 Gauntlt允许您使用类似于流行的Cucumber框架测试的类似句子的结构来创建安全测试用例。 看起来像这样：
此测试检查使用Nmap在服务器上打开的端口。 在部署之后，这可以是有效的冒烟测试，以确保仅在Web服务器上打开必需的端口。 像这样的测试表明了安全测试用例的有用性，并且将测试添加到您的项目中并不困难。
开发人员需要从与单元和集成测试相同的角度开始考虑安全性测试。 自动执行测试，以确保应用程序的安全性，同时保持交付速度。
安全从业者，更像开发人员
另一方面，传统的安全专家通常不会遵循开发周期。 许多人根本不了解软件开发实践。 应用程序安全团队要等到开发团队敲击他们的肩膀，然后要求他们检查其应用程序。 这通常是在应用程序正式投入生产之前。
安全团队进行审核，然后将找到的结果传递给PDF文件。 这在DevOps环境中不起作用，因为它的伸缩性不足以跟上应用程序的更改。 同时运行许多应用程序和项目的大公司永远不会有足够大的安全团队来及时审查它们。
因此，应用程序安全团队也需要将安全性视为代码。 这种作为代码的安全性不是应用程序测试用例，而是使用代码来自动化安全性测试工具以使测试更加高效。
让我们看一下它是如何工作的。
自动化渗透测试
OWASP Zed攻击代理 （ZAP）是功能强大的渗透测试工具，用于测试Web应用程序和发现可利用的漏洞。 它具有多种不同的开箱即用扫描应用程序的方式，并且只需按一下按钮就可以非常有效。
但是，像ZAP这样的工具的真正价值在于它对自定义脚本的支持。 ZAP允许您创建自定义脚本，以自动执行人类可以执行的复杂测试。
应用安全小组在使用ZAP之类的工具时可以使用的一个很好的策略是自动化您的手动测试结果。 像往常一样在您的应用上执行手动渗透测试，并记录发现的有趣而复杂的漏洞。 然后使用ZAP将这些手动测试转换为自动化脚本。
现在，您可以将该脚本指向任意数量的类似应用程序，并在设置手动测试所需时间的一小部分内对其进行测试。 查看以下示例：
看一下ZAP中的脚本。 它检查以确保应用程序不接受未签名的JSON Web令牌 。 对所有需要JSON Web令牌的Web应用程序运行此命令，如果没有手动渗透测试，您将很快发现问题。
我接下来要说的不要害怕：安全从业人员可能必须创建自己的代码存储库并保持最新。 打开一个GitHub帐户并试用它，以了解其工作原理。 请您公司的友好开发人员向您展示如何在使用的任何源代码控制系统中创建项目。 一旦学习了源代码管理的工作原理，您将发现使用它的巨大好处。
开发人员需要考虑安全性。 安全专家需要思考发展。 自动化是保持DevOps环境的唯一方法。
为开发人员启用自助服务安全性
DevOps的另一个主要租户是开发人员自助服务。 现在，开发人员可以在需要时按需创建服务器和环境，并在完成后将其拆除。
应用程序安全团队应该认识到这一点，并为开发团队提供自助服务。 使用自动化工具使开发人员能够更快地发现错误。 将安全测试工具集成到构建管道中，并确保它们在每次提交时都运行。 ZAP和Gauntlt之类的工具可以轻松设置为CI服务器（例如Jenkins）中的任务。
应用程序安全团队应尽可能将安全性工具引入开发人员的日常工作中。 IDE插件可以帮助开发人员在编写代码时（而不是数周或数月后）发现安全漏洞。 Puma Scan是Visual Studio的插件，可扫描C＃代码中的安全问题，而Find Security Bugs是Eclipse的流行插件，对Java代码也具有相同的功能。 这些插件可以在教开发人员如何安全编码的同时，使您的软件更安全。
最后，在针对代码库和构建进行扫描时，开发人员需要查看结果。 创建可使用的仪表板，从安全角度清楚地显示应用程序的运行状况。
允许开发团队查看存在的问题，并在使用的任何项目管理或错误管理软件中为他们创建票证，而不仅是将这些责任交给安全从业人员。
安全即代码：确保DevOps安全的途径
保护DevOps工作流程似乎令人生畏。 这种感觉源于坚持旧的做事方式，而这在这个新的令人兴奋的世界中已不再重要。
开发团队需要将安全视为质量。 在测试中赋予安全性一流的地位，从一开始就保护您的应用程序安全。
同样重要的是，安全不再会阻碍发展。 寻找自动化安全测试的方法。 在开发安全软件方面为开发人员提供帮助，并帮助他们采取下一步措施。
当我们将安全性作为代码实现时，无论在技术上还是在思维上，安全的DevOps都将成为现实。
翻译自: https://www.javacodegeeks.com/2018/03/security-code-mental-shift-necessary-secure-devops.html
devops 代码拉取