应用安全介绍之Wabbi

在2021年的RSAConference大会上，Wabbi入选创新沙盒的十强初创公司，关于Wabbi的介绍，绿盟科技有一篇文章介绍的很详细，大家可以参考：

http://blog.nsfocus.net/rsa创新沙盒盘点-Wabbi-面向应用全生命周期的安全/

Wabbi的平台由管理器（Manager），策略编排（Orchestrator），发布控制器（Gatekeeper）三部分组成。

管理器主要是项目管理功能，包括项目存在的安全问题，项目安全问题优先级排序，项目安全问题的待办数，项目总体的安全性评分等。

策略编排器，默认提供多种安全策略，包括认证、授权、恶意软件、通讯、文件、业务逻辑等，还包括NIST，OWASP等合规策略。利用集中的策略引擎，将策略分配至不同的项目，保证应用一直遵循当前的安全标准。

发布控制器，保证每次发布的版本都遵循安全标准，并对版本做管理，发现每个版本的安全问题，简化了发布后合规检查的问题。

方案层面，Wabbi提供网络安全成熟度认证，全称是Cybersecurity maturity modle certification，这是美国国防部发起的一项计划，衡量企业的网络安全能力，分为五个阶段，可执行，可文档，可管理，可检查，持续优化。但对国内参考意义不大，因此不仔细介绍。

工具集成方面，Wabbi是希望保护DevOps流程的安全，也就意味着要和流程中的很多工具能够集成，目前能集成的工具有IDE(visual studio，eclipse)，白盒（SonarQube），CI（Jenkins），流程管理（Jira），测试工具（Contrast），云平台应用（Azure Boards，Azure Pipelines）等。

其实读完这些，从一个行业从业者的角度来看，还不是很清楚其技术理念和产品具体功能，于是尝试着把网站都看了一遍，包括网站上的blog，主要目的还是希望能学习到他的一些技术思想，市场营销方式，对国内的同行提供参考。

 

主页介绍

技术理念：横跨现代开发团队，扩展应用安全

Wabbi SecDevOps 基础设施平台和开发工作流集成，提供信息连续性，使安全可以扩展到整个DevOps管道，这样团队将不需要在安全和敏捷之间抉择。

• 分析

分析现有的SecOps和DevOps工具输出结果，了解项目属性和安全风险概况，进而推动下游决策。

• 查看

查看现有DevOps工作流中安全相关信息，从策略，步骤到控制，这样就总能掌握符合安全标准的正确信息。

• 行为

生成自动化和有教育意义的决策，回馈到开发管道中，这样可以一直自信地提交代码，确认符合最新的标准。

• 策略管理

不再让策略躺在Excel和Word中，使用Wabbi策略集中管理器，在策略中设置参数，了解其被应用于哪个项目，自动把变更推送给相关人员。

• 项目分析

和ticketing系统集成，例如Jira，甚至在开发开始之前，就可以给活跃的项目创建安全概述，随着功能上线和获悉漏洞结果，持续发展。

• 自动化治理

Wabbi处理所有繁重工作，以了解项目和功能是否符合最新的安全标准。通过易于构建的工作流，Wabbi在CI/CD管道中，自动管理应用安全通过/不通过决策。

Wabbi SecDevOps平台的组成

   1. 管理器（Manager）

安全开发平台，安全问题管理，控制你的安全问题作为开发工作流的一部分，防止瓶颈和积压工作的拖累。

应用安全不仅仅是漏洞

随着DevOps工具链的激增，保护应用所需的工具也随之增多。这生成了大量复杂的安全问题数据，没有项目级的上下文关系，在现有的开发速度下，团队不依赖自动化工具无法管理这些数据。

安全问题包括从失败的控制到漏洞报告，到失效的策略。漏洞管理本身就是一个不完整的应用安全程序。

使用Wabbi的SecDevOps编排平台，开发型组织能够在不中断当前工作流的情况下，明白安全噪音。基于设计细节来定制配置文件，并分配到每一个项目。Wabbi能够分析、优先级排序、自动化操作保证代码符合安全标准地持续交付。

SecDevOps编排能够使企业把他们的安全数据转换成可执行的信息，实现在开发工作流中的教育、自动化、决策。

关键好处：

• 基于项目的优先级排序

基于项目来指定配置文件和质量门禁，Wabbi对安全问题重新评分，确保根据项目的优先级来排列修复顺序，并将相关工作条目集成到待办事项中。

• 实时漏洞管理

随着策略变更，以适应新的威胁容忍度和风险，Wabbi自动对漏洞重新排序，作为待办事项，更新整体应用安全健康度，在ticker系统中生成工作条目。

• 安全债务的控制/计划

了解管理安全债务的努力，控制团队和安全问题有关的工作。此外，预测性的分析有助于做计划时准备和安全相关工作的预算，保证项目按时、按预算交付。

• 监控策略&控制合规

知道哪一个策略和控制没有得到遵守，必要时在Wabbi中自动化生成问题，并推送到ticket系统，保证及时解决问题，不会生成不必要的瓶颈。

 

   2. 编排器（Orchestraor）

安全开发架构，应用安全策略编排，策略是每个应用安全程序的核心，使用Wabbi，保证他们被持续部署。

如果一个策略被发送，DevOps没有读到它，会产生一个噪音吗？

不幸的是，尽管安全部门花费了很大功夫，持续地修改和分发符合企业当前安全态势和外部威胁活动的策略。太常见的是，这些策略被淹没在电子邮件和培训中，当DevOps团队最需要的时候，也就是要执行这些策略的时候，缺无法使用。在当前的DevOps工作流中，没有实时的策略信息。应用安全策略分配很容易出错，会消耗研发团队和安全团队大量的时间资源。保证分配正确的策略。

