我的安全视界观

2026年5月，安全公司Push Security披露了一起针对ChatGPT用户的新型供应链攻击——LLMShare。攻击者利用ChatGPT的共享功能（chatgpt.com/s/）托管恶意HTML页面，并通过Google广告精准投放，诱导用户下载伪装成"ChatGPT桌面应用"的恶意软件。 与传统钓鱼攻击不同，这次攻击的核心在于滥用可信平台：恶意内容完全通过ChatGPT官方域名渲染和托管，用户看到的是"chatgpt.com"的链接，天然放松警惕。这种"借壳"攻击方式，标志着AI平台正在成为新的攻击面。 这起攻击最值得警惕的，不是技术手段有多高明，而是攻击平台的演变。过去，攻击者要搭建一个可信的钓鱼网站，需要注册域名、部署服务器、申请SSL证书——每一步都可能暴露痕迹。现在，他们直接利用OpenAI的官方域名来托管恶意内容，成本极低，隐蔽性极强。 对于企业安全团队来说，这意味着"域名可信 ≠ 内容可信"的旧假设正在失效。我们需要重新划定信任边界，不能因为内容托管在知名平台就放松警惕。 更值得思考的是：这种攻击方式会不会蔓延到其他AI平台？Anthropic的Claude、Google的Gemini、百度的文心一言——它们的共享功能是否也存在类似漏洞？ AI安全，不只是防止AI被攻击，还要防止AI平台被滥用。 #安全事件#LLM攻击

2026年5月11日，知名TanStack开源库遭供应链劫持，攻击者通过钓鱼获取维护者OIDC令牌，向62个官方包植入凭证窃取代码。该库周下载量逾1200万次，恶意版本在数小时内完成全球扩散。OpenAI两名员工终端恰在此窗口期中招，导致少量代码仓库凭证泄露。 此事虽未酿成灾难性后果，却暴露出软件供应链的深层脆弱性：一次精准钓鱼 → npm账户沦陷 → 全球依赖链污染 → 大型企业员工终端被突破。整个杀伤链中，企业自身几乎无防御抓手。 作为安全从业人员，我认为最值得警惕的不是"OpenAI也被黑了"，而是这次攻防的时间差：传统"定期扫描"模式对此类速闪投毒完全失效。真正有效的防御必须是实时、自动化的。给同行三点建议： 1、引入SBOM及实时SCA，将开源依赖可视化为资产； 2、开发终端零信任化，持续加强终端安全检测-异常行为； 3、与关键开源社区建立直连应急通道，争取在投毒窗口前的预警时间。 此次OpenAI的应急响应可圈可点——迅速轮换签名证书、强制macOS用户更新——体现了风险意识。但对更多企业而言真正的考题是：当你的核心业务依赖万千开源组件时你能在攻守时间差中守住几道防线？

AI真强，从事产品安全的我们

网络安全从业人员使用AI遇到的困境

时光荏苒~之前，看到很多人都感叹时间过得太快，这次轮到我了。这是我的首个十年工作总结，主要事件、主要作品及主要感悟，虽零散但是我世界中闪亮的星。

2026校招面试，也许是因为这项工作占据了我很多时间，并且刚阶段性的落幕；或许还因为多年来我接触了很多毕业时能力参差不齐的校招生，对于他们的发展有一些观察与思考。

截止2025国庆节前夕，SDL100问系列文章已经完结，也意味着SDL三部曲（SDL最初实践、SDL100问、SDL创新实践）已输出超过2/3。虽说时间比预期多花了1倍，不过好在顺利完成。一个阶段的结束，这对自己来说也是新的开始~

