SDL已死，应用安全路在何方？

前言

应用安全仍是重点投入领域

SDLC遇到的问题

    安全并不是安全团队可以独立解决的事情

    加强设计和部署阶段的投入是大势所趋

    SDLC适合软件开发，云和devops定义了新时代

    SDLC没有实现让业务承担责任

    落地过程中缺乏协同性

    缺少拥抱和激励安全的文化。

    以大多数公司的基础安全建设来说，还不配做SDLC

真实的安全开发生命周期

    软件安全开发真正要思考的问题。

    为业务团队赋能

    自动化能力的方向

    重新审视纵深防御

    教练的角色

    让漏洞利用时间更长

ROI量化分析

本文关键字：应用安全，研发流程，团队协作，安全短板

前言

    在安全行业，SDLC（软件安全开发生命周期）已经死了，如果各位安全从业人员还在追求所谓的微软最佳实践，立足的根本理念已经落后；如果信息安全管理者还看到下属做此类SDL的规划，那就是在浪费组织宝贵的预算。由微软早期提出的SDLC已经不适应现在的网络安全生态，不要照猫画虎不成反类犬，不要神化SDL理念，要看到与时俱进的安全风险，关注真实的风险治理。定位业界最佳实践可以是安全团队的追求，但更要立足于企业在大趋势下的安全背景。业界追求技术卓越的公司已经放弃了单纯在SDLC方向的投入，只有那些低头走路的小伙子，依旧在故纸堆里寻安全。

应用安全仍是重点投入领域

    攻击者的重要漏洞利用依旧是紧盯目标在软件安全领域的薄弱点持续渗透，下面的图表数据来源于Forrester Analytics Global Business Technographics Security Survey, 2019。

    数据显示企业受到的排名第一第二的主要攻击风险点依旧是软件安全漏洞和web应用程序，软件安全仍是目前攻防对抗中资源投入的最佳切入点，后期的精彩的内网对抗往往依赖于外部首先撕开口子。相信国内大多数的企业信息安全负责人上任的第一件事就是补锅，花费大量的时间精力去聚焦目前的已知风险--不要让攻击者直接通过软件漏洞getshell。所以应用安全以及囊括的二进制，web、IOT安全领域，始终是企业安全战略人才和资源投入的重点。同时在企业内部软件库，软件包，镜像的风险随着是安全技术的推移没有得到改善。现在的软件开发行业提倡不再重新发明轮子。每年新增约55%的新项目通过开源社区在踊跃发展。

    安全人员知道这些底层的应用程序库漏洞在两年内增加了 88%（本来很安全，有了安全人员就不安全了-_-）。另有调查显示虽有81％的从业人员认为开发者应当负责开源软件的安全性，但只有 30% 的开源软件维护者认为自己具有较高的安全意识。现在的应用安全言必声称更关注软件安全早期阶段，是因为形势很严峻，78%的第三方漏洞是在间接依赖中发现的，实际修复工作做起来对于研发和安全来说都十分复杂，那么SDLC可以做到什么？或者说SDL在这期间缺失了什么？

SDLC遇到的问题

安全并不是安全团队可以独立解决的事情

    容器安全为例，容器作为新兴的技术，我们理所当然认为会包含一些实用精良的安全理念。实际上并非如此：经过研究显示，十大最流行的默认 Docker 镜像中，每一个都包含至少 30 个易受攻击的系统库，很多linux发行版和中间件都很脆弱，安全人员给的解决办法永远都是一句话：升级版本,重启。但是在深耕容器应用安全领域，可以做的事情有：

    看看哪个是SDLC完全可以胜任投入的领域？业界从业人员反复强调，嵌入到SDLC中解决去软件问题，要在生命周期中解决较早的那些漏洞，但是将现状是国内各家组织在安全性集成到开发过程中、按规划匹配安全人员配置、将业务线作为安全事务的主人翁方面不够坚决，目前在流程方面也缺少支持工具，在组织支持策略投入更做得不够充分。