一个策略反映了一个公司的风险态势和目标、如何执行策略、何时应用以及怎么控制，在分配策略到项目中时，没有一个方法适合所有的场景。

在Wabbi的SecDevOps编排平台的帮助下，安全团队实现应用安全策略集中管理，消除人工策略管理和更新过程。这给了他们知道正确的策略被应用到正确项目上的自信。开发团队不再必须学习大量的策略，做出最佳决策，而是在项目之初，就完全透明的实现自动化分配策略。

SecDevOps给企业持续的策略感知，实时监控策略效率、策略覆盖、策略合规。

关键好处：

• 策略集中管理

不再使用Excel和PDF来管理和分发策略，Wabbi的策略集中管理，可以在单一地点生成、编辑、监控策略，让你集中注意力于生成和部署最佳策略上。

• 策略自动分配

Wabbi易于使用开始阶段调查来分配策略，在项目设计阶段，通过和你的ticket系统集成，摆脱考虑为每个项目分配正确策略的繁琐工作。

• 策略实时更新

永远不要担心跟踪哪一个策略分配到哪一个项目上，当项目和策略细节变更时，相关人员会被自动通知所有变更，包括风险状态。

• 策略效果监控

当策略没有被执行时，能够了解，并得到前线的反馈，能持续改善策略和保证在SDLC中应用安全策略的持续覆盖。

 

3. 发布控制器(Gatekeeper)

安全开发发布控制

使用Wabbi Gatekeeper，有信心知道每一次代码交付时符合安全标准。

一个检查清单不是发布控制

你的自动化发布基础架构应该是这样—都是自动化的。不幸的是，安全发布需求常常被卡在检查清单和收件箱内，等待人们去处理他们。没有自动化的治理，团队必须选择等待人工处理，验证代码符合安全标准，希望没有大的问题而发布软件。这两个选择导致增加的信息和交付风险，拖累了开发生产力。

DevOps自动化，确保防止、识别和修复瓶颈，因此代码能够发布，但没有SecDevOps编排，安全成为最大的瓶颈之一。

使用Wabbi SecDevOps 基础设施平台的发布控制器，自动化安全质量控制，保证安全和你其他的DevOps自动化保持一致。应用安全不再是一个瓶颈，集成到所有的质量检查中，这样代码持续地、准时、按预算、按规格交付。

Wabbi 发布控制器编排所有的安全质量检查，保证交付的代码总是符合当前的安全标准，当不符合时，它知道去提醒谁，应该修复什么。

关键好处：

• 环境级控制

不要让安全阻碍你的测试，使用Wabbi发布控制器，你能够根据环境设置不同的安全标准，这样你的QA流程能持续。漏洞正在被修复

• 自动审批工作流

当一个环境不符合标准，但需要发布，Wabbi知道正确的批准工作流，按照他们习惯的沟通方式，自动化提示相关人员。

• 修复优先级排序

由于不符合安全标准，构建失败。Wabbi给团队展示信息，纳入合规，保证交付。

• 完整审计跟踪

随时访问完整审计跟踪，了解代码交付时的安全需求，是否有简化事故处理和合规要求的优先指示。

 

 

什么是SecDevOps？

2019年，11月1日

SecDevOps就是把安全集成到开发流程中。十个安全事故，有九个是由于代码缺陷导致的。这就毫不奇怪，公司都在积极的把安全集成到他们的开发管道中。随着这股潮流，也出现了一个新的行业—DevSecOps，还有随之而来的大量行业术语。

你也许听过的一些术语：

• 健壮版DevOps（Rugged DevOps）

健壮版DevOps专注于把安全融入到开发中的文化，Josh Corman，Jeff Williams，David Rice发表了“有能力生成可用、可生存、可防御、安全和弹性的软件”的宣言。在威胁图景持续变化的世界中，软件也许会以我们从未想过的方式被使用。不依赖特定的开发方法，而是关于安全主动持续地作为开发的一部分而进化。

• 安全设计（Security-by-Design）

如同它听起来那样，安全设计专注于把安全的编码实践构建到产品或特定的功能中。着眼于在最早期阶段，使用有力的安全控制，最小化攻击平面，预知风险区域，保证防御深度。在这里，你常常会听说如威胁建模这样的练习，某些方面，它有点像提前预测渗透测试。在你还没开始编写代码之前，尽量发现你的代码可能被恶意使用的方法。

• 左移

左移重点是在开发周期中，尽早的安全测试，在整个流程中，逐渐向左移动。重点放在SDLC中安全测试的时间、地点和频率。重度依赖DevOps管道的自动化，使应用安全测试可以和开发并行操作。然而公司常常很为难，因为他们担心测试太早，影响速度和安全之间的平衡。

• 等等，你刚才不是说这个行业叫DevSecOps吗？

是的，那是常见的说法，甚至有一个争论，是否只是DevSecOps，或者只是一个代称，表明把安全集成到开发管道里，代表着三个子变量，DevSecOps，DevOpsSec，SecDevOps。

我们相信是有区别的，事实上这三个变量反映了把安全集成到开发管道流程中的成熟度。细节区别如下图：

 

   

DevOpsSec

DevOpsSec把安全放在开发之后，仍然意味着和开发流程一定程度的集成（和DevOps+Sec对比）。但仅在代码已经上线之后，90%的公司在代码完成之后开始安全测试，尽管这样修复生产环境中的漏洞更加困难和昂贵。

你有DevOpsSec吗？

• 安全团队和开发团队隔离，除了重要的情况，交流有限

• 你已经计划漏洞扫描，因为你知道安全不仅仅是合规

• 结果在单独的工作流中被管理，可能是手动管理

DevOpsSec就像盖一座房子，先住进来，然后再检查是否盖得合理，当需要修复时，需要更长的时间，而且总是不合适。

 

DevSecOps

            

   

 

