一. 什么是安全开发生命周期（SDL）

　　1.1 SDL诞生背景

　　随着互联网技术的快速发展，网络系统及应用在给人们的生活带来巨大便利的同时，信息安全问题也逐渐成为用户和企业关注的焦点。然而，安全问题的管理和解决需要一个系统的、完整的解决方案，在缺乏有效解决方案的情况下，很容易因为开发人员的疏忽或缺乏安全设计，导致系统存在安全漏洞。这些漏洞一旦被恶意用户利用，将会造成严重的安全风险或经济损失。

　　在此背景下，微软在2004年正式提出了安全开发生命周期模型（SDL），并在其软件开发过程中广泛应用。SDL模型旨在通过整合安全能力到软件开发的各个阶段，从而提高软件系统的整体安全性，减少安全漏洞的产生。随着时间的推移，SDL已成为一种广泛应用的企业应用安全建设模型，已经被越来越多的组织和企业使用，并被证明是一种有效提升系统安全性的方法。

　　1.2 SDL模型概述

　　SDL的核心理念就是从需求、设计到发布产品的每一个阶段都增加相应必要的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。其流程主要分为以下七部分：安全培训、安全需求、安全设计、安全开发、安全测试、安全发布、安全响应。在各阶段加入相应的安全能力，如图1所示：　　

图 1

　　二. B站SDL雏形

　　在2020年安全团队开始着手依据SDL模型尝试在B站的落地工作，整个过程大致可以分为安全能力落地和安全流程落地两个阶段。

　　2.1 安全能力落地

　　万丈高楼平地起，复杂的SDL模型也是由每个细分的安全能力组成。为了满足SDL模型的核心理念，首先就是要求安全团队在系统开发的各个阶段具备相应的安全规范或安全能力，这样才能为后续的SDL模型落地打好根基。在此过程中，安全团队重点完善了以下几个阶段的各项安全能力：

　　培训阶段：准备安全意识、安全漏洞等安全课程及材料

　　需求阶段：新增系统安全基线、安全漏洞管理规范

　　设计阶段：新增威胁场景及威胁建模

　　开发阶段：新增安全编码规范，新增第三方组件扫描工具

　　测试阶段：新增交互式应用安全扫描工具

　　发布阶段：持续优化动态应用安全扫描工具

　　响应阶段：持续推进HIDS及WAF覆盖

　　2.2 安全流程落地

　　软件开发的各阶段具备了初步的安全能力之后，就要考虑如何将SDL模型在B站的应用开发流程中完成落地。在推动落地的过程中，自然也会遇到一些困难，例如：当前开发流程无任何安全节点，人力资源不足，业务人员安全意识不足等。为了解决上述困难，安全团队的重点工作主要有以下几个方面：

　　划分安全BP人员：考虑到B站业务的复杂性，安全团队会为一些重点业务线分配了安全BP人员，负责该业务的SDL流程落地工作。安全BP人员通过跟业务负责人沟通，介绍安全相关能力的同时，也尝试了解业务相关的安全需要，然后有计划的推动SDL流程的落地工作。

　　加强安全相关培训：在实际工作中，往往不同开发人员面对安全问题会存在不同的理解。此外，安全意识也缺乏传递性，新员工经常出现不了解现有安全要求的情况。因为安全BP人员会针对负责业务线常见安全漏洞和安全意识进行定期的培训工作。

　　借助现有管理平台：经过沟通发现，大多数业务通过内部协作平台管理开发流程，最终的发布流程也会通过服务管理平台进行审批。因此，安全侧通过在这两个内部平台中添加QA节点，安全作为QA节点感知需求及应用上线动作，逐步了解业务并深入安全相关工作。

　　定期沟通机制：安全BP需要跟业务开发人员及负责人建立定期沟通机制，在持续提升业务安全水位的同时，也跟业务团队形成良好的合作关系。在持续合作过程中，安全BP会不断深入了解所负责业务线的相关业务特点及应用组成，不断发现业务中的安全问题，并基于相关业务线的业务特点找到合适的解决方案

　　经过一年多的SDL实践，在某些业务线，SDL模型已展现雏型，如图2所示：　

图 2

　　三. 数据生命周期安全

　　从2023年开始，随着数据安全相关法律法规的落实和监管要求，SDL相关工作迎来了新的挑战——数据生命周期安全。数据生命周期安全是指从数据的采集、传输、存储、处理、共享到销毁的六大阶段，完善数据安全治理体系。目的是为了保证数据的完整性、可靠性、安全性、合规性以及最大化利用价值。在数据生命周期的不同阶段，需要根据数据的特性和业务需求制定相应的管理策略和措施，如图3所示：　　

图 3

　　安全部门也积极响应法务、数据平台以及其他部门合规团队的工作，在SDL流程中加入了相应的数据安全能力，如图4所示：　　

