接下来我想跟大家分享一下这些年来我接触的用户在DevSecOps过程中所面临的困难和挑战。DevSecOps这个概念在近两年非常流行，我们把安全融合到DevOps中，就形成了DevSecOp。加入安全之后会面临哪些困难和挑战呢？

我总结了一下：首先我接触的大部分用户都是在开发周期的最后阶段才开始考虑做应用安全测试和防护。在开发阶段首先是考虑功能怎么实现，业务优先，第二会考虑性能，功能和性能都没问题后，才会考虑安全性的问题，就已经太晚了。

很多企业是这样想的，到最后会有渗透测试，渗透测试做完就没有问题了。这是远远不够的，首先，渗透测试不是那么全面，其次，放在最后做，发现问题后，可能就已经来不及修复了。马上要上线，很少有企业会因为漏洞而推迟上线时间。

很多时候企业是两难的，有时候可能真的发现了问题，但是会在上线之前去改造这个问题再上线吗？往往不会。应用有漏洞，但是几乎不可能推迟上线时间。很多时候企业会抱着侥幸心理，虽然有漏洞，但是这个漏洞可能不会被发现、被利用。为了抢占市场，要保证先上线，后面再有时间，再去修复、改bug、做应用的加固。

多数企业都会抱有这种心理，但是有时候漏洞会真的被利用了，如果修复的不够及时，不够迅速，可能在修复的期间内就已经被利用了。所以说尽早发现问题是非常重要的，这也是我们DevSecOps最核心的理念。一个是要把安全嵌入到整个软件开发生命周期中，每个环节都要嵌。第二，安全左移，把安全的理念左移到开发人员。
在大部分企业中，安全相关的人员占的比重很小，开发测试团队人员非常充足，但是真正负责安全的人员非常少。这些极少的安全成员如何保障应用上线后的安全性？其实是很难的。

除了安全团队的比例非常小之外，还有一个现状，我们的安全团队更多的是网络安全专家，对于编程和应用开发并不是非常懂。我们的开发人员往往对安全的知识也不太了解，他们往往认为自己的职能就是为了实现功能，认为功能实现了，任务就完成了，对安全开发和安全知识的储备不足。

这样就导致了开发人员写的代码可能存在很多安全问题。到了安全团队那里，他们不是开发出身，也不太懂代码，会发现这些问题他们根本解决不了，就产生了一个鸿沟。

所以我们的DevSecOps的核心思想就是把安全左移，把安全的重心放在开发阶段。这跟传统的安全是截然不同的，传统的安全是在运维阶段做安全，很多安全团队都属于运维部门，很多工作像防火墙、IPS、WAF、渗透测试等都是在后期来做。

在DevSecOps核心理念中，一定要把安全工作移到开发阶段，最好能够移到需求分析阶段。让我们的开发团队、开发部门能够承担安全的责任和工作。企业的应用安全工作不应该是完全由安全团队来负责的，一定是由开发和测试团队共同承担企业的应用安全职责。这就是DevSecOps的核心理念，开发团队不但要承担功能的实现，安全性也要保障。

第二点是，企业普遍认为做安全扫描需要太多的时间。不光是扫描应用本身，还要扫一些端口、数据库、系统等等。想进行更为全面的扫描，可能会花很多的时间，企业往往会有这样的顾虑。
第三点，当问题发生时，我们安全团队在找问题的时候，往往会发现，真正的问题并不是网络层面，而是来自于我们的应用本身，一部分是应用的业务层的源代码，还有一部分是代码依赖的一些底层的开源组件。最后发现，问题其实是来自于开发人员，但是背锅的却是安全人员。

所以很多时候，我们的开发人员发现问题比预期要晚得多，往往是到最后阶段才知道代码存在问题，然后再去定位、修复、再去发布应用，这样就会耽搁很多时间。所以我们提倡一定要尽早发现问题，在开发阶段就开始规范化我们的安全编码，尽早去做安全测试。

其实随着自动化工具的部署，扫描时间越来越短。之前可能需要人工去进行审计检查，有了自动化的工具之后，扫描时间的趋势是越来越短了。对扫描后的结果和漏洞分析需要的时间可能越来越多了，需要去判断分析，是不是真的有危险？需不需要改？怎么改？这个很重要。这一点是我认为目前企业遇到的最大的困难和挑战。

我们部署了很多的自动化测试工具之后，针对测试的结果需要花费很多精力，对分析的人员也有很高的要求。既要懂软件开发的知识，又要懂安全，还要懂整个的业务场景。根据需求才能够去判断针对扫描后的结果要不要改，怎么改。

其实说句实话，开发、测试和安全人员其实是有些对立的。开发人员当然希望不要对他写的代码挑毛病，他们往往会觉得自己写的代码是完美的，是没有问题的。但是安全人员肯定要从安全角度去做要求，要求程序员写的代码是符合安全基线和标准的。这两者难免会有一些摩擦，因为这之间其实是有鸿沟的，往往是开发人员不太懂安全，安全人员也不太了解开发和编程。

以上这些就是我们目前面临的困难和挑战，我们做好DevSecOps也是为了解决这些困难和挑战。通过跟大家分享一些好的实践方法，从流程和工具角度去给到大家一些建议。保障企业的业务系统能够平稳安全地运行。