DevSecOps聚焦于把安全测试工具集成到开发管道中，然而，过于关注工具，缺少项目的上下文，意味着在安全和速度之间有一个权衡，当67%的开发团队每周甚至更频繁地发布代码，很难让他们慢下来。

你有DevSecOps吗？

• 安全和开发团队对彼此之间的流程具有可见性

• 安全测试不仅仅是SAST&DAST,还包括IAST&RASP，SDLC的其他组件（容器安全，云配置安全等）。

• 使用同一个产品管理平台管理结果

回到我们盖房子的比喻，DevSecOps就像在建筑房子的时候，准备一个需要修复的事情清单，但没有足够的信息来确认修复他们的顺序，甚至是否全部需要修复。

SecDevOps

              

 

SecDevOps把安全集成到开发流程中（注意，不是开发管道，那个是DevSecOps）。关注安全流程和开发流程的一致性。而不是仅仅关注工具，安全能被集成到每个阶段，工具可以提供支持，而不是被工具羁绊和限制。

你有SecDevOps吗？

• 安全和开发团队有一个经常性的，集成的交互（安全甚至可以加入代码审计！）

• 基于项目细节，项目被分配特定的策略

• 结果被自动排序，作为工作条目，被反馈回到开发工作流中

SecDevOps就像我们盖房子：事先定义好流程，保证在正确的时间检查，进行下一步之前，重要的问题要被修复，其他的部分能够根据优先级排序，后期修复，或者允许变为安全债务的一部分。

没有任何转型能在一夜之间完成，但到达最后的SecDevOps阶段不再是一个乌托邦式的梦想，当你把开发、运营和安全团队中的人、流程，工具结合在一起，就会是一个容易实现的目标。

  SecDevOps入门，是什么，如何做，为什么？

2020年1月15日

现在的问题是，这个世界满是坏人，也满是糟糕的安全（我们可以称之为不完美）。把这两件事放在一起，你会很快认识到，为什么平均每39秒，一个计算机设备会遭到攻击，在你跳过一段YouTube 广告，或者早晨穿上一双袜子的时候，有一段代码已经被攻陷了。这是因为人和计算机的不完美。但也还好，因为……

好消息是，世界也满是好人，你在这里，大概是想了解如何开始使用SecDevOps，意味着你可能也是一个好人。那你来对地方了！使用SecDevOps，你的组织能提高应用安全，智胜坏人，世界变成一个稍微好点儿的地方。

所以，我们可以开始了。

首先需要知道，什么是SecDevOps？

如果你听说过SecDevOps，那么你应该也听说过DevSecOps和DevOpsSec，看起来好像没什么不同，是因为科技行业喜欢用他们的命名习惯，把人搞迷糊吗？确实有点是（毕竟，为什么微软跳过了Windows 9？Windows Vista 从何而来？）。但这不是重点，实际上，在进一步学习之前，需要了解这些术语之间的重要区别。

1. DevOpsSec 是指大多数公司的现状。用来说明代码上线之后，应用安全的术语。也是90%的公司开始开始安全流程的地方，因为安全的人工过程和无法跟上现代开发管道的发展步伐，他们担心安全变成一个开发周期中的瓶颈。

2. 另一方面，DevSecOps侧重在SDLC中、构建和保护应用时所用的工具的集成。传统上，当人们考虑这些工具时，会想到Veracode和Contrast之类的漏洞扫描器。然而，随着DevOps工具链激增，保护它的安全工具也一起增多，如容器安全工具，像Aqua，Twistlock；云配置工具，像Fugue，Sonrai。

3. SecDevOps 把应用安全集成到开发过程中。SecDevOps是一个整体性系统，考虑到开发生命周期的每一步，从最初的设计阶段，到产品交付之后。因此，侧重于把应用安全程序的部署作为SDLC的一部分，而不仅仅是测试：这包括了解每个项目使用什么策略，验证他们的控制方法（手动或者自动），了解安全测试结果的分析等。

想像你在做饭，你需要正确的工具，配方，和食谱的操作指南来做一顿饭。不知道流程（SecDevOps），只有工具和配方（DevSecOps）作用不大，还有可能会搞得一团糟。

如何开始呢？

• 文化

SecDevOps首先是一个文化上的转变。对一些人来讲，文化转型常常听起来有些吓人，但当开始朝着正确的方向转变时，就没有什么可害怕的了。好消息是，我们知道开发团队非常擅长适应，这意味着更频繁地、交付更好的功能。这个世界需要更安全的应用，因为这是我们数字世界的基础。记得我们早些时候所谈论的那些坏人吗？有安全意识的文化是一件好事情。

当在你的组织内有了一个SecDevOps文化，应用安全变成了开发过程内在和自然的组成部分，不再是拖累开发速度的额外步骤。这是一个非常重要的思想上转变，如果安全被看做是一个额外的冗务，实际工作中就会走捷径，坏人就赢了。这就是SecDevOps为什么如此重要的原因。

• 策略

在了解SecDevOps是什么之后，你还要有个方法去部署它，那就是通过策略。谈到策略，大多数人首先想到合规，但实际上，策略反映了公司的风险概况如何与更广泛目标保持一致。什么是你组织的风险容忍度？如何缓解？如何控制？这些都会编码到你的策略中，影响如何执行你的SecDevOps程序。每个单独的项目内运营时就，策略给开发团队和安全团队提供了一个框架和上下文环境，作为一个好的SecDevOps程序的立足之点。

• 人

顾名思义，SecDevOps的核心不仅要集成流程，还包括负责生成、交付和保护代码的团队。

应用安全管理者花费大量时间在人工手动地管理工作，没有SecDevOps时，他们没有时间作为DevOps的战略合作伙伴。给应用安全管理者提供集中治理所有应用安全的程序，解放了他们，他们可以集中精力作为一个安全顾问，而不仅仅是一个安全守门人。他们可以主动地参与到设计对话和代码审计部分，或当问题出现，给他们所需要的信息，配合开发团队一起工作，在要求时间内解决问题，实现两个团队的目标。