加强设计和部署阶段的投入是大势所趋

    下图统计数据显示，软件静态分析在SDLC的应用中资源占比，涉及发布后的阶段的投入2020年将由40%下降到25%，投入将继续前移到更早的研发流程。

    根据笔者的观察，同上面的Forrester依据国外公司给出的统计数据比较，国内的SDL各个岗位资源投入比例是失衡的。依据公开的甲方安全部门分配的JD和人员岗位比例来看，从事安全测试，红蓝军，感知的人员，远远多于从事安全设计和开发安全的人员。

    不过值得注意的是，国内整体跟上国外的一个现象是在应急响应方面的实际投入也是整体逐步降低的，或者是处于先增后减的趋势。各家SRC的安全相关事情会变得越来越少。在企业安全建设的一定时间有个分界点：头部公司的SRC强者恒强，有钱的SRC用更多的奖励吸引核心白帽子，小公司的SRC弱者越弱，绝大部分的安全运营活动从漏洞盒子，众测外包就可以上线和覆盖。某些公司短期SRC的预算越来越多，奖金礼品越来越丰盛。但是总体看公司级别在应急响应活动中整体能收到的有价值的漏洞是收敛的，对企业安全建设有意义的漏洞越来越少（有价值的事情以后由内部蓝军承担）。那些听起来风声水起的活动大都是偏向宣传、影响力和社区运营的事情，真正的和企业核心安全能力提升的事情，读者们可以细细品，SRC是不是在发布响应环节和安全的关联越来越弱。

SDLC适合软件开发，云和devops定义了新时代

    数字化，移动性，云和物联网（IoT）都加剧了互联网企业IT环境的复杂性，安全成了安全团队的孤军奋战，SDLC或者倾向于敏捷的SDLC来不及适应企业开发模式。以申请线上资源的场景为例，一切主流的开发模式都定义了效率和敏捷性，上线是由业务团队定义，从阿里云、腾讯云、私有云申请机器快速扩容和灰度，安全团队没计划画出威胁建模图，数据流图通过云化定义。安全时间的的责任由传统IT所有权（早期安全是IT的事情，是运维的事情，他们提供的机器，他们打补丁，他们提供oracle安全服务），到开发人员现在拥有和必须实施安全相关的能力（通过容器的dockerfile，临时规避解决心脏滴血风险；通过机器快速下线和发版解决漏洞）。

    这里对新时代的协作模式举个例子打比方。保姆式（安全：我发现了几个安全风险，请你排期修复，谢谢。业务：我不听，我不听）、家长式（安全：这里有安全情报，你要修复，不然就嘿嘿嘿。业务：哦，知道了。）、保安式（安全：我家waf给你拦截了xx多的恶意请求，业务：这是啥事？你和我说干啥？）。但最终做事情，还是得依靠业务，安全不能亲自上手。

SDLC没有实现让业务承担责任

    在SDLC中，最差的体验是增加多个安全审核步骤，最后产品开发上线步骤繁琐而忐忑不可知。这些案例首当其冲的是各家公司引以为豪的：上线前安全扫描。安全团队要注意不要创建任何卡点的安全工具和流程。第二差的体验是发送安全工单，我发现了XX漏洞，请你按照XX修复，否则XX。SDLC做得不足也包括应对越来越重要的威胁情报无法自动化处理，即在基础设施建设中，没有安全技术实现面对威胁的缓解技术；也没有推动方便业务处理这些情况时快速解决方案，全都是等着业务挪动一下。

    SDLC确实是在生命周期做产品安全，但是责任共单模型是隔离在研发生命周期之外的。事实上开发人员和业务线应当是安全的首要责任者，培养主人翁意识是现在主流的协作模式，而不是仅仅做风险规避型的组织割裂者，让安全人员以安全角色帮扶介入业务团队是SDLC一直推崇的，但并未发挥业务是产品安全受益人和责任人的理念。

落地过程中缺乏协同性

    SDL流程是围绕安全专家执行对业务的产品应用安全性进行指导和评审，由业务作为ower改进，请读者们根据实际工作体会回答：会是谁老是通过邮件催着让安全修复有进展？安全，因为业务受限于安全的大棒。理想状况该是哪个团队？研发，因为研发应当主动寻求安全的合作。再举个缺乏跨团队协同的例子：笔者见过甲方团队出具的自研或者买的各种的商业扫描器的报告。如果是根据项目创建，会有各个项目部门的漏洞梳理，高中低危害的各种图表，但是这类安全渗透测试报告从来没有想过从业务方的角度，证明经过安全扫描的验证没有漏洞就拥有了一定的安全性，长期以为导致从事安全相关的工作配合对于开发团队是痛苦的吃力不讨好。  

    再举个例子：业务团队会问：报告没有安全漏洞显示，是说明我们业务没有漏洞吗？安全人员总是基于专业的谨慎回答：有可能是某些业务逻辑问题我们发现不了，扫描结果也不保证未来有风险。业务团队：我勒个去？扫了半天还不确定有没有问题，那你干啥了？安全人员：额， 我的扫描器经常扫描出一些IIS 7版本信息泄露的风险，我也不知道是不是对你们有用。

