如何以代码的形式提供安全性：11个入门提示

[[270725]]

正如Grupo Banco Santander安全研究负责人Daniel Cuthbert在“为开发者致电武器：以安全为代码的革命性”中所写道：

现在是时候把我们的努力集中在防御 - 而不是攻击 - 并让那些能够有所作为的人成为英雄：开发者。

BIDS Trading Technologies的首席技术官Jim Bird是一位拥有20多年金融服务技术经验的软件和项目经理，他在O'Reilly的这份报告中写道：

作为代码的安全性是关于在DevOps工具和实践中构建安全性，使其成为工具链和工作流的重要组成部分。您可以通过绘制如何更改代码和基础结构以及查找添加安全检查和测试和门的位置而不会引入不必要的成本或延迟来实现此目的。

- 吉姆伯德

那么您的团队如何超越概念转变为行动?这里有11个技巧可以帮助您入门。

1.理解'安全SDLC'的含义

了解安全软件开发生命周期(SDLC)将帮助您评估如何在特定的DevOps情况下构建安全性。您可以犯的很大错误是尝试执行安全性而不了解它是什么。

关于这个主题的权威来源是OWASP Secure SDLC备忘单;虽然它仍处于草稿模式，但它提供了一个很好的概述。下图显示了在开发周期的每个步骤中发生的活动。

显示“向左移动”的箭头说明了通过执行安全实践尽早嵌入安全性的概念，下面进一步定义。图片提供：OWASP。

2.使用SAMM评估您的情况

软件保障成熟度模型(SAMM)是一个开放式框架，可帮助组织制定和实施针对组织面临的特定风险量身定制的软件安全策略。但是，有些人认为这个框架执行起来很复杂。

在您的组织牢牢掌握SAMM之前，这些问题将帮助您快速评估DevOps流程的安全组件：

1. 要求：您是否正在收集专门针对要构建的软件的安全和隐私要求?
2. 设计：您是否在每个sprint上进行威胁建模?
3. 开发：您使用静态分析和代码审查吗?
4. 测试：您是否使用动态分析和安全测试来验证安全要求?
5. 部署：您是否计划使用笔测试评估最终版本或进行包含错误赏金计划的风险评估?

如果您的答案大多数没有，那么您处于实施安全性的早期阶段 - 换句话说，您的DevSecOps工作处于非常低的成熟度级别。

许多组织将他们的安全工作集中在周期的最后阶段，在笔测试之后进行部署。不幸的是，如果您发现主要漏洞，这种方法成本很高。而且一个很大的风险是笔测试可能无法发现确实存在的任何重大问题。

相反，“左移”运动越来越注重从一开始就嵌入安全性，最终成本更低，风险更小。

3.注意DevOps中固有的安全挑战

DevOps是一个嵌入安全性的具有挑战性的过程。例如，考虑安全原则，例如“最低权限”，开发人员可以访问生产环境并进行任何更改。这与大多数优秀实践安全概念相矛盾，但是当安全性作为代码到位时，仍然希望嵌入安全性。

安全性不能成为业务的障碍，但有必要在安全开发和没有安全形式的敏捷之间找到平衡点。

4.尽快将安全性作为代码实施

在敏捷冲刺期间嵌入安全性应该是完美无缺的，并且几乎是自动的。这是理想的情况，但很难做到正确。

另一种方法是在此过程中尽可能自动化，包括应该必须具备的特定安全DevOps管道。团队中的每个人都应该保持一致并坚持这些想法。

5.早期的威胁模型

在sprint开始前至少一天计划威胁建模会话。所有潜在的问题和风险都应成为安全故事的一部分。

6.尽早定义安全要求

1. 确保在sprint开始时定义安全要求，包括威胁建模问题。 (提示：使用OWASP ASVS 2.0来支持此过程。)
2. 制作安全要求安全性故事并将其添加到sprint backlog中。
3. 在sprint定义期间，计算实现和创建测试用例以解决这些安全性故事/任务所需的工作量。 (提示：使用OWASP测试指南。)
4. 在开发阶段使用OWASP主动控件，并确保在每个sprint期间这些控件成为常规任务。

7.使用SAST / DAST工具

1. 在构建过程中插入静态和动态分析工具(SAST / DAST)。
2. 从这些扫描中获得定期冲刺错误的结果。这应该在清理任务之后完成，例如确保消除尽可能多的误报。
3. 如果代码变化太大，您可能会重新考虑如何应用SAST，因为当代码发生很大变化时会出现许多误报。
4. 如果您的组织无法负担付费工具，请查看开源替代方案，例如OWASP依赖关系检查，以至少找到易受攻击的组件。

8.尽可能执行代码审查

一个任务是执行代码审查作为sprint的一部分。这里发现的任何问题都会在冲刺结束时成为错误。

9.衡量风险并确定优先顺序

产品所有者 - 或者在决策中执行此指定角色的人 - 应具有适当的安全背景，以了解问题并能够优先考虑那些需要很高关注的问题。

10.准备安全性代码骨干

环境的任何更改(QA / UAT / PROD)都应该使用代码手动完成。配置的所有更改都应该通过代码，使用源存储库并跟踪所有更改。这可以通过任何流行的构建，源代码和部署工具来实现。这是代码安全概念的支柱。

纵观整个过程，DevOps管道应侧重于嵌入自动化持续交付过程的活动。以下是关注的内容：

1. 所有环境中的配置更改都应该由源控制和同行评审。
2. 构建过程应该自动化集成和部署。
3. 在考虑安全性的情况下仔细检查容器的配置。
4. 应将SAST工具集成到构建过程中，并将发现的问题反馈到sprint中。

11.定期评估，冲洗并重复

进行SAMM评估会议以检查您实施安全性的完整程度，并创建特定的短期任务来实现此目标。一步一步是关键。

左移可以帮助你保持领先

向左移动的组织在发现缺陷方面更有效，修复它们的损失和成本低于开发人员部署应用程序时，或者在发布应用程序之后。

但快速交付的压力使设计的安全性变得更加困难。 DevOps团队有责任在短时间内验证安全要求。 “作为代码的安全性”可以在这方面发挥重要作用，因为它有助于自动化安全部署过程，使过程更容易，更快。