在了解应用安全对他们项目的后果之前，项目管理者常常盲目运营。在交付时间上和预算上超支，导致项目交付风险。也许听起来有些矛盾，但通过SecDevOps集中管理和应用安全管理，分散了IT的管理，把日常的决定权放到项目经理手中，他们不需要变成应用安全专家，就可以做出明智的决策，把安全作为质量定义的一部分，让他们的团队交付高质量的代码。

开发人员，架构师，运维人员是在前线执行策略的人，你希望尽可能得简单地让他们去操作，就意味着融入到他们当前的工作流。不管是ticket系统，IDE，拉取请求或构建工具。此外，确信他们以双向的方式作为流程的一部分，这样你可以得到策略执行效率、以及他们是否已实施的反馈。

为什么重要？

SecDevOps是应用安全流程完全集成到SDLC中的最终状态。这并不是一个虚幻的未来，而是一个实际的方法，任何规模的团队都能从今天马上开始，确保他们能从更好集成应用安全中获益。如果你想更好地了解，你的团队和组织是如何开始，可以和Wabbi SecDevOps的咨询专家们喝一杯虚拟的咖啡，好好聊聊。

 

 

罗马不是一天建成的，你的SecDevOps也不是

2020年，2月1日

在过去的十年内，随着数字化转型的加速，软件开发战略已经经历了自从软件开发商业化以来的最大转变。DevOps要求更快地满足市场要求，但DevOps团队发现，安全的速度太慢了，无法集成到现代化的开发管道中。然而，数字化也使信息安全比以往变得更重要（更复杂），当安全团队和开发团队试图一起工作时，产生了分歧。

“开发团队和安全团队之间的不一致，新的功能被延迟推向市场，导致错失了很多商业机会。在某些情况，去除双方之间分歧的压力导致增加新的漏洞，因为开发团队的工作要遵从于安全策略和标准。”（麦肯锡，网络安全：数字化企业的关键，2019）

传统上，安全检查点位于生产和发布最终产品流程中每个点之间。在瀑布式环境中，有时间在不中断工作的情况下去完成这些工作；在现代的DevOps管道中，57%公司每周或更频繁发布产品，团队被要求在速度和安全之间取得妥协。

为平衡这个问题，公司现在转向SecDevOps，将安全从阻碍速度的大的人工检查和合规复选框中移出，转而观察整个应用安全流程，使用自动化把安全集成到SDLC中。当他们使用这种基于过程的方法时，工具提供支持，而不是由工具和他们的限制来推动，不仅生产出更安全的工具，而且通过降低以往盲目地满足非功能要求中与安全相关的费用，他们得到了一个很高的投资回报率。

然而，应用安全流程集成到DevOps中，不是一夜之间就发生的，它花费了时间和意愿，梳理整个公司的文化，支持必要的变革。人们必须被激活，得到好的培训，合适的管理，这样他们能在新系统内有效地工作，流程必须适用，工具集要建立，罗马不是一天建成的，SecDevOps也是如此。

SecDevOps，不只是一个工具，而是一个运营方法

关于这三个词的不同有争论，事实是，他们只是进化到SecDevOps过程中的不同步骤。90%的公司从DevOps+安全开始，那时，直到代码上线，才开始安全的工作，就像带领公司玩应用安全轮盘赌一样，根本不知道花费多少钱，花费多长时间能修复这些问题。

通过在流程中更早地部署安全实践，他们在开发的最初阶段就出现，甚至早于第一行代码。这不仅仅是尽早测试，而是在每一个阶段提供信息，去执行、教育和管理。这意味着消除最简单的错误，（如错误配置），了解在单一项目、版本、环境基础中，哪个漏洞是最严重的，设置解决漏洞的最后期限。这必须是一个整体的方法，把安全嵌入到开发生命周期的每一步中，就像Gartner说的“IDE 插件不是一个附属品，相反，根据DevSecOps精神，他们尽早地发现简单的错误”。

需要注意的是，大多数开发团队想在安全中扮演主动的角色，他们已经看到了在工作流中，主动管理运营的好处，因此DevOps的诞生。集成应用安全也没什么不同，相比最终丢弃大量代码或事后修复，特别是频繁的代码发布增加了额外的复杂层，在开发时阻止安全漏洞更容易，更实用，成本更低。

向DevOps转变不是那么漫长，Dev和Ops 很容易沟通，就像美式英语和英国英语，虽然有些不同，但双方都能很快了解彼此的意思。向SecDevOps转换就更复杂，开发团队说美式英语，安全团队说着某个原始部落的语言，因此，首先SecDevOps是一个文化转型，每个部门都要学习一个通用的语言，这样大家才能有效的沟通。

走向SecDevOps

当一个组织评估他们在SecDevOps成熟度曲线上的位置时，他们要评估三个参数人，流程，工具。你会注意到人是第一位，那是因为没有有效的团队，把安全织入到DevOps中的流程和工具无关紧要，时刻记在心里，你能够位于一个领域成熟度曲线中一个阶段，也能位于其他区域的不同阶段。

不管你是在一个单个团队，或者一个大的企业，都够能沿着这个曲线开始实施。

DevOps+Sec

 

 

人

• 保证团队成员了解安全和合规并不一样，合规是最小要求，安全关于产品如何运转。

• 培训不等于意识，教会团队成员安全最佳实践非常重要，每个开发人员应该知道这些，形成一种负责任的文化更好。

• 当在早期和经常执行扫描时，会对个人自信和团队精神造成损坏，扫描结果应该用来教学，而不是责备。

流程

• 列出控制和指导之间的不同，清楚“必须”和“可能应该”的区别，这样团队成员能够在需求范围内拥有自主权。

