下载掌阅APP，畅读海量书库
立即打开
虽然DevSecOps可以被认为是引领未来软件安全发展方向的新方法论，但是严格来说，截至目前，所有的DevSecOps实践尚处在摸索和发展阶段。
在已知的DevSecOps实践中，有的是一些前沿企业全面贯彻DevSecOps、以DevSecOps重塑自身组织的相对彻底的DevSecOps实践，有的是一些在各自行业内的领军企业，在其建成SDL体系基础上进行DevSecOps转型实践，还有的是一些信息安全服务的乙方企业秉持着DevSecOps敏捷安全理念力图为众多的企业提供围绕DevSecOps的一系列软件安全解决方案的实践。
无论来自甲方的实践主体，还是来自乙方的实践主体，从DevSecOps的实践过程来看，总体来说，大体可以分为两类：从零开始建设DevSecOps体系，以及在已有SDL体系上实践DevSecOps转型。
事实上，一开始就全面地实践DevSecOps的企业，目前为止并不是很多。全面的DevSecOps落地实践意味着从零开始建设DevSecOps体系。这类较早在自身组织内推行DevSecOps并付诸实践的前沿企业，通常都不是墨守成规的组织。在这样的企业组织体系中，团队乃至个人往往更容易认可新的理念，接纳新的安全开发方法论，更适合从零开始建设DevSecOps体系。然而，毕竟是从零开始，难度比较大。
与SDL模型在零安全基础的企业内落地时遭遇诸多困难的情形相似，从零开始着手DevSecOps体系建设，也要面对自身组织内软件开发、运营等过程安全管理缺位时的混沌局面，诸如需求评审和代码评估缺失、人工评估方式下的人情评审、缺少标准化知识库而无法评估质量、安全团队与其他团队尖锐对立、过分强调业务需求优先、事故频繁而深陷救火复盘等一系列软件安全管理问题。
凡是采用SDL重塑的企业，都在一定程度上解决了自身组织内软件开发过程中安全管理缺位的问题。因此，直观地讲，在企业已有的SDL体系上实践DevSecOps转型，较从零开始建设DevSecOps体系要相对容易些。
从统计数据来看，目前已知的DevSecOps实践多来自互联网、通信、金融、能源、交通、物流等重要行业的领军企业。它们在自身已有的或在建的SDL体系上转而积极拥抱DevSecOps并付诸转型实践。
SDL体系本就着眼于治理软件开发过程中安全管理缺位时的开发乱象。因此，一些企业的决策者不免会想当然地认为从SDL体系向DevSecOps的转型实践是驾轻就熟的，只需要将同样的安全实践从SDL体系向DevSecOps体系直接移植即可。
然而，SDL体系实现的仍然是传统的安全管理，具体表现在：安全理念落后，认为安全责任仅在于安全团队；安全嵌入研发及运营流程的程度低，甚至还常被置于流程之外；安全活动需要人工参与甚至主导，效率低下。相比之下，DevSecOps主张安全是每一个人的责任，需要将安全活动嵌入研发及运营的流程，且要柔和地嵌入并实现端到端的工具化和自动化，以完全适用于快速迭代的业务场景。由此不难看出，二者对于安全的认识有着本质的区别，这直接影响到了所实现安全的属性，使之存在着巨大差异。因此，从SDL体系向DevSecOps的转型实践，绝非是简单地将SDL体系的安全实践照搬过来就能完成的。
SDL多用于大型软件产品的开发安全，而大型软件产品通常采用传统瀑布式开发，往往有着较长的开发周期。随着敏捷方法，比如敏捷开发方式和DevSecOps，逐渐在软件开发活动中占据优势，将安全集成到敏捷方法中就成了很有必要和十分迫切的事项。然而，仅是将SDL的安全实践添加到一般意义上的敏捷流程中，就需要对相关的SDL安全实践进行精简和轻量化。即便如此，由于敏捷方法是一种增量交付模式，集成了SDL安全实践的敏捷流程也只是对增量部分实现了SDL安全保障。
而更实际的问题是，考虑到敏捷方法的流程特点，相关安全实践的适应性调整和在集成到敏捷方法的过程中，不免会遭遇一连串问题，比如传统安全团队的工作模式不匹配、安全性被习惯性地轻视甚至忽略、集成安全实践后影响敏捷方法效率、安全专家短缺等。
其中，以传统安全团队的工作模式不匹配为例，传统安全团队的职责在于：指出业务系统存在的安全问题，并提出修改的要求，以及监督在整改完毕前不得上线和问题追责。这样的安全角色定位和态度显然将使安全人员无法在快速迭代的模式中立足。为了调和上述矛盾，在敏捷流程中，只有将安全工作进一步前移至需求阶段，与开发团队一道识别安全风险，促成安全目标与业务目标的协调一致，才能在敏捷过程中实现软件安全。否则，这种不匹配在SDL体系向DevSecOps转型的实践中将成为企业面临的首要问题。
作为典型的以价值驱动的开发管理模式，敏捷方法每次迭代交付通常都优先考虑项目经理认定的最有价值的业务需求。在这种情形下，开发团队因缺乏安全知识或交付压力，难免会习惯性地将安全性需求排在低优先级甚至策略性地放弃。换而言之，就是将经典的SDL安全实践选择性放弃，从根本上拒绝安全左移，如此则实质地限制了SDL体系向DevSecOps转型。
从另一个角度来看，回顾过往的SDL实践，若一味地强调迭代的安全性，一些典型的SDL安全活动及其配套工具必然会对敏捷过程的效率造成影响。例如，在典型的SDL安全活动中，通过白盒测试扫描源代码和二进制文件能够尽早地发现其中潜藏的安全漏洞，但是需要人工介入解决误报的问题，这会制约敏捷方法原本应有的效率。因此，想要实现敏捷流程的安全性，SDL流程中一干笨重的安全活动及配套工具应当作出适当的修改或舍弃，否则同样会限制SDL体系向DevSecOps的转型。
面对敏捷流程的安全管理，若仅以过往的SDL实践经验来看，最为直观和迫切的问题还是安全专家的短缺。在敏捷方法中，需求—设计—开发—测试—交付—部署—运营过程中大部分甚至全部都是单件流并行的，若针对每个用户故事都需要安全专家在现场协同，就需要配置与开发团队近乎同数量级的安全专家，这对于大多数企业都是不可能接受的。因此，安全专家的短缺以及人员配置方式也是限制SDL体系向DevSecOps转型的重要因素。
总的来说，从SDL体系向DevSecOps转型并不是简单地将SDL体系的安全实践直接照搬过来。对于过往的SDL实践经验和已有的SDL体系，也不应该一味地否定它和推翻它。合理的做法应当是，充分审视SDL实践经验和已有的SDL体系，从中选择有用的部分，借鉴其中有益的经验。对于不适用于DevSecOps的部分，例如SDL中一些笨重的安全活动及配套工具，应当进行适当的改良和适配。而对于SDL体系缺失的部分，需要及时引入或开发相应的技术、工具，以实现在已有SDL体系基础上构建DevSecOps体系。
无论从零开始建设DevSecOps体系，还是在已有SDL体系的基础上进行DevSecOps转型，都会碰到一系列问题，这些问题会阻碍DevSecOps体系的落地。
归纳起来，这些阻碍DevSecOps体系落地的原因不外乎以下几个。
安全角色在SDL体系中都是以独立团队的形式存在的，与开发团队、运营团队是分开的，这就导致跨部门之间存在天然的隔阂。DevSecOps要求安全团队与开发团队、运营团队的人员都改变观念，认识到安全是每一个人的事情，需要大家的协作，需要切实地落实执行。然而落实执行的过程往往会遇到很大的困难。例如，开发人员会认为考虑安全是在给他们增加额外的工作量，导致拖累开发进度甚至延期。特别是在敏捷方法下，这无疑是将开发人员推向安全的对立面。因此，这种新旧安全文化的冲突和不同角色的意识壁垒，是阻碍DevSecOps体系落地的首要原因。
这里的安全人才主要是指具备DevSecOps知识的相关安全人才，即DevSecOps安全专家。不仅从零开始建设DevSecOps体系时需要DevSecOps安全专家，在已有SDL体系上进行DevSecOps转型时，也需要DevSecOps安全专家。
安全左移是DevSecOps的本质属性之一。它要求安全团队与开发团队亲密协作，在关系到开发安全、运营安全的需求分析、方案设计、测试验证、发布交付、部署运营等环节都需要有安全专家的参与。安全专家需要既懂安全，又懂研发，还要了解软件架构、软件开发部署流程等，这样才能支撑诸如威胁建模等与安全需求分析、安全架构及方案设计、安全编码、安全构建、安全测试、安全发布、安全运营等相关的安全活动的顺利进行。
安全人才市场中的安全专家本就比较短缺，再加上大部分安全人员都是负责运营侧的传统安全人员，这就导致DevSecOps安全专家更是凤毛麟角。而DevSecOps安全专家的缺失，将导致安全团队和开发团队的沟通不畅，进而影响安全左移的效果。安全左移做得不好，将直接影响安全性要素嵌入DevOps流水线后的效率和效果。
开发人员、运营人员等角色缺少安全意识和相关技能，这也是阻碍DevSecOps体系落地的原因之一。安全培训是一种使相关人员提高安全意识以及掌握相关知识和技能的直接、有效的手段。
即便是SDL体系的知识传授都透着浓浓的学院派气息，缺少落地实践指引，更遑论新兴的DevSecOps。缺少实战意义上的安全培训和实践案例分享实际上是限制相关人员迅速提升能力的一个重要因素。人是DevSecOps体系的建设者，人员安全能力薄弱的问题必然会影响到DevSecOps体系的建设。
DevSecOps流水线的落地需要自动化技术的支撑。较之SDL,DevSecOps对自动化的要求更高，只有高度自动化的流水线才能提高安全实践效率，实现匹配敏捷性要求的快速迭代。然而，传统的威胁建模、安全需求分析、安全架构、方案设计以及相当一部分的安全测试都需要人工介入。
安全活动配套的工具过度强调人工介入，不仅提高了对相关人员的需求，更是割裂了各种安全工具与开发、测试环境的自动化连接，降低了开发、测试环境的耦合程度，进而无法实现自动化流水线和安全闭环。
目前比较主流的安全测试工具有很多种，比如传统的SAST白盒代码审计工具、DAST黑盒漏洞扫描工具及新型的IAST灰盒安全测试工具、SCA软件成分分析工具等。这些独立运行的工具都有自己的漏洞管理系统，所以将这些工具集成到DevSecOps流水线首先要面临的就是异构漏洞数据的清洗、关联分析和全流程漏洞管理的问题。
更为糟糕的是，现实中的一些利用工具实现的安全活动，例如源代码安全扫描工具进行的白盒测试、漏洞扫描工具进行的黑盒测试等，扫描时间动辄数小时，这将严重割裂安全与研发流程，无论对持续集成效率还是对数字化业务交付速度而言显然都是不可接受的。因此，这也是制约DevSecOps体系落地的原因之一。
DevSecOps体系要从文化、流程、技术等多维度对包括组织架构、流程管控、技术规范、工具引入、知识管理、人才培养等多方面进行建设和改进。面对长周期的、多维度的、涉及方方面面的体系建设过程，诸多新事项被提出并需要从零开始着手落实，许多要素都需要分阶段规划实施、持续改进和重塑。那种期待通过简单移植他人成功落地的DevSecOps体系的企业，或是因一时兴起搞突击式立项和进行所谓DevSecOps体系建设的企业，一般情况下都无法使DevSecOps体系在其自身组织内成功落地。我们在推行DevSecOps敏捷安全体系应用落地的过程中应尽量避免“理论主义”和“乐观主义”的出现：流于形式的理论主义，虽然提出了一系列看似站位高、目标远大的建设体系，但因脱离实际而无法落地执行；笃信技术可以解决一切问题的“乐观主义”，有点舍本逐末，寄希望于单一工具的能力或是诸多工具的简单堆砌，但无法让它们彼此连通形成体系化合力。