试想一下，你在一个应用程序交付中实施了 DevOps 工程实践，你已经到达开发流程的末尾。
此时，安全团队发现了即将上线系统中存在严重的安全漏洞，并且传统防御手段无计可施，于是提出了报告。
现在，你必须打破原本流畅的DevOps流程，追溯并要求开发人员修复该漏洞。
DevOps时代，软件的交付频度 空前提高，您有没有准备好，与之对应的软件安全模式?
3月26日，选型宝邀请Synopsys 高级安全架构师 杨国梁 ，做了“如何打破枷锁，让安全开发成为一种习惯？——DevSecOps理念、工具与实践”的主题分享。
这篇文章里，将整理本次直播分享的主要内容。
为方面阅读，这里先介绍一下Synopsys：
关于Synopsys
在Gartner和Forrester的相关评价中，Synopsys都被评为是应用安全领导者的地位。
在2018年Gartner 应用安全测试产品核心能力在DevOps下的得分中，Synopsys位列第一。
各应用安全测试产品核心能力在DevOps下的得分
下面就是关于本次分享的文字实录。
一、DevSecOps落地的关键挑战是什么？
相信做过安全，或者做过开发，或者说在这里面做过协调工作的人都会深有感触。
当你想推进一些安全的检查，或者说是一些额外检查项的时候，研发人员的抵触情绪非常的重，并且把将之视为一种枷锁、一种束缚，拖慢研发进度的罪魁祸首。
因此，落地DevSecOps的关键挑战是：
“怎样让工具去适应开发人员，而不是背道而驰”
不要试图改变程序员和测试人员的工作方法，也不要去增加他们额外的工作负担，否则将破坏DevOps的协作性和敏捷性，注定会成为众矢之的，让DevSecOps最终无法落地。
二、完整的应用安全包含哪些内容？
想要在研发流程中，有机融入安全因素，进而真正落地DevSecOps。
我们先来看一下，整个开发体系里面在不同的阶段，不同的点上，应用安全可以做哪些事情？
1、计划阶段
首先，在做需求的阶段，我们需要做的是安全需求、威胁建模、风险分析。
2、编码阶段
其次在你写代码的时候，你可能需要在IDE上做一些集成检查，比如静态分析，再就是在提交代码时候的静态分析。
3、代码构建阶段
然后在代码构建的时候，你可能会需要做完整的静态分析以及软件组成分析，你用了哪些开源组件？用了哪些第三方的组件？这些都在你的代码里，但却不是你自己开发的。以及如果需要的话做一些人工的代码审查。
4、测试阶段
在测试阶段我们可以做的事情就更多了。动态测试、交互式安全测试、如果你需要的话，这时候可能再做一个完整的静态测试。以及模糊测试，fuzz testing，然后是API testing。其实现在大家知道越来越多的业务承载在API上，所以对API的安全性的测试是很有必要。
5、发布阶段
然后到了发布阶段，包括安全配置，打包部署。
6、部署阶段
然后到了部署阶段，会有一些运行保护的手段，以及大家可能比较熟悉的搞一些第三方会做的渗透测试。
7、运维阶段
再就是你的运维阶段，以上说的那些内容，如果适合的话，可以在运维阶段不断的做，持续的做。并且实时监控你的软件会有哪些问题，包括打补丁等等都属于这个阶段的工作。
漏洞奖励计划，当你自己的力量不够，会希望借助于社会上的一些力量，一些白帽子帮你一块众测，来发现你系统中的问题，你对此给予一定的奖励。
还有一些红军蓝军的对抗的形式、RASP运行时保护。
三、 落地DevSecOps，安全工具应该遵循怎样的理念？
一个比较流畅的CI/CD流程，加上了这些安全项之后，怎样才能不破坏DEVOPS的敏捷性？
SYNOPSYS认为落地DevSecOps，安全工具应该具备左移、低侵入等理念。
1、左移（shift-left）：
在软件开发流程中，尽可能早的开展安全活动
尽早发现关键质量缺陷和安全漏洞，在成本最低时加以修复就是安全左移（shift-left）的核心概念。我们在应用程序被生产出来的每一个环节，从部署，测试，构建，编码，甚至架构设计阶段都为企业提供业界最佳的安全测试工具和服务。帮助客户更快更好的生产安全的应用程序。
2、低侵入、无感知：
把安全能力无缝融入开发环境、开发工具中
SYNOPSYS的工具与多种开发环境和开发工具集成，让安全能力“无感知”的融入开发流程，包括：
? IDE(如VisualStudio、Eclipse、IntelliJ、RubyMine、 WindRiverWorkbench 和 Android Studio)
? 源代码管理 (SCM) 解决方案
? 问题跟踪工具(如 Jira 和 Bugzilla)
? CI 构建工具 (如Jenkins和Azure DevOps)
? 应用生命周期管理解决方案(ALM) 集成。
四、 借助自动化测试工具，DevSecOps落地的几个例子
怎么借力自动化测试工具，把传统上被研发视为是束缚的安全手段，有机融入研发过程，变成一些研发的好的习惯，SYNOPSYS分享了一些DevSecOps落地案例。
1、静态分析
首先是一个静态分析的例子，集中式分析的场景。工程师从IDE提交了代码，然后Coverity进行了捕获，进行了分析，把分析结果提交，工程师再到通知平台去查看缺陷。
举一个例子，大概100万行的代码，从整个的流程完了大概半个小时。查看完了缺陷之后，工程师再去修复代码，再重新提交。
紫色的框里面的部分工程师是没有必要知道。做的好的一些公司可能每次构建之后再继续做静态分析，我们上图的案例中，数百万行代码的项目，每30分钟左右，就可以获得结果；但我们现在看到多数的公司，可能它都是为了节省一些资源，会把这些分析的工作放在夜间做。
那么第2天工程师还是要去平台去查看这些缺陷，他还是要习惯这样一个工具。这里面跟DevSecOps有什么相违背的地方？一，是它不够快。二，是工程师还要习惯这个叫Coverity这样一个工具，他要到Coverity平台上去检查它的结果，增加了侵入性。
有什么改进的方案？
首先，我们可以在IDE端里面做这件事情。工程师本身就是要在IDE里写代码的，在IDE本身分析。这个分析只分析他改动的那部分，所以从30分钟变成了几秒到一两分钟这样。
然后在IDE当中直接查看结果，这跟工程师的编码习惯是一致的。如果有问题，他在IDE上直接就修改，如果没问题再把它的代码入库。
所以在整个流程里面，这个工程师并没有感觉到，引入了一个别的工具，他只是在不断地写自己的代码，不断地修正自己的代码而已。
这样做完之后好处其实很明显，工程师修复问题的时间缩短了。从上个例子里面的半个小时，甚至一晚、一天之后，变成了当前就能马上修复。
工程人员也不需要去熟悉另外一个工具,开发人员无需访 问Coverity平台，在熟悉 的IDE/编辑器中确认问题。对他没有造成侵入，对他的工作习惯也没有做修改，而且他的代码质量也得到了提升。
下面这张图是Synopsys总结的一个静态工具的高层级的工作流
从IDE端，你需要开哪些规则，可能是开一些信心程度非常高的、误报非常低的，一直到你生产的环节需要开哪些，因为你毕竟在整个系统编译的时候，还会有一些跨文件、跨函数等等的问题，还是需要再集中编译的时候来发现。这是一个完整的建议。这些红色和绿色的点，绿色代表说你在这些位置可以去做一些数据的采集，不断地完善你的整个流程。红色的这些点意思是说有问题出现，可以入到问题追踪系统去。
对于用户来说，如何衡量静态工具的优劣？
Synopsys认为静态工具的误报率一定要足够低，才能推进DevSecOps，具体数值参考OWASP Benchmark 。
这个图的横轴代表误报率，纵轴代表真实的抱对了的比率，比如说一个100行的代码里面，埋了100个问题，其中50个是真的问题，50个是假的问题。上面这条虚线的意思就是瞎猜，你100行全部标成有问题，得分就是50个全报对了，50个不该报的也全报。
那衡量工具的时候其实很简单，你只要看这个工具的得分是不是越来越趋近于左上角，该报的都报了，不该报的一个都没报，那就行了。目前Coverity的得分是业界最高的，有84%。
关于误报与漏报的平衡原则：
安全测试工具找出来的问题并不一定100%都是准确的，以静态工具举例，市面上常见的静态工具主流的误报率基本上是在3~4成。也就是说你发现报了10个问题，其中3~4个有可能都不是问题。而当你研发人员去看这10个问题的时候，他起码30%~40%的时间都被浪费掉，去排查本来不应该他做这件事情，这些是误报的。
当误报很高的时候，是没有办法推进DevSecOps这件事情。
这个时候，面临误报和漏报的取舍问题。常规观点是“宁可误报，不可漏报”。这个东西多数出自于安全团队，或者说再往上说一点，多数出自于领导之口，这里面背后可能蕴含了一些逻辑，就是我不愿意承担漏报产生的后果，并且我不管你花多少代价，我不管你效率怎么样，我只要一个结果就是没有漏报。
Synopsys给出的建议是：优先考虑低误报，逐步完善漏报情况。
只有误报的足够低，研发人员才愿意用。在Synopsys整个的安全防御体系中，有一个概念叫defense in depth，纵深防御。你可能这个阶段漏掉了一些东西，但是被你漏掉的东西，在下一个阶段，比如说动态测试的阶段，比如说交互式测试的阶段，它可能会被补上。
因此，没有必要因噎废食说在某一个环节没有办法做到尽善尽美，整个事情就不做了。
同时DevOps带给你的另外一个好处就是部署快，意味着修复问题的速度也快。那你如果能发现一个漏报的情况，你再下一个迭代中迅速把它修补掉。
2、SCA（软件组成分析）
第二个例子是软件组成分析的例子。工程师在IDE上引入了开源的代码在当前进行识别，并且检查有没有违背使用的规则。
一些大的公司可能会制定自己的开源的策略，因为开源不是你拿来则用的，里面有很多像安全漏洞的问题，还有一些法务许可证的问题。比如说你用了要把自己的代码也开源出去，这是明显不行的。
所以一些公司会提前制定好他们的开源的策略，并且把他们的策略一以贯之的贯穿在他整个的开发体系里面。
而开发人员最好在刚引入的时候就知道他能不能用这个组件，在IDE里面通过检查，我们可以告诉他说你的违规了，不能用，根据我们的建议，他可以重新选型，应该用哪个开源组件。如果都OK了，再源码入库。
这里面其实解决了很多的问题。因为我们举个例子来说，如果你用有漏洞的版本，并且你的开发都已完成，入库环节，你再检查发现有个严重的安全漏洞，所以只有要打回去重新走一轮这个过程，这必然违背了DevOps快、低侵入这样的一个原则。
3、IAST (交互式应用程序安全测试)
刚才的例子都是在编码阶段，IAST讲的是在测试阶段，大家可以看一下下面的流程。
研发人员写完了代码，做完了编译，打包好可以以二进制的形式做一些动态测试的时候，我们把一个Agent放在你的程序上面，通过这些程序的一些插桩，实时地结合你自己的功能测试。
因为每个公司肯定都是要做功能测试的，所以这个工具优势就在于，你在做功能测试的同时，它就把所有的潜在的安全问题、安全测试同时帮你做，你只需要在后台看有没有一些严重的安全问题，再对这些安全问题做处理就行了。
这理论上来说，是对于安全人员，对于研发人员侵入性最小、要求最低、开展门槛最低的一个工具。
这个工具有一些什么好处呢?
Seeker 这个工具会提供主动验证，确保结果的准确，甚至趋近于零误报这么一个值。
我们捕捉到了功能测试的流量之后，会在功能测试的流量里面加入我们攻击性的测试，并且会对于疑似的漏洞做验证。
打了标签的问题就是验证过的，100%确实是有问题的，并且根据严重程度，会排风险的优先级.
这解决了一个什么问题？安全人员经常遇到的一个挑战就是问题太多，不知道哪些是真的问题，也不知道哪些是应该优先解决的问题。所以通过这样的技术，可以帮助安全人员把最该优先解决的问题筛出来给研发人员。
但当给研发人员的时候又有一个什么问题，如果你是动态测试，那么动态测试其实只能给你出现一个结果。
研发人员还需要自己去debug，又违背了Devops的快、低侵入的原则。但IAST 有个好处是它会把问题出现在代码行里面的哪一行，整个出现的过程，它是如何产生的？到哪个点出的问题？都呈现给研发人员。
五、 Synopsys 完整的DevSecOps解决方案包括哪些部分？
围绕SDLC软件开发生命周期，Synopsys 提供全方位工具的应用安全的DevSecOps解决方案。
1、编码阶段
Coverity：静态分析工具
代码编写的阶段，有Coverity来做IDE的集成，在编写代码的同时发现关键质量缺陷和安全漏洞，在成本最低时加以修复。
2、代码集中构建阶段
Black Duck(黑鸭)：软件组成分析
使用业界领先的软件组成分析工具，在选型，开发和生产过程中检测，管理并持续监控开源组件和第三方组件中的安全与合规风险。
3、测试阶段
Seeker：交互式安全测试
深入分析 Web 应用的安全状况和基于各种合规标准(例如，OWASP Top 10、PCI DSS、GDPR和 CWE/SANS Top 25)的漏洞，主动验证安全漏洞并追踪敏感数据。CI/CD的无缝集成。
Tinfoil：API及动态安全测试
4、运维阶段
刚才那些工具如果适用，你可以同时不间断地用，不间断地来发现新增的一些问题。
5、专业服务
在没有覆盖到的这些框框里面，Synopsys 都会有一些专业的咨询服务，或者说是一些咨询、拖管的服务来覆盖。
六、 落地DevSecOps的一些值得借鉴经验
直播的最后， 杨国梁分享DevSecOps的一些落地的经验，包括：
1、小步快走
最开始这个东西开始起来是有一些难度的，所以希望是以比较小的一些项目能够把它做起来，做起来看到一些成效之后，尽量的左移，看到成效之后，我们再继续往下推进，不断的去完成它的自动化，不断的融入工具，不断的去做你的这些度量的指标的优化，流程的优化。
2、关于人员培训
对于人员的培训，最终完成整个你的开发人员、测试人员、安全人员、管理人员的一些观念的一个转变，从而完全转变到DevSecOps的文化里面。
其实最根本的还是人，因为你最终这些软件是需要靠人来写出来的，你需要对这些研发人员进行培训，你需要有懂安全的人员在研发的体系里面，实时的跟研发人员做交流，把这些问题反馈给研发人员。同样，你会让这些工具高效的运转起来，你还
要让自己的工程师，能够非常熟悉，怎么把这些工具高效的运转起来。整个DevSecOps其实就是一个观念转变的这么一个过程。你不断的去优化你的这些流程，不断的去优化你的这些工具，使之适配于你的组织，才能玩转整个的DevSecOps。
3、关于工具
关于工具没有工具是可以即插即用的，没有两个DevSecOps是一模一样的。你只有选择适合自己，定制适合自己的方案，才能把你自己的DevSecOps运转起来。