• 在项目开始之前，就保证策略被适用于项目的每个部分，防止团队成员尝试遵循不适用的策略而浪费时间和产生挫败感。

工具

• 工具箱清单—通过组织，或者如OWASP和NIST 计算器等开源工具来实现。目标是透明、优先级排序、集中管理安全策略。

• 想出如何使用SecDevOps工具集来补充流程，如何使用工具实现自动化、跟踪项目、改善部门之间的沟通。

• 把你的信息从Excel，Word，PDF中取出，集中管理工具提高了整个公司的可见性和参与度。

DevOpsSec

 

  

人

• 创造一种鼓励团队成员对安全编码感到骄傲的文化，考虑采用某种形式的奖励系统，不管怎样，只要能优先考虑安全就行。

• 挑选一个热情的布道者，帮助他变成安全拥护者，培训他们，使他们自始至终能引领和捍卫安全的重要性。

• 确保责任心是一个核心价值观。如果你写了代码，你就要修复代码。这保证合适的人从错误中学习，不会变成未来的风险。

流程

• 整合自我证实。让团队深入了解策略，邀请他们提供反馈，并在开发新策略时，考虑这些反馈。

• 在当前的工作流中集成工具，这样团队成员不用离开工作环境，把安全改善工具提供给开发人员，不要让他们去外部寻找。

工具

• 如果你还没有扫描，那现在开始。当有这么多工具在手边，可以加速流程和改善结果，人工扫描在有效性和效率上都不理想

• 扫描应该超越基本的合规扫描，但不要太频繁，以免变成负担。找到正确的平衡，不同团队，这个平衡点也不同。

• 学习对扫描中发现的漏洞进行排序。生成有意义的修复，了解什么时候漏洞是一个可接受的风险，完美是不可能的，我们要放弃完美主义。

DevSecOps

 

    

人

• 设计合作，千万别这么做，做个计划。每个部门何时及如何去寻求其他部门的建议和合作？把一切都摆出来。

• 从组中收集反馈，坚持透明。透明并不总是容易做到，这是一种文化价值观，必须通过时间、重复、证明来逐步培养。

流程

• 在拉取需求中集成安全，要求反馈潜在的变更，促进围绕将安全集成到开发生命周期中的对话

• 确定在哪里能减少安全债务，哪个方面的安全债务是可接受的，哪些是不可接受的，学会排序。

工具

• 对开发的每个阶段制定安全标准，处理每个阶段的安全问题，避免生成新的障碍。

• 借助于人们正在做事的方式来把安全集成到每个阶段，这产生了责任心，给下一个阶段输出安全的产品

• 发现对自己工作有效的方法来集成工具，不要试图在圆孔里钉方形钉子，在每个部门寻找适合当前工作流的工具

SecDevOps

 

 

 

人

• 使用人工智能和机器学习，这样人们可以把精力放在他们最擅长的事情上，让计算机做繁重工作，在可行的时候，释放出时间和大脑空间。

• 提供智能战术，帮助指导团队成员通过流程。这能帮助团队成员解决问题，保证跟上变更的步伐

• 提供所需要的有目的的培训，保证每个团队成员跟上步伐，使用错误作为教学时刻，作为指导，知道什么时候需要更多不同的培训

流程

• 自动化治理被用来指导流程。很有必要去保证产品的完整性，但不要白白放着有价值的数据，要用起来。

• 设置好质量门，保证产品符合需求。而不是起到限制作用。使用他们和当前的产品参数对比，确定修复哪一个功能

• 改善策略推荐，既然整个团队在关心安全，在当前的项目和威胁图景中，决定是否策略适用。

• 安全分析能被用在每个阶段，保证产品的安全，避免以后减少安全问题

工具

• 使用工作流平台，帮助流水线操作，当SecDevOps有效时，避免工作流工具，有太多的数据需要管理。

实现SecDevOps，它看起来像什么？

SecDevOps的最终目标，允许人们更有效的工作，改善流程和增加集成工具的全部目的是帮助团队更聪明地工作，而不是更辛苦的工作。允许创新和改革蓬勃发展，在开发中而不是在后期，解决安全和合规问题。

当DevOps的整个目标是尽快地通过生产流程，任何操作着罗盘的安全守门人，看起来都是违反直觉的。就像乌龟和兔子，一个从一开始就包含安全稳定的、良好执行的工作流常常证明，比一个速度快的、流程彼此隔离、生产出有安全缺陷、需要回炉的产品的工作流更有效。

需要记住的事情

在SecDevOps中不存在完美

完美的代码不存在，完美的安全是一个神话。在业务、开发、安全中，不存在没有风险的事。完美不仅是不切实际的，也是不可能的，相反，我们必须关注修复大的问题，按我们所能做到的最好来转移风险，持续前行。

使安全适用于开发，而不是相反

重要的是，开发团队应该遵守的安全措施应该集成到他们的流程中，而不是让他们在当前工作流之外去寻找安全工具，保证在平台和工作流内部，工具容易访问和使用。

安全和开发相同点多于不同点

虽然他们也许说着不同的语言，驱动他们进程的基本的信条是一致的。

• 策略只是安全编码标准

• 漏洞就是缺陷

• 需要修复的条目只是技术债务中的安全部分

SecDevOps把他们放在同一页，这样关于安全，他们是战略性的，而不是因为信息不及时来被动应付。

 

什么是应用安全策略？

2020年，3月1日

当前超过以往任何时刻，信息安全是每一个业务单元的首要考虑因素，开发也不例外。在这个Equifax 数据泄露之后的世界里，我们了解到，好的应用安全不仅仅是工具，而是在正确的时间、传递正确信息到开发管道中的流程。这个思维方式导致很多公司开始尝试SecDevOps，把安全集成到开发流程中。