在回顾该问题时，发现提问者并没有把问题定位得很清楚，导致在没有人追问的情况下，大家给出的应答也不具体。说它不清楚在于内部漏洞，在我看来至少有两个主要来源： 1、产品发布上线前各类安全测试发现的漏洞：这种情况其实有比较明确的修复要求，至少是要在系统发版前完成修复，如果做得更好的话，也可以制定明确的修复时间来推动业务方修复，但这个时间一定是要与发版时间相比较，把短的用来做deadline； 2、产品或内部资产运行状态下日常漏扫漏洞：这类漏洞主要是针对内部资产或外部互联网侧的应用，缺少明确的时间参考系，所以要制定修复时间，可以细分出优先级。比如互联网侧的信息系统修复时间要求比内网的短，高危漏洞比低危修复时限要求短，从执行来看互联网系统按照几天甚至几小时比较合适、内网系统按照几周或1个月比较合适。 针对逾期修复的情况，可以在内部做红黑榜进行推动，可以设置安全风险分数（逾期修复天数*漏洞风险等级对应的权重*存在漏洞的资产重要性对应权重），然后按照部门进行风险分数计算并在全公司晒榜，以此激励大家修复漏洞。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 开发安全左移和右移，哪一个更好？ SDL 99/100问：如何进行软件安全需求分析？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件

软件的安全需求是其自身安全性的源头，但往往由于客户没有足够的输入、对相关法律法规或行规不重视，所以可能做得并不好，对于不出海的产品、问题尤为突出。 在SDL运营过程中，最普遍的矛盾就是：业务设计如此、不修复，但在安全看来很危险。若是产生这种矛盾，一般都是由于设计或需求没有考虑安全性导致的，改起来很麻烦，所以最开始提出安全需求并跟进落地是十分必要的。 安全需求除了来自客户明确要求、法律法规、行业行规外，还可以结合公司的技术栈、常见安全问题来做要求，比如要求使用公司私有源中的开源组件、使用公司的开发框架进行开发、使用安全函数组件进行功能实现等。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 开发安全左移和右移，哪一个更好？ SDL 97/100问：关于白盒测试，应该知道哪些正确观念？ SDL 98/100问：针对业务部门外采购的产品，要求做安全测试吗？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件

对于自研产品安全做得好的公司，外购软件的安全性成为木桶中最短的板，通常会要求供应商做安全测试，并且已经有了比较成熟的做法： 1、上线前安全测试：指针对外购的业务系统进行安全测试，把发现的漏洞同步给供应商，甚至还会被供应商索要修复漏洞所消耗的人天费用； 2、交付时安全检查：属于安全左移的第一步，要求供应商提交所售产品的安全测试报告、代码审计报告、开源组件清单、对外开放端口矩阵等，供采购方安全团队审核，并把检查结论做为上线前是否符合安全测试的门槛，不符合就不做安全测试、就不能上线； 3、立项时安全要求：上面的内容还是有点被动，源头在业务部门提交需求给采购部门时，应该把安全相关的要求放进去，比如安全要有技术评标权利、供应商具备一定的安全资质、后续发现漏洞需要设置响应时效、说明费用等。 目前国内已经有一个大趋势：针对供应商产品的安全，已经从结果扩展到过程、供应商自身的安全建设能力。除了要求供应商提供产品安全相关的材料，还要求提供执行结果的内部流程体系及机制，比如是否建立了专门的产品安全团队、是否有安全测试工具链等。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 开发安全左移和右移，哪一个更好？ SDL 97/100问：关于白盒测试，应该知道哪些正确观念？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件

白盒测试在SDL中，建设优先级应该是属于较高的一类，也被大家广泛讨论。通过长期运营后，发现有以下特点： 1、检出常见漏洞产出高，但绝对不是万能的：在黑盒和人工测试的基础上更进一步，那就是白盒扫描效果最好、而且能够发现更多的漏洞，类型以文件操作、注入类、硬编码等为主，对于有安全函数处理、污点追踪数据流中断、业务逻辑类漏洞，目前基本是没办法直接检出的； 2、靠人工运营才能落地，不能买来开箱即用：白盒的一大缺点就是误报高，可能高到最开始时无法推动漏洞修复，需要投入专业人员运营、规则调优后才可能投入生产使用。 截止目前为止，还没有一款应用大模型的白盒工具能够全面 PK 商业产品，希望未来能够出现。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 哪个厂商做SDL咨询服务和建设比较强？ 如何推动业务方修复开源组件漏洞？ 开发安全左移和右移，哪一个更好？ 什么是ASTRIDE？ 与外部厂商合作时，外发敏感数据有啥好方案？ 针对开发安全管理的面试，一般都会问哪些问题？ 针对有漏洞的代码，安全怎么不让发版？ SDL 96/100问：如何对软件项目安全性进行度量？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