图 4

　　API分类分级：通过抽样线上网关的用户请求流量，对接口中传输的数据进行检测，并根据检测结果对接口进行分类分级

　　数据库分类分级：通过对现有数据库集群的抽样检测，根据字段内容、字段备注、字段名等信息，识别数据库中存储的数据并进行分类分级

　　与安全漏洞不同，数据安全的治理需要根据数据分级分类、业务情况、监管要求、使用场景等各方面因素综合评估。例如，依据公司《数据分类分级指引》将数据分为C1到C4四个等级，C4级别的数据在传输及存储时就需要做加密处理。再比如同样是个人敏感信息数据，生产环境中需要加密存储，而测试环境则不允许落地存储，因为在合规要求下测试环境不允许使用真实个人敏感信息进行测试。

　　四. 从SDL到DevSecOps

　　虽然经过安全团队持续的努力，在某些业务线已经初步完成了SDL模型的落地，但在此过程中遇到的种种问题也引发了笔者的一些思考：

　　在包含复杂业务场景和众多技术部门的企业背景下，使用SDL模型覆盖部分业务线或许可行，但要实现全公司范围的覆盖就需要大量的人力投入，安全部门不可能将人力覆盖到所有业务

　　大量的需求评审、安全测试等环节需要人力参与，这无疑会造成开发流程效率的降低，这其实与互联网公司强调敏捷的概念相违背

　　在SDL模型下，即使在开发各阶段安全的工具与能力都已非常完备，但“安全”与“开发”似乎仍然是割裂的。在此情况下，反而容易形成“安全孤岛”，开发人员会认为相关的漏洞、后果是安全人员需要解决的问题，从而将大量冗余的工作转移给了安全人员，“安全”在开发中成为了独立的存在因素，这往往会进一步造成沟通的困难

　　因此，SDL模型在强调敏捷和高效的互联网公司是否显得过于厚重，如何将安全无感的融入现有开发流程，便成了最值得思考的问题。随着DevOps流程在B站逐渐完善，公司CI/CD工具及流程的持续完善与优化，DevSecOps或许成为了新的解决问题的钥匙。就如同DevOps理念中开发和运营相互结合一样，关键的安全能力为何不能也融入这个体系中呢？所以，DevSecOps与SDL理念不同，不再强调人、文档与制度的推进，而是侧重打破开发与安全的割裂，将安全尽可能无缝、无感知地集成进现有devops流程中，在不降低开发者效率，或者不要求开发者离开现有工具链环境的情况下，使系统满足安全要求。

　　在此理念下，DevSecOps通过将安全工具链加入DevOps的各个环节来实现应用的持续安全，但与SDL模型不同，DevSecOps模型下更强调各安全工具的集成能力、自动化能力和易用性。当前B站DevSecOps安全工具链的实践大致如图5所示：　

图 5

　　需求阶段：需求安全评审工作可能是与大语言模型最契合的场景之一，大语言模型可以完全改变以往低效的人工评审模式，目前安全部门正在这个方向上持续尝试

　　开发/测试阶段：借助内部持续集成平台，安全侧感知应用构建行为，自动化发起源代码扫描、第三方组件扫描及镜像扫描，此行为开发人员无感知，发现安全漏洞时会自动推送至相关开发人员。当然在此阶段人工测试有时也是必须的

　　发布阶段：动态应用安全测试及主机基线扫描会覆盖公司所有主机及域名资产，周期性的循环扫描，持续发现新增安全漏洞。同时，安全侧也借助变更管控平台，感知最新发布的应用，对新发布应用域名做快速扫描

　　运营阶段：在此阶段，安全侧会通过威胁情报、日志审计、入侵检测系统、应用防火墙等工具，持续监测和发现入侵或危险行为，完成安全应急响应工作。同时，也持续优化安全工具的相关规则和应急响应流程

　　五. DAST&漏洞管理

　　在整个安全开发流程中，动态应用安全扫描(DAST)的好处非常明显，它可以对正在运行的应用进行检测，与开发流程的耦合要求相对较低，但漏洞产出的准确率高，能有效降低企业整体安全风险。因此，有效的 DevSecOps 可以说始于 DAST 带来的检测结果，在解决实际的安全风险的同时，也能够帮助发现DevOps流程中欠缺的安全相关能力，而后续的漏洞管理也是安全工作中必不可少的一部分。所以，本文就重点讲述DAST及漏洞管理这两方面的工作。

　　5.1 资产暴露面管理

　　与外部渗透攻击需要有效的外围打点工作同理，为了达到有效发现企业安全风险的目的，首先需要尽可能完善的收集企业的外部暴露资产。在企业内部视角下，资产的收集虽然没有外部视角那么困难，但在混合云环境下，主机及域名资产复杂，依然会存在一些难点，例如：