这里的关键词是“正确”，特别是关于信息，事实上正好相反，确实，我们需要大数据，但不要把信息和数据搞混。

• 数据，事实上的信息（如测量和统计），用来作为提问、讨论、或计算的基础。

• 信息，从调查，研究或指导中得到的知识。

换句话说，数据是许多条信息，像单个比特，没有组织或者上下文。当他们得到这个结构，例如代码行，他们变得有意义和可操作，这是能用来做决策的信息。这也是为什么我们的行业叫作信息技术，而不是数据技术。

在应用安全，数据是安全测试结果，上下文是一种策略，没有上下文，无法理解安全测试结果对公司、分支机构或特定项目意味着什么。

什么是应用安全策略？

好的，咱们先从它不是什么开始：合规、业务工作流规则、检查清单……，现在你清楚了，这些也许是策略的下游功能，如果你开始就认为策略是上述功能之一，你就会仅仅把它看作你必须做的一件事情，而不是如何实施应用安全的战略工具。

我们的好朋友Merrian Webster告诉我们，策略是“根据被给的条件，从备选方案中选出的明确的过程或行动方法，指导和决定当前及未来的决策”。但重复一次，策略不是规定或者检查清单，而是关于如何管理特定情况的指导方针—主动的和被动的。

一个策略的核心是公司风险概貌的反映，提供如何执行、何时执行和如何控制的指南。策略不应该是完美，而是在80%的时间里有效的指导方针。因此DevOps和应用安全团队能够把他们的重点放在20%，在那里他们无法找到现成解决方案，而不是全部依靠策略，或者不依靠策略。

还有其他名字的玫瑰

策略的概念已经存在于开发中，被称作不同的另外一件事：编码标准。

因此当开发认为策略是编码标准时，不仅减少了使用中的摩擦，而且提供了应用安全集成到SDLC中的自然切入点。

• 设计 了解哪些策略和项目相关，如何影响项目交付

• 代码 和开发人员共享策略，允许他们在拉取要求时，提供反馈

• 构建 人工或者自动化检查，了解代码是否符合提交的标准

• 测试 识别安全缺陷，在发布前修复必须修复的点，并对其他的作为技术债务的一部分做排序

• 部署 验证代码符合设置的发布标准，如果没有，有合适的处理措施

• 维护 持续识别新的安全弱点，持续对安全债务重新排序。

• 运营 从应用安全的角度，在策略效果上得到持续反馈，实时了解管道的运行状况。

策略提供了如何在每一个阶段管理数据，并变成可操作信息的上下文。回到Merriam Webster，我们被提醒，策略是“行动的方法，指南”，意味着不是一个明确的规则，只是一个指南，也就是说，对策略没有被执行时，我们了解其情况非常重要，你就可以对如何处理它做出明智的决定。

为什么策略有这样坏的名声？

策略一直存在于他们影响的世界之外—软件开发—太久了。常常被放在Excel和PDF文件中，每个季度分发下去，缺少和他们影响的工作再联系。因此，不奇怪他们常常感到渴望和难懂，一个好的策略根植于行动，如何、何时执行和控制，当不生效时，如何管理。

• 如何执行   什么是指南，我如何实施？

• 何时执行  策略在什么情况下适用

• 什么是控制  人工的还是自动的，什么是测试，多久进行一次？

• 例外处理 谁需要批准，什么时候能修复？（如果可以的话））

当重点放在可执行的策略，他们就可以在不中断工作流的情况下，集成到当前的开发流程中，甚至会提高开发生产力，减少项目交付风险和潜在的“消防演习”，同时生成更好的代码。

一个好的策略会进化，开发优先级和安全风险从来都不是静态的，因此策略也要一直成长，像活生生的实体。随着威胁图景的变化，一个公司发展或进入一个新的方向，效力是可测量的，策略也将继续改变。

 

使用SecDevOps来加速漏洞管理

2020年，9月10日

软件漏洞围绕着我们，这已经是常态，但自从新冠疫情给全球带来了巨大的变化，小小的漏洞，能导致任何规模的企业业务中断，这是一个不会短时间消失的问题。后新冠时代新的预测，到2021年，估计每年信息安全犯罪的成本会达到6 万亿美元。而且随着整个世界向远程工作方式转移，为了保障软件开发持续，防止业务中断，数据泄露的平均成本增加了137000美元。而且这不是少数人的看法，80%企业估计会受到攻击。

这些数字表明，信息安全不再是锦上添花的事情，而且在开发之初就不可缺少的部分，不能再等到事后诸葛亮。新冠疫情带来新的远程工作方式，即使我们最终摆脱了疫情，这种模式仍会持续下去。开发和安全团队开始无法同步工作时间表，导致曾经的人工安全流程更加痛苦。SecDevOps必须部署，不管员工的结构如何，保证应用安全和开发团队能够全力运营。

SecDevOps对我们有什么意义？

SecDevOps的目标是使开发人员和运营把生成更安全的软件作为日常工作的一部分。通过把安全集成到开发生命周期每个阶段，团队能够主动地阻止和管理漏洞，而不是等代码上线之后。那就太晚了。当组织从DevOps向SecDevOps转变，带动每个人了解安全不是可选择的，而是必须的。给他们提供需要知道的信息，能够有效和有效率地执行。SecDevOps允许组织稳定的扩展应用安全，减少业务风险。不仅仅减少攻击面和机会，而是在整个项目中运营中，降低项目交付风险，缩短推向市场时间。

你不能在没有SecDevOps情况下，管理漏洞

在一个SecDevOps系统中，团队是否工作在一个地点、分布式的、或者完全远程，部署和加强安全策略从来不是一个问题，把安全流程集成到SDLC中，保证开发从一开始，就了解他们项目和功能的正确策略。自动化不仅仅保证实施了正确的控制，而且基于每个项目的严重性和重要性，对漏洞进行排序，而不仅仅是待修复的一个名单。