对产品的安全性度量，可以从以下两方面找一些指标： 一是开发态下执行安全要求的情况，包括业务线上线前是否经过安全测试（安全评审/静态代码扫描/黑盒安全扫描/人工安全测试等），是否满足安全要求后才发布上线（已发现漏洞修复情况），考察业务部们落实安全要求的情况，常见指标有漏洞数、漏洞修复率、XAST扫描覆盖率等； 二是运行态下产品安全情况及趋势，包括开发过程中执行安全要求的质量、发现安全事件应急响应、各类安全防护开启与否等情况，常见指标有安全事件数、应急响应时间、违规数等。 就单个项目而言，如果用于开发安全管理及汇报，前者提到的指标更适宜用于度量，因为项目交付后可能就是客户或其他团队在负责，需结合实际情况来定。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 哪个厂商做SDL咨询服务和建设比较强？ 如何推动业务方修复开源组件漏洞？ 开发安全左移和右移，哪一个更好？ 什么是ASTRIDE？ 与外部厂商合作时需要外发敏感数据，有啥好方案？ 针对开发安全管理的面试，一般都会问哪些问题？ SDL 95/100问：针对有漏洞的代码，安全怎么不让发版？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

先简要的回答这个问题，安全团队必须具备话语权与技术性卡点能力，二者缺一不可。 1、话语权：需从决策层（如 CEO、CTO）推动安全纳入业务优先级，再向下穿透至研发、运维、业务等全链条； 2、技术卡点：在 CI/CD pipeline 中构建不可绕过的安全关卡，通过 SAST/SCA 等工具自动化检测，并与发布系统强联动 - 未通过安全基线（如高危漏洞清零、合规证明完备）的版本，无论业务紧急程度如何都不允许上线。或与产品管理IPD流程的TR评审强关联，安全需要评审才能通过。 关于技术卡点，要准备例外审批机制，但需设置极高的门槛（如 CTO 级签字 + 漏洞修复时间表），以备特殊场景之需。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 哪个厂商做SDL咨询服务和建设比较强？ 源代码扫描，是做仓库的全量扫描还是增量扫？ 如何推动业务方修复开源组件漏洞？ 开发安全左移和右移，哪一个更好？ 什么是ASTRIDE？ 与外部厂商合作时需要外发敏感数据，有啥好方案？ SDL 94/100问：针对开发安全管理的面试，一般都会问哪些问题？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

这个岗位对标的可能是应用安全负责人、应用安全工程师－开发安全体系建设方向，被问到的问题大概会围绕以下两点展开： 1、开发安全面临哪些安全风险，如何治理或开展工作？ 2、开发安全体系、工具、流程如何建设及运营，有哪些指标？ 在此基础上，负责人岗位还会被考察以往带队情况、向上沟通等偏向于人员、工作内容管理类的问题。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 哪个厂商做SDL咨询服务和建设比较强？ 源代码扫描，是做仓库的全量扫描还是增量扫？ 如何推动业务方修复开源组件漏洞？ 开发安全左移和右移，哪一个更好？ 什么是ASTRIDE？ SDL 92/100问：在测试代码审计类产品能力时，有没有好一点的开源项目推荐？ SDL 93/100问：与外部厂商合作时需要外发敏感数据，有啥好方案？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

