诸子云 | 活动：10.22广州DevSecOps 方向主题线下研讨会
作为在2017年美国RSA大会出现的一个新概念，DevSecOps意味着“每个人为安全负责”。DevSecOps糅合了开发、安全及运营理念以创建解决方案的全新方法。DevSecOps被广泛应用标志着应用及IT基础设施的安全管理进入到一个全新的时代，将安全作为管理对象的一种属性，从应用和IT基础设施开发开始进行全生命周期的安全管理，构建一个安全属性很高的应用或IT基础设施，而不仅仅是通过安全为应用和IT基础设施提供保障。
在此背景下，10月22日，诸子云广州分会举办了“DevSecOps 方向主题线下研讨会”，现场专家对DevSecOps展开了深入讨论，针对DevSecOps的敏捷性、扩展性、可运营性、落地及体系架构等多个角度进行了探索与解读。
本次研讨会由诸子云广州分会主办，郑欢担任主持。活动有幸邀请酷狗音乐、中国电信、广发银行、CVTE、蓝月亮、广东华兴银行、碧桂园、AdTiming、广东快乐种子科技等企业的安全专家参与。
艾贝链动安全运营负责人郭桂生、某金融研发中心安全架构师李晓德、比瓴科技创始人&CEO付杰、某在线教育前安全负责人廖翰晖，四位专家分别进行了分享。
郭桂生
艾贝链动安全运营负责人
CNAPP指的是Cloud-Native Application Protection Platform，译为云原生应用保护平台。这是Gartner在去年新提出的一个概念，主要应用于云原生环境，并贴合当前的大趋势和大背景。当前受疫情影响，互联网技术急速下沉，更敏捷、更强大的开发工具的需求迅速增加，云原生的工作负载激增。相对于传统技术，云原生能够更快速，更便捷。据Gartner 估计，到 2025 年，超过 95% 的新数字工作负载将部署在云原生平台上，高于 2021 年的 30%。
云原生主要包括广义云原生和狭义云原生，广义云原生指的是一种允许用户构建具有弹性、灵活和敏捷性的应用程序架构的技术架构，使之能够快速响应数字化变化。狭义云原生指的是基于云平台能力（IaaS，PaaS，SaaS），使用包括DevOps，微服务、容器化等打造的支持持续交付、水平扩展、敏捷迭代特性的技术架构。
实际上，云原生虽然有很多好处，但在使用中的痛点和挑战也很明显。据调查显示，97% 的公司报告了云原生应用程序的可观察性问题；96% 的公司表示，云原生应用程序导致部署周期变慢，其中有67% 的公司将安全性列为最大挑战；69% 的公司认为容器级防火墙（IPS/IDS、WAF、DDoS、DPI 等）是云原生应用程序网络安全的首要需求等等。总结下来分为四个方面，弱可见性、错误配置和暴露面、多重安全风险、缓慢的安全过程。
根据Gartner的定义，CANNP是一个集成各种安全、合规工具能力的整体性平台，包括从开发到产品部署全部阶段的核心能力和需求，包括容器扫描、云配置监控，基础架构扫描等等。CANNP核心就是通过平台统筹各种各样的能力为应用的全生命周期提供各种各样的保护。同时，它还能够按照企业的需求，将相关能力整合到一个体系中，实现更快速、敏捷的安全保护。
在开发阶段，CANNP围绕于本地开发工具通过集成SCA、SAST相关插件（IDE插件）对本地开发的项目进行实时扫描检测，并根据需要对扫描结果上传。SCA、SAST 通过接收远端统一配置的安全开发基线实现在开发侧对潜在可能出现的代码风险和漏洞组件进行检测识别，此措施不仅能在开发侧进行代码风险检测发现，并且实现了在技术对企业开发安全基线的统一标准化控制。
在测试阶段，CANNP主要基于代码仓库（gitlab等）中的工程代码，通过CI 自动化流水线实现集成联动SCA、SAST、DAST、IAST 等工具对以相关项目工程（应用）为目标的自动化测试过程。在对应Pipeline的过程中，其本质过程是调用远程的CNAPP相关的安全模块服务API对指定版本的项目进行拉取、构建、测试的过程，并在服务后端实现对以项目为单位的自动化测试结果进行跟踪处理。
在构建阶段，CANNP主要围绕CI过程所输入输入的仓库源、文件、镜像等所获取的镜像进行全面的漏洞扫描，具体包括 IAC、Images、Artifactory 等，主要实现对应用所需所有进行镜像进行服务组件的漏洞扫描、恶意文件分析检测等。在此过程中pipeline 本质将是调用安装在CI server 或 远程的扫描器完成相关目标镜像的扫描并完成结果上传跟踪处理。
这里有三个建议，首先是不追求实质的一体化平台，任何一个拿来即用的CNAPP产品都没法完美满足企业所有的相关需求。可能是功能上的考虑、管理上的考虑甚至成本投入的考虑。在具体的实践中，不应追求实质的一体化的CNAPP平台覆盖所有，只须在CNAPP架构的指引下构建一套适配自身的逻辑CNAPP平台。
其次是协同多个相关部门或团队，CNAPP 本身概念涉及的相关部门极多，为保障项目有序推进，应积极协同多个部门（安全部主导）参与整个体系的设计架构过程并理清其中角色和职责。
最后是事件处理流复用，应避免要求过多用户（安全部例外）直接登录使用CNAPP，若存在工作流的跟踪处理，应优先考虑使用生态集成对接的形式形式，使CNAPP产生的相关事务之前嵌入到现有的事件流中（trello,jira,confluence,workflow 等等）。
02金融企业DevSecOps体系建设与落地实践
李晓德
某金融研发中心安全架构师
2012年，Gartner通过一份研究报告提出了DevSecOps的概念。2016年9月，Gartner发布报告《DevSecOps:How to Seamlessly Integrate Security into DevOps》，提出具体模型和方案。核心理念：安全是全体IT团队所有成员的责任，要贯穿到业务生命周期的每一个环节。
微软的SDL理念诞生的背景是随着软件的普及，各地的黑客把注意力集中到微软开发的软件上，促使他们关注自身的软件安全。微软的目标是将安全集中到软件开发的每一个阶段。此前，安全环节更多是在测试阶段，也就是交付代码之后。在需求、设计、开发等阶段并没有潜入安全管控措施。
DevSecOps诞生的背景是传统的SDL无法满足频繁交付的需求，SDL考虑的是质量而非效率。同时，云服务、微服务、容器等新技术的出现使边界不再像过去那样清晰，因此就诞生了DevSecOps体系。与前者不同的是，DevSecOps体系的核心理念是将责任落实到每一位安全或IT团队的每一个成员，关注的重点是帮助组织更快的发展或改进产品，以满足组织更好的服务客户，并在市场上高效的参与竞争。
DevSecOps在实践中拥有三个关键角色，第一是人和文化，相较于传统的安全职责分离原则，DevSecOps强调建立安全而不仅仅是依赖安全。安全是大家的事，每一个人皆为安全负责。第二个是持续自动化的技术，从开发源头做威胁管控， 相关安全工具链技术应支持Jenkins等CI/CD管道，支撑DevOps敏捷开发和快速部署。最后是柔和低侵入的流程，配套工具链技术的实施和流程尽可能对原业务流程产生微小的影响。
在人和文化方面，现有的人员组织结构一般来说包括六项：领导是整个中心的资源协调，对中心整体安全负责；研发团队负责人负责团队内部资源协调，对团队整体安全负责；安全团队负责中心DevSecOps体系落地建设，包括人员培训考核、安全工具链建设等；安全BP指的是每个团队设立一名安全BP，对接安全团队，负责落实团队的应用安全工作；安全架构师指的是每个应用设立一名安全架构师，对所属应用的安全负责；项目组负责需求安全分析、系统安全设计、安全编码。在DevSecOps的体系中，安全需要每个工程师的参与，每个人都承担了安全职责和工作。
具体的人员管理和文化建设包括入职背调和保密协议，所有新员工入职时前都会进行背景调查和签订保密协议；新员工入职培训考试，对新入职的员工开展安全培训和考试，包括内控要求、DevSecOps体系的介绍、基础安全漏洞介绍与修复方式、安全意识宣贯；安全积分与考核，以团队和个人为维度建立安全积分制度，并纳入考核的奖惩制度。
一般来说，安全规范和制度包括以下五类，第一是体系管理类，是最上层的管理细则；第二是安全设计类，包括《应用系统安全设计通用规范》等相关的一些规范；第三类是安全编码类，包括《Java语言安全编码规范》、《PHP语言安全编码规范》等；第四类是平台安全类，包括Android、iOS等平台安全规范；最后是安全测试类。
在流程建设中包括安全需求设计、安全审核、安全编码、安全测试、上线运行。安全需求设计方面要设立安全基线，也就是安全需求。基线的来源包括常规的应用漏洞，相关的法律法规标准等。每个安全基线包括了一些名称描述、风险等级以及对应的安全设计、测试用例等。每个安全基线对应了多个关系，描述安全需求，规避安全风险。
DevSecOps是如何柔和嵌入到现有的开发流程中，首先是安全工具的选择策略，一般采用商用安全工具和开源安全工具相结合的方式，商用安全工具技术成熟，开源安全工具更加灵活。每类安全工具以商用安全工具为主，同时引入开源工具作交叉验证和补充。
SAST 静态代码扫描工具是如何嵌入的，首先通过CI/CD流水线配置代码检查任务并设立质量门禁。其次是引入开源的静态代码扫描工具，编写自定义的扫描规则。第三是IDE中集成代码扫描插件，安全左移。最后是以问题代码文件名、行数、内容做SM3,实现两款静态代码扫描工具误报和漏洞互通。
付杰
比瓴科技创始人&CEO
目前落地DevSecOps面临着几大挑战，80%的SDL/DevSecOps项目在落地执行中，普遍面临以下难点，首先是建设周期长，迟迟不见项目上线及实施效果；其次是人力消耗大，项目内部推动困难；第三是研发对于改变现有工作流程不习惯；最后是项目成果难以量化、可视化。这些问题背后的原因主要是有几点，第一是安全工具碎片化，安全工具与CI/CD集成度低，工具扫描维度零散，缺乏统一分析。第二是安全活动线下化，开发过程安全活动大量依靠人工线下驱动，安全活动与CI/CD、协作工具缺乏整合。第三是自动化处置能力缺失，多样化安全场景处置依靠人工拉通，安全体系运营需要大量安全人才。第四是安全数据分散，研发数据、安全扫描工具数据及外部威胁数据分散，缺乏统一分析，更无法让数据产生价值。
实际上，这些问题既是技术问题，也是管理问题，安全工具碎片化和安全活动线下话都是与管理相关的问题。当前，一个好的平台一定要有两个核心价值主张，持续性和可运营。持续性强调的是它的能力可以在一个优秀的框架下持续扩展，可运营是在不同的组织架构、不同的应用的开发场景以及各种安全问题的处置场景中能够被运用。这背后需要统一的安全平台，以自动剧本的方式将人、项目、技术三要素统一；需要ASOC编排，实现对安全工具、CI/CD工具及协作工具的统一编排及结果关联分析；需要统一数据中心进行分析、汇总和度量，避免数据孤岛。
比瓴无论是服务大型金融机构还是小型互联网公司，始终坚持帮助客户构建一个研发低干扰、devops友好、持续可运营的体系。CAS平台作为比瓴向客户交付DevSecOPS能力的核心，最顶层是一系列的场景安全剧本，包括开发场景、合规场景和相应场景。安全剧本的下面是两个大的数据中心，一个是安全数据中心，另一个是安全运营中心。安全数据中心包括安全开发驾驶舱、安全开发知识库、统一威胁管理和统一漏洞管理。安全运营中心包括安全开发运营剧本、安全开发质量门禁、安全开发资源管理和编排及关联分析。平台中层是比瓴CAS所内置的单点安全能力，例如SCA开源扫描引擎、代码敏感信息扫描、API安全扫描、IAST交互式扫描。平台下层是与DevSecOps基础设施的各种插件对接，包含代码仓库、制品库、项目管理系统、流水线以及第三方的扫描工具。
比瓴CAS平台的核心是剧本，并由剧本驱动企业的日常安全处置，其中包括平台内置安全剧本模板和企业自定义剧本。平台内置安全剧本基于比瓴在过往大量客户实践经验被构建，剧本支持以情报、Timer、MSG、CICD的方式触发，基于场景差异化编排调用资源、资源动作及前后关系，并基于结果采取安全处置动作，包括：安全门禁、消息通知、策略修改等。与此同时，用户可全新编辑安全剧本或修改平台剧本模版，自定义属于企业的安全场景自动化运营处置方式。
比瓴CAS平台的第二个能力是工具统一编排，可见即可用。持续可运营的软件安全能力非常重要，持续性表现在两个维度，第一，是否能够覆盖全部节点，例如需求阶段、设计阶段、测试阶段、预发布阶段和发布的审核阶段。第二，接入的能力是否可以扩充，这关系到框架的持续性演化能力。第三是可运营，云原生赋予了弹性和可伸缩性以及屏蔽技术细节，这是云原生的优势之一，同样的，在安全平台也可以构建一个统一的安全基座，可以灵活基于剧本和自定义剧本的方式来处置不同场景和完成不同技术、资源的使用，甚至是对技术、资源的细节差异屏蔽。
以在日常软件开发场景为例，针对敏捷模式、瀑布模式、应用等级差异及业务变更规模差异，比瓴提供非常多样化的剧本。根据剧本的不同，客户可以实施差异化的管理流程、节点上差异化的扫描工具、工具不同的扫描规则模版，并且基于扫描结果实施恰当的门禁策略。
廖翰晖
某在线教育前安全负责人
在线教育行业与其他行业的不同点在于其业务侧重点不同。在线教育主要侧重APP端的客户流量转化和生源的长期可维持性和保护个人儿童信息安全的保护特点，在此基础上其业务研发也就有了根本性的区别。
SAST指的是静态应用程序安全测试技术，通常在编码阶段分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞。对于一些特征较为明显的可以使用正则规则直接进行匹配，比如硬编码密码、错误等，但正则的效率是个大问题。当前市面上的所有SAST工具都无法适配越权问题。
大部分互联网教育公司的应用架构都是微服务架构，安全作为一个属性的话，需要深入嵌合到这个架构中框架。因为有统一的框架，才能更好的通过静态代码做一些事情。外购的系统肯定是不开源的，因此就只能通过接入must这种应用安全设备去防护第三方系统。随着越来越完善的 DevSecOps 安全建设之下，很多安全问题已经逐步变少，例如 SQLI、RCE 等，企业的安全建设在研发安全方面已经逐步完善，常见的 WEB 漏洞已经开始降低，但是有一种漏洞难以解决，且是常见的 SRC 的高分漏洞，那就是越权漏洞。
如何检测越权漏洞，首先在 ql 里有一个来自 remoteFlowSource 的类可以满足这个需求，其次，当一个参数传递进来并且没有数据流经过用户服务，换句话就是未使用用户服务团队提供的request解析api进行解析。一般用户服务会提供一些api来解request的登陆态，并返回这个request的id值，没有用到用户服务的解析，就没有id。最后，当应用有数据库查询功能，比如更新订单、查询订单的敏感信息，也就是常见的 CURD。在这个查询中，一般会带一个条件，就是“where id = ?”，这里的id就是从用户传递过来的对象中拿到的。
在设计过程中，首先是安全需求评审；其次是软件设计融入安全架构观念；第三是编码，针对编码安全规范进行复核；第四是灰度测试，上线前接入IAST灰盒扫描；第五是应用上线，安全部门针对上线应用进行安全入网评审；第六是上线发布，其中最关键的是在互联网教育应用中设计了运行时防御，以便在运行期间快速修复漏洞；最后是运维，接入常规应用防火墙等。
IAST (Interactive Application Security Testing) 也叫灰盒测试，即介于白盒和黑盒之间的一种测试，这一场景下的技术不但关注程序输入输出信息，还可以了解部分程序内部逻辑。因此具备黑白盒测试的优点（主要是IAST掌握了应用程序内部上下文联系）。
RASP代码自我免疫技术：以java举例，RASP借助JVM提供的instrumentation技术，以Javaagent形式部署在java应用当中。agent对关键类和关键方法进行HOOK以增加针对性的算法来防护攻击。
现场花絮
活动相关资料欢迎大家在知识星球下载~
齐心抗疫 与你同在