没有SecDevOps，漏洞管理系统无法根据应用的需求，缺少有效管理安全债务的上下文信息，最后当不符合安全标准时，无法提供构建管理。保持着对人工检查的依赖，跟不上今天管道速度的步伐，最后只能把问题推到其他地方。

为减少昂贵的周期最后阶段的安全检查，提高每个开发周期的输出，SecDevOps功能对下列高水平的关键点进行排序：

• 多为一，一为多。如果安全，开发，和运营是三国演义里面刘关张的话，SecDevOps就是诸葛亮，识别应用安全问题，把三个人放到一起来解决问题。（或者一个更现代化的解释，如果安全，开发，运营是查理的天使，SecDevOps是查理，能决定哪个天使是哪一个）。

• 应用安全策略必须在整个公司内得到良好的定义。良好的定义并不是意味“很多”。而是意味着清楚的知道什么时候该应用。如何和项目的战略关注点达成一致。这允许所有的参与方了解每个项目的每个阶段，需要做什么，才能按时交付有质量的产品。

• 扩展SecDevOps的关键是自动化。“人，流程，工具”并不是软件中的新咒语，虽然最初的几步，可以通过简单的流程来实现，但最后，为了跟上今天软件开发管道的速度。SecDevOps流程必须在SDLC中实现端到端的自动化。没有自动化和编排，不管企业的规模有多大，当扩展到整个企业时，SecDevOps会变成另一个瓶颈。

使用SecDevOps成熟应用安全程序

虽然SecDevOps实际上很容易部署，也不是一个一劳永逸的系统。你必须持续受到反馈，提高你的应用安全和软件开发流程。一个成功部署的SecDevOps程序会保证你已经闭环了反馈流程，不仅监控实时的策略合规，阻止瓶颈，提供预先分析，计划好漏洞修复工作。

虽然在DevOps文化中，漏洞管理流程趋向于被看成是拖累开发进程，事实上，那是一个离事实最远的现实。即使最简单的SecDevOps部署，也会很快得给公司展示出，他们不需要费太大力气就可以交付更安全的代码，把应用安全策略集成到当前的工作流中，控制技术债务中的漏洞，甚至阻止漏洞生成。

 

 

今天，开始把安全集成到DevOps中

2020年，9月21日

你可能会说，SecDevOps是一种和时间一样古老的方法。DevOps—毕竟，一开始也是由于安全导致凤凰项目中的问题。然而，在过去的5年里，它逐渐变成焦点，截止到2019年，17%的公司已经完全拥抱了DevOps，其他的69%在DevOps的不同阶段已经认识到，如果不把安全包含到DevOps中，他们无法完成转型。

这是为什么向DevOps转变并不总是容易的一个原因之一，超过50%报告“管理和DevOps转型所需要的人员，流程和技术非常困难”。不把安全包含在内，组织会继续生成DevOps本来要消除的瓶颈，这是安全希望去掉的一个名声。

但更多和更快的DevSecOps工具没有修复这个问题，没有合适的端到端自动化和编排，无法完成SDLC的安全集成，这也是SecDevOps产生的原因。在2020年Q1，随着在家工作增长了775%，许多DevOps转换已经被设置成超光速推进，因为DevOps实际上为远程工作量身定做的，使SecDevOps战略成了2020年必备战略。

就像我的奶奶总是提醒我，欲速则不达，她的观点不是做事要慢，而是正确的方法，因为在最后，当你正确的做事，你节省了整个的时间，那也是SecDevOps出现的理由。

2020马上结束了，为什么我要把SecDevOps放在最重要的位置？

很清楚的是，如果你在2020年之前，没有优先把安全集成到SDLC中，你会大大落后别人。因为10个有九个安全事件由于软件代码中的缺陷导致。但还不晚，事实上，SecDevOps是一个持续的进化，能够分阶段解决。随着这个世界转向远程工作，一个超过新冠疫情的工作方式的转变，应用安全不再是DevOps中可有可无的东西了。

项目经理持续关注按时和按预算交付他们的项目。在过去，这意味着他们可以等待，直到产品开始安全测试或安全测试之后。但随着DevOps要求的节奏，57%的公司要求每周构建，甚至更频繁（5%是每小时都构建一次），如果安全没有被包含在每一步，他们会面对一个无法逾越的安全债务，将使公司失去DevOps的全部好处。

但面对这么多漏洞的挑战，开发团队和安全团队如何排序他们的修复措施？没有项目级的上下文信息和可视化来排序漏洞，团队在黑暗中运营，无法理解应用最严重的漏洞是什么？以及是否已经被解决了。SecDevOps，不管你在成熟度曲线的哪个位置，提供了漏洞名单黑暗深渊中的一盏灯。

通过理解这些引入到特定应用的风险漏洞，不仅仅是在漏洞的世界中，安全团队能够明显地减少错误报警，确信开发团队在工作流中为漏洞修复做了排序，减少了信息安全和项目交付的风险，今年中你还能获得一次胜利。

如同大家普遍认可，DevOps的核心信条是减少交付到市场的时间和提高生产力，已经和快速移动混淆了。（快速移动，打破事物，在facebook，确实有效地阻止了数据泄露……或者没有）。上市时间是确保产品准时推向市场，所付出的时间和努力，这是一个多维的函数，快速移动，只是时间的单一维度。

如同我奶奶总是提醒我，“欲速则不达”。她的观点不是做事慢，而是做正确的事，因为到了最后，当你做事的方法正确，你就节省了整体的时间。那也是SecDevOps出现的原因。它不是关于“以安全换速度”或者“左移”，这些都是一个维度，而DevOps，是关于在正确的开发时间做正确的安全工作，减少SDLC中整体浪费，这些浪费包括，随着时间推移，非功能的需求膨胀。应用安全预算，产品崩溃，从重写代码到安全事件。

