我们有2个代码分析器，4个用于动态测试的工具，我们自己的技术和250个脚本。 并不是在当前过程中所有这些都是必要的，但是自从我开始实现DevSecOps以来，我们必须结束。
来源 角色作者：贾斯汀·罗兰（Justin Royland）和丹·哈蒙（Dan Harmon）。什么是SecDevOps？ 那么DevSecOps呢？ 有什么区别？ 应用程序安全性-涉及什么？ 为什么经典方法不再有效？
Swordfish Security的 Yury Shabalin知道所有这些问题的答案
。 Yuri将详细回答所有问题，并分析从经典的应用程序安全模型到DevSecOps流程的过渡问题：如何在DevOps流程中实现安全开发流程的嵌入，而不破坏任何内容，如何经历安全测试的主要阶段，可以使用哪些工具，使用什么？它们有所不同，以及如何正确配置它们以避免陷阱。
关于发言人： Yuri Shabalin- Swordfish Security的首席安全架构师。 他负责SSDL的实施，将应用程序分析工具一般集成到单个开发和测试生态系统中。 7年的信息安全经验。 他曾在Alfa Bank，Sberbank和Positive Technologies工作，该公司开发软件并提供服务。 ZerONights，PHDays，RISSPA，OWASP国际会议的发言人。
应用程序安全性：它是关于什么的？
应用程序安全性是负责应用程序安全性的安全性部分。 这不适用于基础结构或网络安全性，即我们编写的内容和开发人员正在从事的工作-这些是应用程序本身的缺陷和漏洞。
SDL或SDLC （
安全开发生命周期）的方向是由Microsoft开发的。 该图显示了规范的SDLC模型，其主要任务是在需求的每个开发阶段（从需求到发布，再到正式发布到生产中）都涉及安全性。 微软意识到舞会中的bug太多了，而且需要做的事情很多，于是他们提出了这种方法，这种方法成为了规范。
正如通常认为的那样，应用程序安全性和SSDL并非旨在检测漏洞，而是旨在防止漏洞的发生。 随着时间的流逝，Microsoft的规范方法得到了改进，发展，并且其中出现了更深层次的细节。
规范SDLC在各种方法中都有非常详细的介绍-OpenSAMM，BSIMM和OWASP。 方法不同，但通常相似。
在成熟度模型中建立安全性
我喜欢
BSIMM最 成熟的安全性成熟度模型 。 该方法的基础是将应用程序安全性过程分为四个领域：治理，情报，SSDL接触点和部署。 每个领域有12个实践，分别代表112个活动。
112个活动中的每一个都有
3个成熟度级别 ：基础，中级和高级。 可以分节研究所有12种实践，为您选择重要的事物，了解如何实现它们并逐步添加元素，例如，静态和动态代码分析或代码审查。 您绘制计划并在所选活动的实施过程中对其进行镇静处理。
为什么选择DevSecOps
DevOps是一个常见的大型流程，您需要在其中注意安全性。
最初，
DevOps包括安全检查。 实际上，安全团队的数量要比现在少得多，他们不是过程的参与者，而是充当控制和监督机构，对发布的要求进行设置并在发布结束时检查产品的质量。 这是一种经典方法，在这种方法中，安全团队无法参与开发，也不会参与流程。
主要问题是信息安全与开发是分开的。 通常这是一种IB电路，包含2-3个大型且昂贵的工具。 每六个月发送一次源代码或应用程序，需要对其进行检查，并且每年
进行一次
渗透测试 。 所有这些导致了这样一个事实，即进入舞会的截止日期被推迟，并且自动工具产生的大量漏洞落在了开发人员身上。 所有这些都无法拆卸和修复，因为前六个月的结果尚未整理出来，这是新一批。
在我们公司的过程中，我们看到各个领域和行业的安全性都知道，现在是时候让自己振作起来，并随心所欲地开发
敏捷性了 。 DevSecOps范例非常适合敏捷开发方法，实现，支持以及参与每个发行版和迭代版。
过渡到DevSecOps
安全开发生命周期中最重要的词是
“过程” 。 在考虑购买工具之前，您必须了解这一点。
仅将工具集成到DevOps流程中是不够的-流程参与者之间的交互和理解很重要。
比人更重要，而不是工具
通常，安全开发过程的规划始于工具的选择和购买，最后是将工具集成到当前过程的尝试，而这些尝试仍然是尝试。 这会导致可悲的后果，因为所有工具都有其自身的特征和局限性。
当安全部门选择一个好的，昂贵的，功能强大的工具并向开发人员求助时，这种情况就很普遍。 但这并没有解决-该流程的结构设计使得已购买的工具的局限性不适合当前的范例。
首先，描述您想要的结果以及该过程的外观。 这将有助于了解工具的作用以及过程中的安全性。
从已经使用的东西开始
在购买昂贵的工具之前，请先查看一下您已有的东西。 每个公司都有发展的安全要求，要有检查和渗透测试-为什么不将所有这些转换成每个人都可以理解和方便的形式？
通常，需求是放在架子上的Talmud纸。 在某些情况下，我们来公司查看流程并要求显示软件的安全要求。 这样做的专家已经寻找了很长时间：
-现在，在笔记中的某处有一种放置该文档的方式。结果，一周后我们收到了该文件。
对于需求，检查和其他事情，例如在
Confluence上创建一个页面-这对每个人都很方便。
重新格式化已经存在的内容并使用它开始更容易。
使用安全冠军
通常，在一家由100至200名开发人员组成的中型公司中，一名安全员在工作，负责执行多项功能，并且实际上没有时间检查所有内容。 即使他尽力而为，也不会独自检查开发生成的所有代码。 对于这种情况，已经提出了一个概念-
安全冠军 。
Security Champions是开发团队中的一个对您产品的安全性感兴趣的人。
安全冠军是开发团队的切入点，安全宣传人员全都整合到了一起。
通常，当安全人员来到开发团队并指出代码中的错误时，它会收到一个惊讶的答案：
“你是谁？” 我第一次见到你。 我做得很好-我的资深朋友将代码审核设置为“应用”，我们走得更远！这是一种典型情况，因为对高层或团队成员的信任度更高，开发人员在工作和代码审查中经常与他们进行交互。 如果安全负责人代替安全警卫指出错误和后果，那么他的话语将具有更大的分量。
而且，开发人员比任何安全提供程序都更了解他们的代码。 对于使用静态分析工具至少拥有5个项目的人来说，通常很难记住所有细微差别。 安全支持者知道他们的产品：什么与什么以及首先要看的内容进行交互-他们更有效。
因此，请考虑实施安全支持者并扩大安全团队的影响力。 对于冠军本人来说，这也很有用：在新领域进行专业发展，扩大技术视野，提升技术，管理和领导技能，增加市场价值。 这是社会工程学的某些元素，是开发团队中的“眼睛”。
测试步骤
20至80范式表示20％的工作量产生了80％的结果。 这20％是可以并且应该自动化的应用程序分析实践。 此类活动的示例包括静态分析
-SAST ，动态分析
-DAST和
开源控制 。 我将向您介绍有关活动以及工具的更多信息，将这些功能引入流程时我们通常会遇到哪些功能，以及如何正确进行操作。
工具的主要问题
我将重点介绍与所有需要关注的工具有关的问题。 我将更详细地分析它们，以免重复。
长时间分析。 如果从提交到进入生产过程需要30分钟才能完成所有测试和组装，则信息安全检查将需要一天的时间。 因此，没有人会减慢该过程。 考虑此功能并得出结论。
高误报率或误报率。 所有产品都是不同的，每个人都使用不同的框架和自己的代码编写风格。 在不同的代码基础和技术上，工具可以显示出不同级别的假阴性和假阳性。 因此，请查看
您的公司以及
您的应用程序中将显示出良好而可靠的结果。
不与现有工具集成 。 从集成的角度来看这些工具，以便您已经在使用它们。 例如，如果您拥有Jenkins或TeamCity，请检查工具是否与此软件（而不是与您未使用的GitLab CI）集成。
定制的缺乏或过于复杂。 如果该工具没有API，那么为什么需要它？ 接口中可以完成的所有操作都应通过API进行访问。 理想情况下，该工具应具有自定义检查的功能。
没有路线图产品开发。 发展不会停滞不前，我们始终使用新的框架和功能，将旧代码重写为新语言。 我们希望确保我们购买的工具将支持新的框架和技术。 因此，重要的是要知道该产品具有真实，适当的开发
路线图 。
工艺特点
除了工具的功能外，还要考虑开发过程的功能。 例如，干扰开发是一个典型的错误。 让我们看看应该考虑哪些其他功能以及安全团队应该注意什么。
为了不中断开发和发布日期，请
针对不同的环境创建
不同的规则和不同的
显示停止器（在存在漏洞的情况下停止构建过程的条件）。 例如，我们知道当前分支转到开发摊位或UAT，因此我们不会停下来也不会说：
-您这里有漏洞，您将再也无法寻找任何地方！在这一点上，重要的是要告诉开发人员存在值得关注的安全问题。
漏洞的存在并不构成进一步测试的障碍 ：手动，集成或手动。 另一方面，我们需要以某种方式提高产品的安全性，以便开发人员不要忘记他们发现的安全性。 因此，有时我们会这样做：在展位上，当它推广到开发环境时，我们只是通知开发人员：
-各位，您有问题，请注意。在UAT阶段，我们再次显示有关漏洞的警告，在舞会的退出阶段，我们说：
-伙计们，我们已经警告过几次，您什么也没做-我们不会让您失望的。如果我们谈论代码和动态特性，则必须仅显示和警告那些功能和仅使用此功能编写的代码的漏洞。 如果开发人员将按钮移动了3个像素，并且我们告诉他他在那里进行了SQL注入，因此迫切需要修复，这是错误的。 仅查看现在编写的内容以及应用程序带来的更改。
假设我们存在一定的功能缺陷-应用程序不应运行的方式：资金无法转移，当您单击按钮时，不会过渡到下一页，或者产品不会加载。
安全缺陷是相同的缺陷，但不是在应用程序的上下文中而是安全。
并非所有软件质量问题都是安全问题。 但是所有安全问题都与软件质量有关。 Sherif Mansour，Expedia。
由于所有漏洞都是相同的缺陷，因此它们应与所有开发缺陷位于相同的位置。 因此，请忘记没有人阅读的报告和令人恐惧的PDF。
在一家开发公司工作时，我从静态分析工具获得了一份报告。 我打开它，吓坏了，煮咖啡，翻阅了350页，关闭它，然后继续工作。
大报告是无用的报告 。 通常他们不会去任何地方，信件会被删除，遗忘，遗失，或者公司表示冒险。
怎么办 我们只是将已发现的已确认缺陷转换为便于开发的形式，例如，将它们添加到Jira的积压中。 我们按功能缺陷和测试缺陷的优先顺序对缺陷进行优先级排序和消除。
静态分析-SAST
这是针对漏洞的代码分析 ，但与SonarQube不同。 我们不仅根据样式或样式进行检查。 在分析中，使用了多种方法：在漏洞树中，在
DataFlow中 ，在配置文件分析中。 这都与代码直接相关。
该方法的优势 ：
在开发的早期阶段，没有支架和成品工具的情况下
识别代码中的漏洞 ，以及
进行增量扫描的
可能性 ：扫描一部分已更改的代码，并且仅扫描我们现在正在执行的功能，从而减少了扫描时间。
缺点 -这是缺少对必要语言的支持。
我主观上认为应该在工具中进行
必要的集成 ：
- 集成工具：Jenkins，TeamCity和Gitlab CI。
- 开发环境：Intellij IDEA，Visual Studio。 对于开发人员来说，不必进入仍然需要记住的难以理解的界面，而是在自己的开发环境中的工作场所中查看他发现的所有必要集成和漏洞，将更加方便。
- 代码审查：SonarQube和手动审查。
- 缺陷跟踪器：Jira和Bugzilla。
图为静态分析的一些最佳代表。
它不是重要的工具，而是过程，因此有一些开源解决方案也可以很好地运行过程。
SAST Open Source不会发现大量漏洞或复杂的DataFlow，但是您可以并且应该在构建流程时使用它们。 他们有助于了解将如何构建流程，谁将对错误做出响应，谁要报告，谁要报告。 如果要执行构建代码安全性的初始阶段，请使用开源解决方案。
如果您处在起步阶段，却一无所获，该如何集成？既没有CI，也没有Jenkins，也没有TeamCity？ 考虑将其集成到流程中。
CVS整合
如果您拥有Bitbucket或GitLab，则可以在
并发版本系统级别进行集成。
按事件 -拉取请求，提交。 您扫描代码，并在构建状态中显示安全检查已通过或失败。
反馈。 当然，总是需要反馈。 如果您只是出于安全方面的考虑，请将其放在一个盒子中，并且没有告诉任何人，然后在本月底丢弃大量错误-这既不正确也不行。
与代码审查集成
一次，在许多重要项目中，我们设置了AppSec技术用户的默认审阅者。 根据是否在新代码中检测到错误或是否没有错误，审阅者在拉取请求中将状态设置为“接受”或“需要工作”-一切正常，或者您需要细化并链接到要最终确定的内容。 为了与产品的版本集成，如果未通过IB测试，则启用了合并禁令。 我们将此内容包括在手动代码审查中，该过程的其他参与者看到了此特定过程的安全状态。
SonarQube集成
许多人都有代码质量的
质量门 。 同样的事情-您只能为SAST工具制作相同的门。 会有相同的接口，相同的质量门，只有它会被称为
安全门 。 而且，如果您有使用SonarQube的流程，则可以轻松地集成其中的所有内容。
CI整合
在这里，一切都非常简单：
- 与自动测试，单元测试处于同一水平 。
- 按开发阶段划分 ：开发，测试，生产。 可能包括不同的规则集，或不同的失败条件：停止组装，请勿停止组装。
- 同步/异步启动 。 我们正在等待安全测试的结束还是不等待。 也就是说，我们只是启动了它们并继续前进，然后我们得到了一切都是好还是不好的状态。
这一切都是完美的粉红色世界。 在现实生活中，这不是，但是我们努力。 安全检查的结果应与单元测试的结果相似。
例如，我们进行了一个大型项目，并决定现在将使用SAST'om对其进行扫描-确定。 我们将该项目推到了SAST中，它给了我们20,000个漏洞，并且在一个坚定的决定下，我们接受了一切都很好。 20,000个漏洞是我们的技术职责。 我们将债务放到一个盒子里，然后我们将慢慢清理并在缺陷跟踪器中启动错误。 我们聘请一家公司，全力以赴，否则安全冠军将帮助我们-我们的技术债务将减少。
新代码中所有新出现的漏洞以及单元或自动测试中的错误都应得到修复。 相对而言，组装开始了，开车开了，两次测试和两次安全测试失败了。 好的-他们走了，看看发生了什么，纠正了一件事，纠正了第二件事，下次又把它赶出去了-一切都很好，没有新的漏洞，测试没有失败。 如果此任务更深入，并且您需要很好地理解它，或者修复漏洞会影响底层的大部分内容：它们将缺陷带入缺陷跟踪器，则会对其进行优先级排序和修复。 不幸的是，这个世界并不完美，测试有时会失败。
通过代码中漏洞的存在和数量，安全门的一个示例是质量门的类似物。
我们与SonarQube集成-已安装插件，一切都非常方便和酷。
开发环境整合
整合能力：- 在提交之前从开发环境开始扫描。
- 查看结果。
- 分析结果。
- 与服务器同步。
看起来就像从服务器获取结果。
Intellij IDEA , , . ,
Flow Graph . , — - .
Open Source
. Open Source — , , ?
, , , , , , . Application Security — Open Source .
Open Source — OSA
.
. , , - ,
CVE - - , . , , , .
. , , , . , . , , . , , .
, . , . — , , . , , . Open Source , , -. , , . , . .
:, Open Source.
—
Dependency-Check OWASP. , , . , on-premise, . , , , , .
, . . , Event Central Nexus, , «» «». Nexus Firewall Lifecycle , .
CI . , - : dev, test, prod. , , , - «critical» -, .
: Nexus JFrog.
. , , . , CVS.
CD. , — . .
Public Component Repositories — , . , trusted components. , . , , . , - , — .
- build' , , .
- trusted components.
- : war, jar, DL Docker- , .
- , : .
— DAST
, . . -, , , , : , , , , .
Open Source. DAST , Open Source , «» :
— , , ., , — .
, AppScan: , 3 — - ! , , AppScan — -, , ,
mailform -. :
— , ?! , !. , -, . — , .
, . 10-15 , , , , .
, .
Burp Suite — « » . , . - enterprise edition. stand alone , - , . , .
:
.
mock-, — , .
, . — , , OpenSource, - , ,
Waf .
.
, , , , -.
. , , . , , . , .
API, , , , —
AppSec , .
, security- , , , , , . , , — Confluence , Jira -, / CI/CD.
Key Takeaways
. — . , , . — «» , — - high mega super critical, , .
— , . , , . DevSecOps, SecDevOps, .
, : , , , , . —
. —
.
.
, . , — . - , . , .
—
Security Champions .
, , , - — .
根据您的过程要求选择工具。不要看社区所说的这个工具是不好的，而这个工具是好的。也许这与您的产品完全相反。工具要求。- 低误报。
- 足够的分析时间。
- 易于使用。
- 集成的可用性。
- 了解路线图产品开发。
- 定制工具的能力。
Yuri的报告被选为2018 DevOpsConf上最好的报告之一。要了解更多有趣的想法和实际案例， 请作为RIT ++节的一部分于5月27日至28日在DevOpsConf上前往Skolkovo 。 更好的是，如果您准备分享自己的经验，请在4月21日之前提交报告。