缺少拥抱和激励安全的文化。

    文化层面，想参与进业务的SDL安全团队输出的只有会议纪要、安全方案、安全工单，修复计划、晾晒的形象。安全团队也得带来正能量，平时缺少举办安全专项的结项活动。进行培训的时候，真实目的不是让业务团队指派某个小伙子在培训教室坐一天，而是主动确实将知识内置在日常开发生活中。哪怕是此次培训的次数和效果不足，安全已经对团队赋能进行正向长期激励了。

    文化的另一个前提是我们应当知道开发人员并非拥有公司现阶段发展必须的安全能力。在我国近期只有少量学校增加了网络安全专业，而面对针对计算机课程并没有软件安全的讲解。主力开发、设计、运维人员的安全意识来自于个人兴趣和工作中遇到的安全案例。所以重点是将更多的开发人员转变为安全人员，不是不停地将安全流程放在最重要的位置卡点灌输安全。将开发人员参与进来，了解安全概念以修复解决安全问题，并且尽量不中断现有研发流程。

以大多数公司的基础安全建设来说，还不配做SDLC

    在早期的企业建设领域里安全是成本，所以所谓的以SDLC为理念实施研发安全的框架做得再怎么好，都是在安全验证，发布和响应几个步骤里打圈圈，在培训，需求、设计、实现阶段并没有明显的长期价值产出。下图中，白框里的内容，安全团队都可以做得有声有色，但是红色框是基础领域的安全涉及公共组件、技术栈、系统安全、固有流程，安全是个项目集，虽是SDLC的工作范畴，但是深水区SDL已经搞不定了。等待基础建设完善了，SDLC才能给可落地的方案，不然威胁评审发现公司使用公司某底层sdk存在token泄露的风险，但是其他手段不完善，没有办法升级和记录日志，没有别的可行替代方案，只能做一些兜底措施。

    当然本文不是吐槽SDLC，在基础的纵深防御、默认安全、最小权限都是安全领域颠破不破的真理，但就以最小权限、按需申请的事情本身基于复杂的场景下，各家公司的底层技术栈大都没有做到满足安全能力，这是SDLC在基础安全的场景下的无奈之处。

    总结起来就是，在SDLC做工作是做不完的（现在的临时解决办法是安全运营理论），业界方更前置地做安全行不通；现在的具体安全事情，安全团队已经搞不定了，要培养开发人员的自我驱动安全；向上管理安全愿景；确保流程和配置支持共同协作。

真实的安全开发生命周期

    微软修正后的敏捷SDLC流程，看重专家的能力，最终实施起来势必是挑战重重，无疾而终。请读者们抛弃SDLC之类的框架图。 

    虽然说从群众中来，到群众中去。安全前置（国外也叫做shift left）也是伪命题。

    如果可以取其SDLC的精华，安全和开发团队该如何合作?

    笔者的答案是将安全能力在前置后置之间快速移动，研发团队更要后置到安全领域。真实的开发-安全关系和软件开发生命周期结合会是下图所示:

    前文提到81%的的人员认为业务团队应该为安全的最终结果承担责任，但是他们目前没有相对应的安全能力，同时也有33%的人员的认为安全相关特性使得产品难以实现快速交付上线。所以抓手在于安全是众多开发人员认为他们想拥有，但是实际上不具有的能力。

软件安全开发真正要思考的问题。

为业务团队赋能

    现在的情况是开发者（RD）、运维团队（SRE）是产生出产品安全漏洞的根本原因（你又在写bug代码了），也是实现安全修复方法的最终实施方。安全团队的重点是赋予业务团队安全能力，提供业务需要的安全数据，加以安全团队的判断标准，让业务逐渐内生安全。