　　资产信息分散记录在多个内部平台

　　内部平台缺乏资产网络环境字段

　　个别资产在内部平台记录缺失

　　为了解决资产管理中的问题，安全侧通过整合主机型入侵检测系统(HIDS)、DNS管理平台、资产管理平台、云管理平台等内部系统中的资产信息，同时在整合过程中补充网络环境判断及测绘能力，从而梳理出更有效和完整的公网资产暴露面信息，并通过安全SIEM平台的资产管理模块记录及定时更新相关资产信息。

　　5.2 B站动态应用安全扫描系统-Sibyl

　　目前B站的DAST使用了自研漏洞扫描系统-Sibyl，扫描系统以前文所述的SIEM平台资产信息为数据源，扫描覆盖了发布和运营阶段，主要包括URL漏洞扫描，应用漏洞扫描和基线扫描三部分，如图6所示：

　　URL漏洞扫描的数据源来自变更管控平台和SLB平台，Sibyl主动获取应用变更信息，自动关联应用相关域名及path信息，将扫描目标传入扫描节点进行漏洞扫描。此阶段为准实时扫描，针对变更应用的扫描会变更后的几分钟内完成。扫描规则以非侵入性规则为主，不对扫描目标做路径爆破、数据写入等高风险操作

　　应用漏洞扫描针对B站全部公网域名及IP，经过服务探测后，将确认存在HTTP服务的资产传入扫描节点进行漏洞扫描。与URL扫描不同，应用漏洞扫描的规则会包含扫描引擎支持的所有扫描规则，扫描周期相对较长，正常为每周完成一次周期扫描

　　基线扫描主要是针对B站全部公网IP，检测是否有安全基线中要求不允许对外暴露的服务或端口。与前两部分漏洞扫描不同，此部分扫描依靠服务识别工具对所有TCP服务及端口进行探测，发现例如ssh、mysql、rdp等高敏感服务开放即上报基线漏洞。由于基线问题风险极高，往往带来边界突破等严重安全风险，所以扫描周期更短，正常情况下每天完成一次周期扫描　　

图 6

　　5.3 漏洞管理平台

　　漏洞管理的重点无疑是明确漏洞的状态及处置流程，保证安全漏洞都能够被及时闭环修复。为此，安全部门自研漏洞管理平台实现了从漏洞发现到修复的整个流程跟踪，目前所有类型的安全漏洞都会统一提交至漏洞管理平台来实现漏洞生命周期的闭环：

　　漏洞分为5个状态：待审核、待修复、待复测、已修复、已忽略

　　漏洞的操作和处理流程如下，详细流程如图7所示：

　　安全人员对待审核的漏洞进行有效性确认并完成审核，审核过程中将漏洞流转给相关研发人员，漏洞进入待修复状态

　　研发人员确认漏洞修复完成后进行提交复测，漏洞进入待复测状态

　　安全人员对待复测的漏洞进行复测，确认修复完成则漏洞处置流程结束，如果漏洞未按要求完成修复，则漏洞状态回退至待修复状态

　　漏洞管理平台当然少不了统计和报表相关功能，平台可以根据漏洞数量、漏洞修复率、修复时长等维度生成实时或周期漏洞报表　　

图 7

　　5.4 漏洞管理规范

　　为了保证安全漏洞能够得到充分重视和及时修复，避免安全漏洞导致的攻击事故和攻击事件，公司范围内推行了《安全漏洞管理规范 》，规范明确了安全漏洞的定义、评分标准及处置规定：

　　漏洞评分的计算规则为漏洞基础评分 * 业务影响因子，漏洞基础评分的计算公式参照国际通用的CVSS 3.1，业务影响因子参照公司内部的服务分级标准定义不同权重因子

　　漏洞的等级分为严重、高危、中危、低危四个等级，每个等级的漏洞有不同的响应时效、修复期限和通报范围

　　漏洞处置包含延期升级机制，若漏洞未在要求修复期限内完成修复，则漏洞会按规范进行升级并扩大通报范围

　　六. 后记

　　笔者有幸经历了B站应用安全的从0到1的建设，也逐渐认识到安全能力的落地不可能独立于业务发展和基础建设。目前，已经有很多安全工具完成了跟现有开发流程的对接，在此过程中很感谢基础架构同事们的大力支持，针对每一个安全工具的对接落地过程也都有很多值得讨论和思考的地方。此外，数据安全目前还有很多未完成的工作，如何将数据生命周期安全和DevSecOps更好的结合也是未来需要努力的方向，这些内容会随着安全工作的持续推进在后续文章中继续向大家分享。最后，引用一句大佬的话：安全是个即“严肃”，又“专业”，同时又容易“被忽略”的活动，任重而道远。