对外进行数据对接，是比较常见且风险比较高的业务场景，需要结合具体的业务场景来设计安全方案或做安全评审，不过通用的思考框架也是有的： 1、必要性：是否必须提供原始的敏感信息到第三方，对方通过API的方式过来查询或计算，取结果回去是否可行； 2、最小化：敏感的业务数据最小化传出去或加入计算，有时候开发会为了方便就用现有的数据接口； 3、设验证：针对API对接的场景，尽可能做各种维度的验证，比如对方出口IP、调用权限等； 4、可审计：无论是API对接还是数据拷贝的场景，都需要做数据出司的审计，可以是邀请第三方相关部门审计、业务打印日志做模型审计。 以上四点可以根据实际业务场景扩展、细化，亦可结合实际需求加入新的维度，完善安全评估方案。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 哪个厂商做SDL咨询服务和建设比较强？ 源代码扫描，是做仓库的全量扫描还是增量扫？ 如何推动业务方修复开源组件漏洞？ 开发安全左移和右移，哪一个更好？ 什么是ASTRIDE？ SDL 92/100问：在测试代码审计类产品能力时，有没有好一点的开源项目推荐？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

从所提的问题来看，提问者肯定是比较懂安全测试工具的能力测试，比如乙方公司会用市面上开源或知名的漏洞靶场来做测试。相比较真实的项目，这些靶场明显代码量更少、漏洞更容易被发现，所以检测能力都很强。 但到真实业务代码的环境后，表现肯定会打折扣。所以可以反过来思考这个问题，先参考厂商的检出率、客户案例等，然后同时安排多个进行POC测试，无论是检出率、易用性都能得到真实的体验。 此外，一定要明确SAST工具的作用范围，绝不是所有漏洞都应该被检出，其次还要进行人工运营。所以，在测试时应该加入误报率之类的反向指标。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 日常的漏洞运营，也应该是SDL团队来做吗？ 关于开发安全BP，对开展SDL有哪些帮助？ SDL 87/100问：哪个厂商做SDL咨询服务和建设比较强？ SDL 88/100问：源代码扫描，是做仓库的全量扫描还是增量扫？ SDL 89/100问：如何推动业务方修复开源组件漏洞？ SDL 90/100问：开发安全左移和右移，哪一个更好？ SDL 91/100问：什么是ASTRIDE？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

关于ASTRIDE的出处，目前接触到最多的声音就是华为，具体就是指隐私合规方面。因为参加过多次华为TQC组织的培训和技术沙龙，对于此深有所了解。在面向全世界的一家公司里，隐私合规无疑是重中之重，所以并不难理解为什么华为这么做。 但对于其他厂的启发呢？始终应该围绕自己的业务场景、公司面临的内外环境来做调整，大方向就是可以左移到需求阶段。在产品刚开始做的时候就加入各类法规、安全要求，进而做合理的plan排期，在过程中如测试阶段进行验证，从而形成需求-测试验证的闭环，主动把控网络安全风险。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 日常的漏洞运营，也应该是SDL团队来做吗？ 关于开发安全BP，对开展SDL有哪些帮助？ SDL 87/100问：哪个厂商做SDL咨询服务和建设比较强？ SDL 88/100问：源代码扫描，是做仓库的全量扫描还是增量扫？ SDL 89/100问：如何推动业务方修复开源组件漏洞？ SDL 90/100问：开发安全左移和右移，哪一个更好？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

左与右其实是相对的，都是指在软件开发生命周期上开展的安全活动，一般来说会把上线作为左右的分界点。 左移固然好，因为在需求、设计阶段或编码时发现漏洞的修复成本，会远低于产品发布到线上带来的修复代价。随着云原生的普及，右移逐渐超过了上线出安全事故时做应急响应、上线后做渗透测试，还包括了线上运行时做安全防护、入侵检测等。 从业务系统的全生命周期来看，安全需要左移、也需要纵深防御，所以应该是无处不移，开发安全需要开发态下的安全保障，也需要运行态时的安全防护，具体的实践应该以现有安全状态为基础、结合实际情况而定。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 日常的漏洞运营，也应该是SDL团队来做吗？ 关于开发安全BP，对开展SDL有哪些帮助？ SDL 87/100问：哪个厂商做SDL咨询服务和建设比较强？ SDL 88/100问：源代码扫描，是做仓库的全量扫描还是增量扫？ SDL 89/100问：如何推动业务方修复开源组件漏洞？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