自动化的方向

    安全团队每天有众多的测试报告反馈说明我们发现了xx问题，soc大显示器每天有多少的爬虫在尝试抓取信息，集团月报的网络攻击地图炮显示公司每天多么危险。但是给安全六个月的时间回头看，你会发现这个团队还是难以推动解决工作中具体的那些问题。相比于对黑客的入侵各种自动化匹配att&ck模型体现的专业能力，对于业务的自动化安服能力是业界相对较低的水平。有意识的团队是时候提升这方面的能力了。

重新审视纵深防御

    安全的木桶原理大家都知道，所以从业者做了一个简单事情，就是堵住木桶的短板。通过阻碍业务，增加安全流程，试图使得安全规则成为一个强制约定。这是正确的做事，但是没有做正确的事。安全不是一个团队事情了。

教练的角色

    有没有发现讨论安全方案时，有业务方的安全接口人或者开发leader在场时，就可以快速敲定安全加固方案。要重视和业务经常进行沟通。这是经常口头说，而从事攻防工作容易忽视的问题。教练善于提供方案而不是提出问题，不要争论安全是不是业务的KPI，出现安全问题，锅，是整个公司背。教练提供安全能力，比赛还是得业务上场，最后业务取得冠军。

    为什么安全要做业务的教练？这里再吐个槽：白帽子乌云社区里的修复方案里经常填这样句话：你们比我更懂。其实有时候是白帽子真不懂。增加参数过滤，校验不可信来源这听起来简单的方案不是想得那么简单，甲方安全团队收到报告针对修复方案要复盘review、拉通对齐、举一反三排查其他漏洞，同业务对时间方案，结果老是救火。业务方也得了解啥是漏洞，结合自己发版的计划，测试计划，判断是否可以下线，安全替代方案是啥，对增加的工作量排期。

    要改变这个情况的正确做法是接到白帽子报告后，业务是第一责任人，安全团队从专业视角给出修复方案，业务自查是否有类似的风险，安全负责验证业务是否完全修复，业务为安全提供数据接口方法供安全长期验收提升安全能力。

让漏洞利用时间更长

    这个谷歌project Zero的目标，也可以作为安全和业务团队整体的目标。简单的指标考虑基础安全建设阶段的完善性，这才是安全干的专业安全事情么。业界具有前瞻性或者领导力的公司如FLAG毫不留情地在进行此类实践，而不是无止境的投入安全建设。

    当然这样要求安全团队有更多的灵活性，在安全原则方面需要引入业务更多的参与，比如在安骑士上看到了某个漏洞的提示，业务想要忽略漏洞（比如内部系统Memcached的拒绝服务，业务认为可以不管），安全团队当然可以同意，因为来自业务的评估是更准确的，并不是有漏洞就得修复，只是个cve而已，并没有实际的影响，不算”真实的漏洞“，也不影响安全的主业：”让漏洞利用的时间更长“

ROI量化分析

    无论是一项活动还是方案，CTO和CIO都要考虑这件事情的成本和收益，即投资回报率ROI，TCO、ROI在安全团队中会体现多少资源，多少JD人力、多少服务器、多少需要业务配合的沉没成本、多少采购预算。下图模型可以帮助读者量化收益技术方案和影响力的方法，分为业务收益、成本，实施和其他因素的影响成本。    经过转变在传统SDLC的实施方案中安全是业务的额外投入，是ROI永远为负的场景。以某公司为例，额，假设是东北某公司实现以下愿景：

    安全团队负责人尼古拉斯 赵四给辽宁民间艺术团老板刘老根画出饼：目前在安全团队的资源投入做的事情给公司的带来的潜在收益分为四个方面：

    解决目前的安全风险有可能造成的损失，防患于未然

    开发了大量工具节约了查找和修复漏洞节约成本

    研发和安全的合作减少了安全事件和修复漏洞所花费的时间

    为产品提供安全能力，加强公司市场竞争力

    读者们可以将这样的思路转变在实际的工作中，愿你的安全工作带来的ROI永远为正。这里笔者仅仅是缀文提出了自己的怀疑，欢迎大家踊跃探讨，留言请轻拍砖。

 

项目发布 | OWASP Top 10 Proactive Controls V3中文版

 

供应链安全：安全建设中的第三方组件依赖问题

 

谈谈开展信息安全工作的四个权力

 

由阅兵想到安全建设不要井底之蛙

 

如何有效阅读安全类文章

 

基层安全管理者需要具备的素质