我的安全视界观

2026年3月下旬，Anthropic 一周内连续两次"手抖"： 第一波（3月26日）：CMS 配置错误，近 3,000 份内部文件暴露，含未发布模型 Claude Mythos（Anthropic 自述"网络安全能力远超任何其他 AI 模型"）。 第二波（3月31日）：npm 发布 @anthropic-ai/claude-code v2.1.88 时遗漏 source map 过滤，59.8MB .map 文件暴露 51.2 万行源码，GitHub 社区 4.1 万 fork 疯狂传播。 从企业安全视角，我们习惯关注 APT、零日漏洞、供应链攻击，却往往忽视一个更基础的问题：发布流程的可靠性。 Claude Code 的架构设计令人叹服 - - 46K 行查询引擎、40+ 工具权限门控、多 Agent 编排、Bun 运行时、React + Ink 终端 UI。但一个忘记勾选的配置，就让所有努力付诸东流。 这个事件值得每一家 AI 公司引以为戒：当你的模型能力越来越强，你的流程是否也同步变强了？

2026年6月2日，安全初创公司depthfirst宣布其自主AI安全代理在FFmpeg多媒体框架中发现了21个已确认的零日漏洞。这一发现标志着AI驱动的安全研究已经进入实战阶段。 关键数据：约1,000美元成本，扫描约150万行C代码，发现21个零日漏洞，每个都附带可复现的PoC。部分漏洞潜伏时间长达15-20年，涉及堆溢出、栈溢出、整数溢出等多种内存安全漏洞。 FFmpeg作为全球使用最广泛的多媒体处理库之一，被应用于浏览器、流媒体平台、监控系统、移动应用和嵌入式设备。这意味着这些漏洞的影响范围极大，全球数百万应用和设备可能受到影响。 从安全专家视角来看，这一事件带来三重启示： 其一，AI代理的安全研究效率远超传统人工审计，但攻击者同样可以使用相同技术； 其二，开源软件供应链安全需要更系统的管理和监测机制； 其三，安全团队需要升级能力，学习AI安全技术，建立人机协作的新范式。 FFmpeg安全团队已确认漏洞存在并着手修复。作为企业安全负责人，建议立即盘点内部FFmpeg使用情况，建立SBOM清单，升级到最新版本，并持续关注官方安全公告。 AI时代的安全形势正在加速演变，唯有主动拥抱技术变革，才能在这场攻防博弈中占据先机。

提示注入漏洞让一个 GitHub Issue 变成了供应链核弹——影响面 ~1.7 万个仓库，而修复窗口只有 4 天。 真正的风险不在于这个漏洞本身，而在于：当 AI 编程代理大规模进入企业 CI/CD 流水线之后，类似的提示注入漏洞会成为攻击者的标准入口。我们现在不把安全框架建立起来，等出事的时候就晚了。 给企业安全团队的三条硬建议： 1、立即做资产清点 有没有在用 GitHub Actions？有没有引入 AI 编程代理（Claude Code / Copilot Agent / 其他）？ 如果答案是"有"，先搞清楚权限范围是什么——别等出了事再翻日志。 2、最小权限 + 零信任，现在就做 1）AI 代理只给完成任务所需的最小权限，多一个 scope 都不行 2）Pin GitHub Actions 到 commit SHA（防止 tag 被移动投毒） 3）敏感凭证（npm token、API key）与 AI 代理隔离，别让它能读到 /proc/self/environ 3、 建立 AI 代理的审计和应急响应机制 1）启用 GitHub Actions 审计日志，监控异常的工作流触发 2）制定预案：当 AI 代理被入侵时，如何快速吊销凭证、隔离受影响仓库、回溯攻击链？ #AI编程代理#供应链攻击

看到 CVE-2026-0257（PAN-OS GlobalProtect 认证绕过）的细节，利用链和应急响应动作，一切都是那么熟悉。 边界类产品的暴露面最大——必须开放端口、接受外部连接、拥有最高权限。它们是攻击者的首选目标，应急响应优先级应该是最高之一。 安全团队也不能"灯下黑"。 我们天天提醒业务团队打补丁、限制访问、开 MFA， 却往往忽视自己管理的边界类、集权类安全产品： 1、防火墙/VPN 控制台暴露公网，补丁延迟打； 2、EDR/XDR 控制台"只有内网能访问"，就放松警惕； 3、漏洞扫描器、IAM/SSO 自身安全性被遗忘。 做好防护，不止是限制 IP 访问。还要加强： 1、异常行为监测：关键 API（登录、配置修改）的异常调用； 2、账号行为审计：重要账号的操作日志、基线行为模型、实时告警。 #安全产品#漏洞利用#安全事件#PaloAlto

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：接收漏洞事件 应急能力提升：实战应急困境与突破 应急能力提升：挖矿权限维持攻击模拟