当你遵循正确的端到端流程（水，肥皂，抹布，然后洗碗机，而不是直接放进洗碗机），你不仅会得到一个正确的结果，还会节省整体的时间。即使是我，也已经屈服于现代洗碗机“跳过漂洗”的诱惑。我很快认识到，仍然有一些事物，当没有被预先清洗，会带给我更多的刷洗工作，甚至发臭的情况。而现代的软件开发管道没有什么不同，没有有效生成安全代码的灵丹妙药，要理解每个项目中每个漏洞的上下文、复杂度、成本，这也是你为什么需要SecDevOps。

安全开发运营意味着你从头开始

如果你没有在开发生命周期的开始就集成应用安全，你只是把问题转移到了某个别的地方，因为你从来没有理解管道中上下文、复杂度、成本。SecDevOps—安全的开发运营，确信安全，就像每一个其他的功能要求，集成到开发的每一步中。

当团队没有在功能需求设计时，就在流程中集成SecDevOps，他们最后会耗尽解决安全问题的带宽。但如果在开始就考虑，安全和开发团队都能得到完全部署和集成应用安全程序的好处。使他们摆脱了单纯的漏洞管理，而是去理解阻止他们行动的策略，了解应用是否符合将要发布产品的组织标准。

在今天的软件开发管道中，即使他们不是完整的CI/CD—没有终点，而是持续改进。通过将端到端集成到开发管道中，SecDecOps实现这种持续的反馈循环，安全和DevOps团队不仅仅减少风险，而是提高开发人员的生产率和上市时间。

没有安全集成，没有完整的DevOps管道

随着提高运营效率，消除作为DevOps基础的瓶颈，DevOps很清楚的表明，没有安全的SDLC是不完整的，事实上，Gartner报告，2022年，90%的团队将把安全加入到DevOps实践中，而今天的只有40%。

如果您今天不开始这段旅程，安全集成差（不根本不集成），将会使你落后竞争者，上市时间和生产力都会受到影响。

 

 

穿透DevSecOps噪音

2021年，2月8日

应用安全的重要性持续得到更大范围的关注，42%的组织，由于软件缺陷而经历了外部攻击事件，35%说来自于错误的web应用。组织仍在努力解决问题，2020年上半年，报告的未修复漏洞中，64%涉及到2018年甚至更早的已知漏洞。

和工作流中断相反，许多公司接受潜在的信息安全攻击风险，尽管知道这些缺陷可能会成为恶意攻击者的攻击点，在软件开发中，安全仍然是一个事后弥补的思路。并不是工程师或者产品经理不考虑安全，而是了解和管理今天的安全需求，没有集成到他们的工作流中。

“也许这个噪音最大的贡献者就是DevSecOps市场本身。

但为什么几乎没有，在构建应用时，就像其他的质量控制一样，考虑把安全集成到工作流中？并不是因为组织不能生成安全策略并跨开发团队和平台来管理他们，而是因为关于如何开发安全软件，需要做什么，在业界内有太多噪音。换句话，解决方案导致问题更大。但当你退一步去识别DevSecOps噪音的原因时，你就能消除干扰，在开发流程中看到软件安全的本质，而不是一个在事后坚持的实践。

 

噪音#1 工具

也许最大的噪音贡献者就是DevSecOps市场本身，“买我，我能为你解决那个单点问题！”。DevSecOps工具和平台的提供者，在过去的十年内，呈指数级增长，提高了产品的数量和水平，也造成了这样一种价值理念，更多的工具=更好的安全。但这不是构建安全软件的方式。

良好的应用安全从工具支持的健康流程开始，而不是相反。否则安全和开发团队会被数据淹没，没有上下文来把数据转换成可操作的信息，确实，不断发展的DevOps管道已经要求扩展自动化安全测试，然而考虑到因为“你有工具，你就有安全”的理念，导致懒惰的应用安全，和错误的自信意识，认为你的应用是安全的，因为你已经修复了工具告诉你的事情—而不是对你、你的应用和你的公司来说最重要的事情。

噪音#2 合规

合规和应用安全安全常常混淆在一起，确实，你必须要做很多事情，像PCI，HIPPA，然而，如果那是你为安全做的一切，你只是在掩盖“低门槛”，让你的代码和公司，面对不仅仅是合规风险。

良好的应用安全是关于到DevOps效率和应用健康，是关于做出正确的决策，保证你的代码符合组织对风险的容忍度，并准备成为SDLC的一部分。它变成了按时、按预算交付代码时的战略资产。

噪音#3 文化

不用怀疑，开发团队的每个成员都了解，安全必须作为一个开发过程的内生部分。然而，他们的理解有一个直接的冲突，并有对应的文化支持。一个最近的研究发现，他们发现安全是一个“让灵魂枯萎的杂务”和一个“无法忍受的过程阻碍”。并不是说开发人员不想结合安全，74%的人是流程的一部分，或者希望如此。而是他们缺少能在他们工作流中管理而不生成额外负担的方案。

良好的应用安全不仅仅是堆砌工具，增加对开发人员的培训，也不是依赖安全工程师或团队中的DevSecOps专家。这些努力只是把手指放到大坝，而不是解决如何加固大坝本身，通过在工作流中提供信息和自动化来设计、开发、和部署安全软件，安全变成代码质量的一部分，而不是交付的障碍。

一旦安静下来，然后呢？

当你关闭了DevSecOps噪音，你能够诚实的看待你的软件开发流程，了解如何以及在哪一点自然地融入安全。你会看到，开始打造安全开发运营（SecDevOps），将不仅可以降低你的安全风险，而是整个项目和业务风险。你可以使用简单的流程、策略和工具，立即开始。 （完）

原文始发于微信公众号（安全行者老霍）：应用安全介绍之Wabbi