在这个问题上，想必很多同业人员都会遇到。其中最理想的就是把修复开源组件漏洞定位为公司级要求，避免陷入与业务方证明漏洞危害性的对抗局面。 然而要推动成为公司标准，也绝非易事，此处我将介绍自己亲身推动的、较为理想的过程 - - 客户驱动或业务驱动。在我们服务的客户里面，有漏洞修复标准非常高的客户，曾要求CVSS≥4.0都需要修复或给出不修的理由。从侧面来看，客户的要求帮我们在内部推动产线修漏洞。 另外还可以借助公司的大事件来推动漏洞修复，又一例子是我们进行冬奥网络安全保障时，要求所有部署到现场的产品都要足够安全。于是我们趁机将SCA的扫描结果修复，安排成为其中一个专项，在大事件面前产线配合的非常好，此后我们就把这个专项纳入到日常安全测试流程中、并写成规范常态化运行。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 日常的漏洞运营，也应该是SDL团队来做吗？ 关于开发安全BP，对开展SDL有哪些帮助？ SDL 87/100问：哪个厂商做SDL咨询服务和建设比较强？ SDL 88/100问：源代码扫描，是做仓库的全量扫描还是增量扫？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟

说起源代码扫描，主要安全活动是SCA和SAST，前者是扫描开源组件已知的漏洞、后门及开源许可证，后者主要是对自研代码漏洞做扫描。 关于增量or全量？这对SAST的结果影响比较大，因为当前主流SAST工具的检测核心逻辑：仍然依赖数据流污点追踪技术，而代码完整性的缺失，会直接导致漏洞检出率下降。 不过在SAST检出的漏洞类型中，也有不影响检出率的情况，比如硬编码密码等敏感信息泄露的检测。从效果来看，还是建议做扫描全量，与此同时则要解决扫描速度和性能的问题。 ------------更多内容，请访问------------- 1、SDL 100问 SDL100问：我与SDL的故事 SAST误报太高，如何解决？ SDL需要哪些人参与？ 大家都有哪些SDL运营指标？ 业务系统是否可以带漏洞上线？ 日常的漏洞运营，也应该是SDL团队来做吗？ 关于开发安全BP，对开展SDL有哪些帮助？ 上传图片的API，除了常见web漏洞外，是否还会有风险？ SDL 84/100问：国内是否有做安全基线的厂商或这个方向的专家？ SDL 85/100问：在推进SDL时，一般选择什么类型的员工作为对接人？ SDL 86/100问：水平越权属于STRIDE中的哪一种？ SDL 87/100问：哪个厂商做SDL咨询服务和建设比较强？ 2、SDL创新实践 首发！“ 研发安全运营 ” 架构研究与实践 DevSecOps实施关键：研发安全团队 DevSecOps实施关键：研发安全流程 DevSecOps实施关键：研发安全规范 DevSecOps实施关键：研发安全工具 从安全视角，看研发安全 数字化转型下研发安全痛点 一个思考：安全测试驱动产品安全？ 3、SDL最初实践 【SDL最初实践】开篇 【SDL最初实践】安全培训 【SDL最初实践】安全需求 【SDL最初实践】安全设计 【SDL最初实践】安全开发 【SDL最初实践】安全测试 【SDL最初实践】安全审核 【SDL最初实践】安全响应 4、安全运营实践 基于实践的安全事件简述 安全事件运营SOP：钓鱼邮件 安全事件运营SOP：网络攻击 安全事件运营SOP：蜜罐告警 安全事件运营SOP：webshell事件 安全事件运营SOP：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