xiaohack's Blog - 静态分析
type: channel
link: https://blog.xiaohack.org/tag/%E9%9D%99%E6%80%81%E5%88%86%E6%9E%90/
items: 架构评审与技术债治理——质量属性、演进式重构与风险评估框架
items: 【论文分享】从混乱到清晰：面向安全分析的综合性JavaScript反混淆
items: SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具
items: 【论文分享】从噪声到信号：如何在千万级软件包中精准定位漏洞影响？
items: 重塑传统自动化漏洞挖掘的Multi-Agent框架攻防一体化实践
items: 微服务应用漏洞自动化挖掘MScan的实现与实战（下）

架构评审与技术债治理——质量属性、演进式重构与风险评估框架
type: item
date: 2026-02-04T06:30:00+08:00
description: 写在前面，本人目前处于求职中，如有合适内推岗位，请加：lpshiyue 感谢。优秀的架构不是一次性的设计杰作，而是通过持续评审、债务治理和渐进式重构形成的有机体系在构建了高可用的容灾体系后，我们面临一个更根本的挑战：如何确保系统架构本身具备持续演进的能力？架构评审与技术债治理正是连接短期交付压力与长期架构可持续性的关键桥梁。本文将深入探讨架构质量属性、演进式重构方法论与风险评估框架，帮助企业构建既满足当前需求又适应未来变化的弹性架构体系。1 架构可持续性：从静态设计到动态演进1.1 架构治理的范式转变传统架构观将系统设计视为一次性活动，而现代架构实践强调持续演进的理念。根据行业数据，拥有成熟架构治理体系的企业在系统维护成本上比缺乏治理的组织低40%，新功能交付速度快35%。架构可持续性的三大支柱：质量属性守护：通过明确的质量标准防止架构腐化技术债主动管理：将债务治理融入日常开发流程演进式重构机制：在保证业务连续性的前提下持续优化这种转变使架构工作从项目制活动转变为产品全生命周期的核心实践，确保了系统在整个生命周期内保持健康状态。1.2 架构评审的价值重估有效的架构评审不是障碍而是赋能，其核心价值体现在三个维度：风险防控价值：提前识别设计缺陷，降低后期重构成本。数据表明，架构阶段发现的问题修复成本是编码阶段的1/10，生产环境的1/100。知识传递价值：通过评审过程促进团队间架构共识，减少认知偏差。质量内建价值：将架构原则和质量要求植入设计阶段，而非事后修补。2 架构质量属性：可持续性的衡量基准2.1 核心质量属性体系架构质量属性为评审提供客观标准，避免主观判断的随意性。完整的质量属性体系涵盖多个维度：运行期质量属性关注系统执行时的表现：性能：响应时间、吞吐量、资源利用率可靠性：故障率、可用性、容错能力安全性：数据保护、访问控制、漏洞防护演进期质量属性影响系统变更和维护成本：可维护性：代码清晰度、模块化、文档完整性可扩展性：水平/垂直扩展能力、耦合度可测试性：单元测试覆盖率、集成测试便利性// 可测试性设计示例：依赖注入提升可测试性 public class OrderService { private final PaymentGateway paymentGateway; private final InventoryService inventoryService; // 通过构造函数注入依赖，便于测试时mock public OrderService(PaymentGateway paymentGateway, InventoryService inventoryService) { this.paymentGateway = paymentGateway; this.inventoryService = inventoryService; } public boolean processOrder(Order order) { // 业务逻辑 return true; } }依赖注入设计提升可测试性2.2 质量属性的优先级权衡不同业务场景下，质量属性的优先级需要差异化设置。一刀切的标准往往导致过度设计或质量不足。系统类型关键质量属性次要质量属性权衡考量电商交易一致性、可用性、性能可扩展性、可维护性强一致性可能降低性能大数据平台可扩展性、吞吐量实时性、一致性最终一致性提升吞吐量IoT边缘计算可靠性、安全性可维护性、性能离线能力优先于实时性质量属性权衡框架帮助团队基于业务上下文做出合理决策：# 质量属性权衡决策记录 decision_id: "perf-vs-maintainability" context: "订单查询服务需要优化响应时间" constraints: - "必须在200ms内返回结果" - "团队规模小，维护成本需控制" alternatives: - option: "引入缓存层" pros: ["性能提升明显"] cons: ["缓存一致性复杂化"] - option: "数据库查询优化" pros: ["架构简单"] cons: ["性能提升有限"] decision: "采用缓存层，但增加缓存失效策略" rationale: "业务要求性能优先，可通过工具降低维护成本"架构决策记录模板3 架构评审体系：多层次、全流程的质量保障3.1 分层评审机制有效的架构评审需要多层次覆盖，针对不同变更范围实施相应粒度的评审。战术级评审针对日常技术决策和代码变更，通过轻量级流程保障基础质量：代码审查：每个PR必须经过至少一名核心成员审查设计讨论：复杂功能在实现前进行团队内设计评审工具辅助：静态分析、代码规范检查自动化战略级评审针对系统级架构变更，通过正式流程保障一致性：架构委员会：跨部门专家组成，评审重大架构决策…

【论文分享】从混乱到清晰：面向安全分析的综合性JavaScript反混淆
type: item
date: 2026-01-25T00:06:56+08:00
description: 一、当恶意代码穿上”隐身衣”：JavaScript混淆的现实威胁打开一个可疑的JavaScript文件，你可能会看到这样的代码：这不是乱码，而是攻击者精心设计的”隐身衣”——JavaScript代码混淆。这段看似天书般的代码，实际上可能隐藏着窃取用户数据、植入后门或发起网络攻击的恶意逻辑。JavaScript作为互联网前端和客户端脚本的核心语言，在网页及各类网络应用中被广泛使用，这也使其成为了攻击者的首选目标。攻击者频繁利用JavaScript的动态特性，通过多层、多样化的混淆技术隐藏恶意代码，极大增加了安全分析的难度。面对这一日益严峻的安全威胁，奇安信技术研究院星图实验室与北京邮电大学联合研究团队在NDSS 2026会议上发表了论文《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》。该论文由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。通过系统性文献调研和样本分析，研究团队将JavaScript混淆技术归纳为四大类共20种技术：词法级混淆（变量重命名、间接属性访问等5种）、语法级混淆（表达式转函数、特殊编码等6种）、语义级混淆（字符串数组、控制流平坦化等7种）和多层混淆（OB混淆、AI辅助混淆2种）。针对这些复杂化的混淆趋势，研究开发的综合性反混淆工具JSIMPLIFIER能够自动破解各种混淆技术，将晦涩的恶意代码还原为安全分析师能够快速理解的清晰形式。二、现有反混淆工具的三重困境当前的JavaScript反混淆工具面临着三个核心挑战，这些挑战严重限制了它们在实际安全分析中的应用效果。输入处理的脆弱性： 现有工具在遇到不同语法、混合编码、打包器包装等”不规范”输入时经常直接崩溃。真实世界的恶意代码往往包含这些问题，导致工具连分析机会都没有。分析策略的单一性： 静态分析工具无法处理运行时依赖的混淆（如动态代码生成），动态分析工具又难以应对大规模样本和安全风险。更关键的是，现有工具通常只针对特定混淆模式，缺乏对多层混淆的综合支持。以JSFireTruck恶意软件为例，这个一个月内感染26.9万网页的攻击使用了复杂的多层混淆，现有工具要么无法处理，要么只能部分解码。输出可读性的缺失： 即使成功反混淆，输出代码仍充斥着_0x4f2a、_0x1b3c等这样的无意义标识符，安全分析师需要花费大量时间才能理解代码逻辑，严重影响威胁响应效率。三、JSIMPLIFIER的创新设计针对以上挑战，我们提出了JSIMPLIFIER，一款集代码预处理、静态抽象语法树分析、动态执行跟踪和大语言模型（LLM）智能变量重命名与代码美化于一体的综合性反混淆工具。JSIMPLIFIER采用三阶段流水线架构，每个阶段专门解决一类核心问题，形成了从”输入修复”到”逻辑还原”再到”可读性提升”的完整处理链条。预处理器：让”坏代码”变”好代码”（Preprocessor）预处理器是整个系统的基石，负责将各种”问题代码”标准化为可分析的格式。它首先进行代码有效性检查，使用容错性强的Meriyah解析器，即使面对不同灵活语法或不完整的代码也能生成完整的抽象语法树（AST）。接着进行词法清理，系统性地处理字符编码冲突，比如将过时的八进制转义序列（如\302）转换为标准的十六进制格式（如\xC2），并重建被分割的多字节UTF-8字符。在语义兼容化阶段，系统将遗留的JavaScript构造替换为跨平台等价物，确保在现代JavaScript环境中的兼容性。最后通过结构优化，利用AST作用域链遍历解决声明冲突，将代码重构为严格模式兼容的形式。反混淆器：静态与动态的完美协作（Deobfuscator）反混淆器采用混合分析设计，巧妙结合静态AST分析和受控动态执行。增强的静态AST分析 方面，JSIMPLIFIER配备强化表达式求值引擎，专门处理混淆代码中的复杂构造：对于LogicalExpressions，实现正确的短路求值处理嵌套的&&和||链（如False && anything直接返回False）；对于ES6解构赋值如[a, b, c] = [getValue(), obj.prop, func.call(this)]，JSIMPLIFIER扩展AssignmentExpression处理，解析左侧模式结构并递归遍历嵌套数组模…

SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具
type: item
date: 2026-01-21T12:05:28+08:00
description: SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具SonarQube Server 2025 Release 6 (macOS, Linux, Windows) - 代码质量、安全与静态分析工具Self-managed static analysis tool for continuous codebase inspection请访问原文链接：https://sysin.org/blog/sonarqube/ 查看最新版。原创作品，转载请保留出处。作者主页：sysin.orgSonarQube Server代码质量和安全性由您掌控之前称为 SonarQube，本地部署的用于持续代码库检查的静态分析工具保持 AI 生成的代码干净释放 AI 编码助手的强大功能，而无需承担不良、不安全代码的风险。SonarQube Server 是您的干净代码解决方案，可以部署在任何地方、本地或云环境中。受到 700 万开发者和 400,000 多个组织的使用和喜爱提高代码质量的代码质量工具您的代码是一项商业资产。通过 SonarQube Server 达到干净代码状态，实现代码的最高价值。SonarQube Server 功能：代码智能利用 SonarQube 的深度洞察，更全面地了解您的代码库。通过减少认知负荷来提高开发人员的生产力。与顶级 DevOps 平台集成轻松加入项目。与 GitHub Actions、GitLab CI/CD、Azure Pipelines、Bitbucket Pipelines 和 Jenkins 集成，以自动触发分析并显示您工作地点的代码运行状况。代码审查通过 SonarQube 的质量阈值，防止不符合策略的代码进入生产环境。消除人工编写和 AI 生成代码中的问题，从而降低后期修复成本。高性能和可操作性按照您的方式进行部署，无论是在本地、在云中、作为服务器、使用 Docker 或 Kubernetes。多线程、多个计算引擎和特定于语言的加载可提供最佳性能。顶级分析速度和准确性在几分钟而不是几小时内收到可操作的清洁代码指标 (sysin)。Clean as You Code 会在您工作时检查较小的代码片段，为您提供有关新代码质量的准确反馈。重要语言的关键安全规则在您的开发工作流程中，在正确的时间和正确的位置无缝地发现编码问题。受益于 6,000 多个规则以及行业领先的 Java、C#、PHP、Python 等污点分析。共享、统一的配置设置特定的编码标准，使您的团队在代码健康方面保持一致并实现您的代码质量目标。另外，“边编程边学习” 可将开发人员的技能提升到同样高的水平。用于 IDE 的 SonarQube添加 SonarQube for IDE 扩展并将其连接到 SonarQube 服务器，以便在编码时动态查找编码问题，并确保您的团队遵循单一受监管的编码标准。测量代码覆盖率查看测试执行的代码库的百分比，以获得有关代码运行状况的宝贵见解。引导您到覆盖率低的领域进行改进。Sonar 的人工智能AI 辅助编码，由 SONAR 改进新的 AI 代码保证Sonar AI 代码保证是一个强大且简化的流程，用于通过结构化和全面的分析来验证 AI 生成的代码。这确保了每一段新代码在投入生产之前都符合最高的质量和安全标准。AI CodeFix 简介Sonar AI CodeFix 是一项强大的功能 (sysin)，可为代码分析解决方案 SonarQube Server 和 SonarQube Cloud 发现的问题提供代码修复建议。只需单击一下，您就可以获得有关如何解决一系列问题的建议，从而简化问题解决流程。笔者提示：此类功能通常需要有效服务合同。安全漏洞检测增强的开发人员安全工具 | 安全与机密信息检测静态代码分析Sonar 的静态应用程序安全测试 (SAST) 引擎可检测代码中的安全漏洞，以便在构建和测试应用程序之前消除这些漏洞。使用 SAST 为复杂项目实现强大的应用程序安全性和合规性。机密信息检测SonarQube Server 包含一个强大的机密信息检测工具，这是用于检测和删除代码中机密信息的最全面的解决方案之一。与 SonarQube for IDE 一起使用，它可以防止机密信息泄露并成为严重的安全漏洞。安全标准合规性SonarQube Server 可帮助您遵守通用代码安全标准，例如 NIST SSDF。将 SonarQube Server 与 SonarQube for IDE 结合使用，可以自动检查项目代码是否存在安全漏洞，并提高整体代码质量。基于开源，满足所有需求的版本SonarQube Server 版本：Community Build免费开源，可提高开发效率和代码…

【论文分享】从噪声到信号：如何在千万级软件包中精准定位漏洞影响？
type: item
date: 2026-01-19T22:36:17+08:00
description: 一、引言：软件供应链安全的”狼来了”困境想象这样一个场景：你是一名开发者，每天打开 CI/CD 系统，迎接你的是数百条安全警报——”检测到依赖包存在高危漏洞，请立即修复！” 但当你花费大量时间逐一排查后却发现，绝大多数警报都是虚惊一场：那些所谓的”漏洞代码” 根本就没有被你的应用调用。这种”警报疲劳”已成为软件供应链安全领域的痛点，也是众多安全检测工具难以实际落地应用的重要原因。这正是奇安信技术研究院和清华大学研究团队在 NDSS 2026 会议上发表的论文所要解决的核心问题。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室），应凌云博士（奇安信星图实验室）和谷雅聪博士（清华大学）。这项研究针对全球最大的开源软件生态系统——npm（拥有超过 300 万个包，2024 年处理了约 4.5 万亿次请求），提出了一套基于函数调用关系的细粒度漏洞传播关系识别方法和分析框架。论文分析结果表明，传统工具所产生的漏洞警告中，高达 68.28% 都是”噪声”，即漏洞代码实际上根本无法被触达。二、问题的本质：为什么传统方法会产生如此高的误报？npm生态系统的复杂性源于其极度碎片化的包依赖结构。已有研究显示，约四分之一的npm包版本依赖于存在已知漏洞的包。以 pac-resolver为例，这个每周下载量达 300 万次的 npm 包曾曝出高危远程代码执行漏洞，导致 GitHub 上超过 28.5 万个公共仓库可能面临风险。但问题的关键在于：依赖存在漏洞的包，不等于你的应用真的受到影响。当前主流的软件成分分析（SCA）工具，如npm audit、GitHub Dependabot等，都采用包级别的分析方法。它们的逻辑很简单：如果你的依赖树中存在包A的v1.0版本，并且包A的v1.0版本存在漏洞，则发出警报提醒你的应用受到影响。 但这种粗粒度分析忽略了三个关键问题：未使用的依赖：你的 package.json 声明了依赖，但代码中从未引入（require/import）该包的任何模块；浅层的 API 使用：即使引入了包，可能只使用了其中若干个函数，而漏洞函数根本未被调用；传递性衰减：通过多层依赖传递时，每一跳的使用范围都在缩小。理论上，函数级可达性分析是最佳解决方案——只有当存在从应用入口到漏洞函数的调用路径时，才认为应用真正可能受到影响。但在 npm 生态实施函数级分析面临三大技术挑战：首先是可扩展性挑战：传统方法需要为每个项目构建完整的调用图（Call Graph），也包含其所有依赖，对于复杂项目，依赖数量可达数百甚至上千个包。每次分析都要从头开始，计算成本呈指数级增长。其次是 JavaScript 的动态特性带来的程序分析挑战。极其灵活的语法特性为静态分析制造了诸多盲区：代码中广泛存在的动态属性访问（利用变量而非字面量调用函数）、将函数作为参数传递的高阶函数机制（回调），以及允许在运行时动态修改对象原型链的特性，都让静态分析器难以在运行前确定具体的调用目标和完整的控制流，从而极易导致依赖分析链路的断裂或缺失。具体代码示例如下：// 动态属性访问 obj[propName](); // propName是变量，静态分析难以确定调用目标 // 高阶函数 function process(callback) { callback(); // 不知道传入的是哪个函数 } // 原型链动态修改 ，增加了分析的不确定性 Object.prototype.newMethod = function() { ... }; 最后，JavaScript 语言模块系统的复杂性进一步加剧了分析难度：CommonJS (require)和 ESM (import/export) 不同的模块机制、module.exports对象可在运行时修改，以及require()的参数可以是动态表达式 ，这些都进一步加剧了分析难度。三、VulTracer的核心设计和解决方案面对这些挑战，我们设计并实现了 VulTracer 这个分析框架。它的核心洞察在于：npm包一旦发布就不可变，因此可以为每个包预计算可复用的分析结果。这开启了”分析一次，复用多次”的新范式。VulTracer 将传统的整体式分析分解为三个独立阶段，核心设计和架构如上图所示。以下将详细介绍每一个部分的设计逻辑和细节。3.1 富语义图生成 (RSG Generation)首先，VulTracer 利用程序静态分析技术，为每一个包构建了一个富语义图（Rich Semantic Graph, RSG）。这张图不仅看清了包内部的函数调…

【论文分享】从混乱到清晰：面向安全分析的综合性JavaScript反混淆
type: item
date: 2026-01-19T22:31:26+08:00
description: 一、当恶意代码穿上”隐身衣”：JavaScript混淆的现实威胁打开一个可疑的JavaScript文件，你可能会看到这样的代码：这不是乱码，而是攻击者精心设计的”隐身衣”——JavaScript代码混淆。这段看似天书般的代码，实际上可能隐藏着窃取用户数据、植入后门或发起网络攻击的恶意逻辑。JavaScript作为互联网前端和客户端脚本的核心语言，在网页及各类网络应用中被广泛使用，这也使其成为了攻击者的首选目标。攻击者频繁利用JavaScript的动态特性，通过多层、多样化的混淆技术隐藏恶意代码，极大增加了安全分析的难度。面对这一日益严峻的安全威胁，奇安信技术研究院星图实验室与北京邮电大学联合研究团队在NDSS 2026会议上发表了论文《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》。该论文由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。通过系统性文献调研和样本分析，研究团队将JavaScript混淆技术归纳为四大类共20种技术：词法级混淆（变量重命名、间接属性访问等5种）、语法级混淆（表达式转函数、特殊编码等6种）、语义级混淆（字符串数组、控制流平坦化等7种）和多层混淆（OB混淆、AI辅助混淆2种）。针对这些复杂化的混淆趋势，研究开发的综合性反混淆工具JSIMPLIFIER能够自动破解各种混淆技术，将晦涩的恶意代码还原为安全分析师能够快速理解的清晰形式。二、现有反混淆工具的三重困境当前的JavaScript反混淆工具面临着三个核心挑战，这些挑战严重限制了它们在实际安全分析中的应用效果。输入处理的脆弱性： 现有工具在遇到不同语法、混合编码、打包器包装等”不规范”输入时经常直接崩溃。真实世界的恶意代码往往包含这些问题，导致工具连分析机会都没有。分析策略的单一性： 静态分析工具无法处理运行时依赖的混淆（如动态代码生成），动态分析工具又难以应对大规模样本和安全风险。更关键的是，现有工具通常只针对特定混淆模式，缺乏对多层混淆的综合支持。以JSFireTruck恶意软件为例，这个一个月内感染26.9万网页的攻击使用了复杂的多层混淆，现有工具要么无法处理，要么只能部分解码。输出可读性的缺失： 即使成功反混淆，输出代码仍充斥着_0x4f2a、_0x1b3c等这样的无意义标识符，安全分析师需要花费大量时间才能理解代码逻辑，严重影响威胁响应效率。三、JSIMPLIFIER的创新设计针对以上挑战，我们提出了JSIMPLIFIER，一款集代码预处理、静态抽象语法树分析、动态执行跟踪和大语言模型（LLM）智能变量重命名与代码美化于一体的综合性反混淆工具。JSIMPLIFIER采用三阶段流水线架构，每个阶段专门解决一类核心问题，形成了从”输入修复”到”逻辑还原”再到”可读性提升”的完整处理链条。预处理器：让”坏代码”变”好代码”（Preprocessor）预处理器是整个系统的基石，负责将各种”问题代码”标准化为可分析的格式。它首先进行代码有效性检查，使用容错性强的Meriyah解析器，即使面对不同灵活语法或不完整的代码也能生成完整的抽象语法树（AST）。接着进行词法清理，系统性地处理字符编码冲突，比如将过时的八进制转义序列（如\302）转换为标准的十六进制格式（如\xC2），并重建被分割的多字节UTF-8字符。在语义兼容化阶段，系统将遗留的JavaScript构造替换为跨平台等价物，确保在现代JavaScript环境中的兼容性。最后通过结构优化，利用AST作用域链遍历解决声明冲突，将代码重构为严格模式兼容的形式。反混淆器：静态与动态的完美协作（Deobfuscator）反混淆器采用混合分析设计，巧妙结合静态AST分析和受控动态执行。增强的静态AST分析 方面，JSIMPLIFIER配备强化表达式求值引擎，专门处理混淆代码中的复杂构造：对于LogicalExpressions，实现正确的短路求值处理嵌套的&&和||链（如False && anything直接返回False）；对于ES6解构赋值如[a, b, c] = [getValue(), obj.prop, func.call(this)]，JSIMPLIFIER扩展AssignmentExpression处理，解析左侧模式结构并递归遍历嵌套数组模…

重塑传统自动化漏洞挖掘的Multi-Agent框架攻防一体化实践
type: item
date: 2026-01-19T18:23:51+08:00
description: 重塑传统自动化漏洞挖掘的Multi-Agent框架攻防一体化实践前段时间在某大厂做安全研究时，针对SDLC的重复性审计工作结合大模型Agent思索了一些可行的思路，便在不断摸索中构建了一个Multi-Agent的协同漏洞挖掘框架系统，目前个人使用来看对于开源的web应用的实战效果相比传统的SAST、DAST以及纯LLM的漏洞挖掘工具来说还是很不错的，便记录此篇框架实现过程和当今Agent赋能漏挖的可行性与优势供师傅们交流指点....0x00 传统漏洞挖掘的困局当前针对Web应用后端的自动化漏洞挖掘技术主要受困于“覆盖率”与“准确性”难以两全的矛盾： 传统的静态分析技术虽能提供全量的代码覆盖，但由于缺乏对程序运行时状态和复杂业务逻辑的语义理解，往往导致海量的误报噪声，极大地增加了安全工程师的审计成本 而动态应用程序安全测试虽能在黑盒方面挖掘漏洞更具真实性，却受限于黑盒视角的路径探索能力，难以触及深层业务逻辑，会存在很多漏报 目前大语言模型的出现为代码语义分析带来了新的契机，但受限于Context Window 的约束以及生成式模型固有的幻觉问题，直接依赖原生LLM进行大规模代码审计往往导致分析结果碎片化且缺乏可信度，并且直接将代码喂给大模型容易受与漏洞无关代码的影响 0x01 探索漏洞挖掘框架的新出路？在探索新的框架实现时，我们可以思考是否能将黑白盒的现有技术互补结合来引导漏洞挖掘？以及我们可以看到几年LLM与Agent相关技术如MCP、RAG的工程化落地，能否用LLM赋于框架更好的语义理解和丰富的上下文能力，再通过Agent做一套自动化流程？为突破上述技术瓶颈，我在探索新的漏洞挖掘框架时也看了一些目前学术界的相关LLM赋能的研究与github开源的技术实现，总体的探索方法还是在论文与现实实践中思考各个方面的优势与缺陷，最终确定做一个基于Muti-Agent协同的智能化漏洞挖掘框架：构建一个从静态分析到动态验证的闭环生态。技术上引入MCP 来作为连接LLM推理能力与静态分析工具的桥梁，利用RAG 技术通过构建高质量漏洞专家知识库来校准模型判定，深度缓解LLM的“幻觉”与知识盲区；同时，结合运行时自动化的流量Fuzz模糊测试技术，将白盒的逻辑推演与黑盒的攻击验证深度融合，减少漏洞的误报和漏报。这里放一个当时挖到的有CNVD证书的水洞，通过项目上传与聊天，自动化分析审计出多处SQL注入漏洞，并且能够给出攻击POC，以及后续完整的修复方案0x02 框架核心：打破黑白盒壁垒该框架核心架构旨在重构传统安全检测的边界，提出了一种 “白盒语义指引黑盒，黑盒动态验证白盒”的深度融合范式。框架并非单一工具的线性叠加，而是一个基于Multi-Agent编排（Agent Orchestration）的异构系统。 白盒分析维度：框架引入了MCP作为智能体的执行接口，驱动底层的静态分析工具与正则匹配引擎，对代码AST进行初步扫描，快速锚定潜在的危险函数调用Sink。为解决静态分析中常见的上下文缺失问题，进一步融合了RAG 技术：通过引入高质量的博客记录的高精度漏洞知识库，系统能够为大语言模型提供特定漏洞类型的完备的Context上下文与判定依据，从而在保持高代码覆盖率的同时，抑制传统模式匹配带来的误报，实现了从“语法”到“语义”的代码的全面理解提升。 黑盒验证维度：框架构建了运行时的自动化Fuzz模糊测试。该模块独立承担着对Web通用漏洞（如XSS、SQL注入）及敏感信息泄露的覆盖任务。当白盒Agent发现疑似逻辑漏洞时，通过黑盒上的Fuzz可在流量侧生成针对性的变异Payload进行动态优化，通过分析HTTP响应状态来实证漏洞的可利用性。 我认为将静态视角的逻辑推演与动态视角的攻击验证相结合的机制，能极大地提升了漏洞检测的置信度，实现了真正意义上的全链路攻防评估，刚开始时候画的大致架构草图，仅贴示了主要功能，一些细节实现并未展示：0x03 智能化Agent设计细节1. Static Orchestration Agent：基于MCP协议的异构工具编排在传统的LLM应用中，模型往往被禁锢在文本交互的孤岛中，难以触及本地庞大的代码仓库，且面临着Context Window对海量代码理解的限制。本框架设计的漏洞定位Agent，本质上是一个 静态分析增强型智能体(Static Orchestration Agen) ，通过引入MCP与构建Prompt定义角色任务将LLM从被动的文本生成者转变为主动的工具使用者，通过静态分析获取代码结构中的丰富语义上下文MCP驱动的“深层感知”不同于简单的API调用，MCP协议使得Agent能够理解工具的输入输出Schema，实现复杂的推理链条： 工具与模型的语义对齐：通过定义标准化的MCP接口，将底层的静态代码分析工具封装为L…

微服务应用漏洞自动化挖掘MScan的实现与实战（下）
type: item
date: 2026-01-19T12:07:09+08:00
description: Intro Tai-e作为一个优秀的静态分析框架，内置了指针分析、污点分析等等实现。为增强其作为一个底座框架的可扩展性，其提供了插件系统，通过插件系统可以控制在静态分析过程中的各个阶段的数据处理，更进一步的进行定制化分析的实现。如下图为Tai-e官方提供的有关于插件系统的原理图： 本文中提及的有关于微服务应用的静态分析框架MScan同样是基于Tai-e进行实现的，针对微服务应用中使用的一些特殊的API进行服务间的高速通信过程，传统的静态分析方式不能够原生支持该类服务间通信的污点流的传播，但是这里采用了上面介绍了插件系统的方式，为服务间的通信过程进行建模，定制化的支持该过程的数据流分析，例如是Grpc、Dubbo或者Feign等通信方式。 具体的分析因篇幅太长分为了上下两篇，上篇主要集中于理论层面的代码分析，剖析基于Tai-e框架的改造细节，明晰从source点提取到扩展的污点分析引擎工作原理的全流程。而下篇主要集中于实战层面的内容，在剖析微服务应用各服务间的通信建模方式，也即如何构建一个SDG（Service Dependence Graph），同时贴近实战批量拉取github\gitee高star项目进行自动化 clone-complie-scan全流程。 DistancePruning 该类的实现对应着论文中提及到的基于距离引导的上下文选择策略，但是感觉具体对其的实现还是和论文中的描述存在出入，后面具体分析其实现 在options.yml中若对advance进行配置，将会使用特定的上下文选择器，这里的动态上下文选择策略的实现和核心逻辑在DistancePruning#run，核心是三个原则 1 对于一个方法，其能够调用到某一个sink点方法且能够被某一个source点方法调用到（不局限于单次调用，只要在调用图上能找到一个调用链即可），对于这样的方法，将其csMap的值设为MAX，也即是这样的方法采用最大的上下文进行分析 2 对于仅仅能够形成调用链到sink点方法，但不能够某个source点方法调用的方法，这样的方法，将其csMap的值设为固定的2，在分析时采用2-call的方法进行上下文的选择 3 而对于上述两种情况都不满足的情况，则直接将其上下文选择为MIN，采用最小的上下文 总的来说，虽然与论文中提出的基于一个方法到达最近的source-sink链的距离进行上下文的选择有所出路，但是这里的上下文选择方法也是基于一个context-insensitivity的分析结果，所以对于可能的source-to-sink调用链长度进行最大上下文的选择也一种有效的避免假阳性的方法 与此同时，注意到在Pruning类也存在有两种上下文选择的思路 1 csMapByTaintNum方法，基于一种成本控制的思路进行上下文的选择，首先通过流式处理，从指针分析结果（pta）的调用图中获取所有可到达的方法（reachableMethods），对于每个方法，计算其参数中属于“污点”（Taint）的数量。然后过滤掉污点参数数为0的方法，并将剩余方法按污点参数数从高到低排序。确保了那些更可能涉及敏感数据流的方法会被优先考虑 总的来说，上下文的大小是由一个动态的分析成本预算控制的。它优先处理污点参数多的方法，但同时严格限制方法的分析成本总和不超过上限（硬件条件）。这种设计巧妙地在分析广度（覆盖更多方法）和深度（分析复杂方法）之间取得了平衡，防止资源消耗无限增长 ○ 对于每个方法，只有当累计成本 count小于阈值（1e5）时，才会将其加入 csMap并标记为 "5"，同时计数器 count5增1 ○ 如果方法非抽象，则计算其分析成本：变量数 * (调用者数量)^4，并将此成本累加到 count上 ○ 一旦 count的值达到或超过 1e5，循环便会停止，后续方法不再被加入 csMap 2 csMapByTaintFlow方法，这个方法猜测是想基于通过上下文不敏感的静态分析结果得到的TaintFlow进行上下文的动态选择，但是感觉后面可能烂尾了，没有实现完 SDG (Service Dependence Graph) OpenFeignPlugin 该插件核心是用来建立通过Feign方式进行跨服务调用的调用边，用于构建SDG (Service Dependence Graph) 对于该插件同样是实现了标准的Plugin接口，其实现了onStart方法以及onNewCSMethod方法用于在程序分析前进行处理以及在遭遇新的方法时进行处理 对于onstart主要是在静态分析前对FeignClient进行处理，获取所有的feign类型的路由以及实现类，保存在mappingEdges中 而对于onNewCSMethod实现了一个访问者模式，遍历遇到的所有新方法的…

重塑传统自动化漏洞挖掘的Multi-Agent框架攻防一体化实践
type: item
date: 2026-01-19T10:06:49+08:00
description: 重塑传统自动化漏洞挖掘的Multi-Agent框架攻防一体化实践前段时间在某大厂做安全研究时，针对SDLC的重复性审计工作结合大模型Agent思索了一些可行的思路，便在不断摸索中构建了一个Multi-Agent的协同漏洞挖掘框架系统，目前个人使用来看对于开源的web应用的实战效果相比传统的SAST、DAST以及纯LLM的漏洞挖掘工具来说还是很不错的，便记录此篇框架实现过程和当今Agent赋能漏挖的可行性与优势供师傅们交流指点....0x00 传统漏洞挖掘的困局当前针对Web应用后端的自动化漏洞挖掘技术主要受困于“覆盖率”与“准确性”难以两全的矛盾： 传统的静态分析技术虽能提供全量的代码覆盖，但由于缺乏对程序运行时状态和复杂业务逻辑的语义理解，往往导致海量的误报噪声，极大地增加了安全工程师的审计成本 而动态应用程序安全测试虽能在黑盒方面挖掘漏洞更具真实性，却受限于黑盒视角的路径探索能力，难以触及深层业务逻辑，会存在很多漏报 目前大语言模型的出现为代码语义分析带来了新的契机，但受限于Context Window 的约束以及生成式模型固有的幻觉问题，直接依赖原生LLM进行大规模代码审计往往导致分析结果碎片化且缺乏可信度，并且直接将代码喂给大模型容易受与漏洞无关代码的影响 0x01 探索漏洞挖掘框架的新出路？在探索新的框架实现时，我们可以思考是否能将黑白盒的现有技术互补结合来引导漏洞挖掘？以及我们可以看到几年LLM与Agent相关技术如MCP、RAG的工程化落地，能否用LLM赋于框架更好的语义理解和丰富的上下文能力，再通过Agent做一套自动化流程？为突破上述技术瓶颈，我在探索新的漏洞挖掘框架时也看了一些目前学术界的相关LLM赋能的研究与github开源的技术实现，总体的探索方法还是在论文与现实实践中思考各个方面的优势与缺陷，最终确定做一个基于Muti-Agent协同的智能化漏洞挖掘框架：构建一个从静态分析到动态验证的闭环生态。技术上引入MCP 来作为连接LLM推理能力与静态分析工具的桥梁，利用RAG 技术通过构建高质量漏洞专家知识库来校准模型判定，深度缓解LLM的“幻觉”与知识盲区；同时，结合运行时自动化的流量Fuzz模糊测试技术，将白盒的逻辑推演与黑盒的攻击验证深度融合，减少漏洞的误报和漏报。这里放一个当时挖到的有CNVD证书的水洞，通过项目上传与聊天，自动化分析审计出多处SQL注入漏洞，并且能够给出攻击POC，以及后续完整的修复方案0x02 框架核心：打破黑白盒壁垒该框架核心架构旨在重构传统安全检测的边界，提出了一种 “白盒语义指引黑盒，黑盒动态验证白盒”的深度融合范式。框架并非单一工具的线性叠加，而是一个基于Multi-Agent编排（Agent Orchestration）的异构系统。 白盒分析维度：框架引入了MCP作为智能体的执行接口，驱动底层的静态分析工具与正则匹配引擎，对代码AST进行初步扫描，快速锚定潜在的危险函数调用Sink。为解决静态分析中常见的上下文缺失问题，进一步融合了RAG 技术：通过引入高质量的博客记录的高精度漏洞知识库，系统能够为大语言模型提供特定漏洞类型的完备的Context上下文与判定依据，从而在保持高代码覆盖率的同时，抑制传统模式匹配带来的误报，实现了从“语法”到“语义”的代码的全面理解提升。 黑盒验证维度：框架构建了运行时的自动化Fuzz模糊测试。该模块独立承担着对Web通用漏洞（如XSS、SQL注入）及敏感信息泄露的覆盖任务。当白盒Agent发现疑似逻辑漏洞时，通过黑盒上的Fuzz可在流量侧生成针对性的变异Payload进行动态优化，通过分析HTTP响应状态来实证漏洞的可利用性。 我认为将静态视角的逻辑推演与动态视角的攻击验证相结合的机制，能极大地提升了漏洞检测的置信度，实现了真正意义上的全链路攻防评估，刚开始时候画的大致架构草图，仅贴示了主要功能，一些细节实现并未展示：0x03 智能化Agent设计细节1. Static Orchestration Agent：基于MCP协议的异构工具编排在传统的LLM应用中，模型往往被禁锢在文本交互的孤岛中，难以触及本地庞大的代码仓库，且面临着Context Window对海量代码理解的限制。本框架设计的漏洞定位Agent，本质上是一个 静态分析增强型智能体(Static Orchestration Agen) ，通过引入MCP与构建Prompt定义角色任务将LLM从被动的文本生成者转变为主动的工具使用者，通过静态分析获取代码结构中的丰富语义上下文MCP驱动的“深层感知”不同于简单的API调用，MCP协议使得Agent能够理解工具的输入输出Schema，实现复杂的推理链条： 工具与模型的语义对齐：通过定义标准化的MCP接口，将底层的静态代码分析工具封装为L…

【论文分享】从噪声到信号：如何在千万级软件包中精准定位漏洞影响？
type: item
date: 2026-01-18T02:04:30+08:00
description: 一、引言：软件供应链安全的”狼来了”困境想象这样一个场景：你是一名开发者，每天打开 CI/CD 系统，迎接你的是数百条安全警报——”检测到依赖包存在高危漏洞，请立即修复！” 但当你花费大量时间逐一排查后却发现，绝大多数警报都是虚惊一场：那些所谓的”漏洞代码” 根本就没有被你的应用调用。这种”警报疲劳”已成为软件供应链安全领域的痛点，也是众多安全检测工具难以实际落地应用的重要原因。这正是奇安信技术研究院和清华大学研究团队在 NDSS 2026 会议上发表的论文所要解决的核心问题。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室），应凌云博士（奇安信星图实验室）和谷雅聪博士（清华大学）。这项研究针对全球最大的开源软件生态系统——npm（拥有超过 300 万个包，2024 年处理了约 4.5 万亿次请求），提出了一套基于函数调用关系的细粒度漏洞传播关系识别方法和分析框架。论文分析结果表明，传统工具所产生的漏洞警告中，高达 68.28% 都是”噪声”，即漏洞代码实际上根本无法被触达。二、问题的本质：为什么传统方法会产生如此高的误报？npm生态系统的复杂性源于其极度碎片化的包依赖结构。已有研究显示，约四分之一的npm包版本依赖于存在已知漏洞的包。以 pac-resolver为例，这个每周下载量达 300 万次的 npm 包曾曝出高危远程代码执行漏洞，导致 GitHub 上超过 28.5 万个公共仓库可能面临风险。但问题的关键在于：依赖存在漏洞的包，不等于你的应用真的受到影响。当前主流的软件成分分析（SCA）工具，如npm audit、GitHub Dependabot等，都采用包级别的分析方法。它们的逻辑很简单：如果你的依赖树中存在包A的v1.0版本，并且包A的v1.0版本存在漏洞，则发出警报提醒你的应用受到影响。 但这种粗粒度分析忽略了三个关键问题：未使用的依赖：你的 package.json 声明了依赖，但代码中从未引入（require/import）该包的任何模块；浅层的 API 使用：即使引入了包，可能只使用了其中若干个函数，而漏洞函数根本未被调用；传递性衰减：通过多层依赖传递时，每一跳的使用范围都在缩小。理论上，函数级可达性分析是最佳解决方案——只有当存在从应用入口到漏洞函数的调用路径时，才认为应用真正可能受到影响。但在 npm 生态实施函数级分析面临三大技术挑战：首先是可扩展性挑战：传统方法需要为每个项目构建完整的调用图（Call Graph），也包含其所有依赖，对于复杂项目，依赖数量可达数百甚至上千个包。每次分析都要从头开始，计算成本呈指数级增长。其次是 JavaScript 的动态特性带来的程序分析挑战。极其灵活的语法特性为静态分析制造了诸多盲区：代码中广泛存在的动态属性访问（利用变量而非字面量调用函数）、将函数作为参数传递的高阶函数机制（回调），以及允许在运行时动态修改对象原型链的特性，都让静态分析器难以在运行前确定具体的调用目标和完整的控制流，从而极易导致依赖分析链路的断裂或缺失。具体代码示例如下：// 动态属性访问 obj[propName](); // propName是变量，静态分析难以确定调用目标 // 高阶函数 function process(callback) { callback(); // 不知道传入的是哪个函数 } // 原型链动态修改 ，增加了分析的不确定性 Object.prototype.newMethod = function() { ... }; 最后，JavaScript 语言模块系统的复杂性进一步加剧了分析难度：CommonJS (require)和 ESM (import/export) 不同的模块机制、module.exports对象可在运行时修改，以及require()的参数可以是动态表达式 ，这些都进一步加剧了分析难度。三、VulTracer的核心设计和解决方案面对这些挑战，我们设计并实现了 VulTracer 这个分析框架。它的核心洞察在于：npm包一旦发布就不可变，因此可以为每个包预计算可复用的分析结果。这开启了”分析一次，复用多次”的新范式。VulTracer 将传统的整体式分析分解为三个独立阶段，核心设计和架构如上图所示。以下将详细介绍每一个部分的设计逻辑和细节。3.1 富语义图生成 (RSG Generation)首先，VulTracer 利用程序静态分析技术，为每一个包构建了一个富语义图（Rich Semantic Graph, RSG）。这张图不仅看清了包内部的函数调…

【论文分享】从混乱到清晰：面向安全分析的综合性JavaScript反混淆
type: item
date: 2026-01-18T02:03:23+08:00
description: 一、当恶意代码穿上”隐身衣”：JavaScript混淆的现实威胁打开一个可疑的JavaScript文件，你可能会看到这样的代码：这不是乱码，而是攻击者精心设计的”隐身衣”——JavaScript代码混淆。这段看似天书般的代码，实际上可能隐藏着窃取用户数据、植入后门或发起网络攻击的恶意逻辑。JavaScript作为互联网前端和客户端脚本的核心语言，在网页及各类网络应用中被广泛使用，这也使其成为了攻击者的首选目标。攻击者频繁利用JavaScript的动态特性，通过多层、多样化的混淆技术隐藏恶意代码，极大增加了安全分析的难度。面对这一日益严峻的安全威胁，奇安信技术研究院星图实验室与北京邮电大学联合研究团队在NDSS 2026会议上发表了论文《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》。该论文由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。通过系统性文献调研和样本分析，研究团队将JavaScript混淆技术归纳为四大类共20种技术：词法级混淆（变量重命名、间接属性访问等5种）、语法级混淆（表达式转函数、特殊编码等6种）、语义级混淆（字符串数组、控制流平坦化等7种）和多层混淆（OB混淆、AI辅助混淆2种）。针对这些复杂化的混淆趋势，研究开发的综合性反混淆工具JSIMPLIFIER能够自动破解各种混淆技术，将晦涩的恶意代码还原为安全分析师能够快速理解的清晰形式。二、现有反混淆工具的三重困境当前的JavaScript反混淆工具面临着三个核心挑战，这些挑战严重限制了它们在实际安全分析中的应用效果。输入处理的脆弱性： 现有工具在遇到不同语法、混合编码、打包器包装等”不规范”输入时经常直接崩溃。真实世界的恶意代码往往包含这些问题，导致工具连分析机会都没有。分析策略的单一性： 静态分析工具无法处理运行时依赖的混淆（如动态代码生成），动态分析工具又难以应对大规模样本和安全风险。更关键的是，现有工具通常只针对特定混淆模式，缺乏对多层混淆的综合支持。以JSFireTruck恶意软件为例，这个一个月内感染26.9万网页的攻击使用了复杂的多层混淆，现有工具要么无法处理，要么只能部分解码。输出可读性的缺失： 即使成功反混淆，输出代码仍充斥着_0x4f2a、_0x1b3c等这样的无意义标识符，安全分析师需要花费大量时间才能理解代码逻辑，严重影响威胁响应效率。三、JSIMPLIFIER的创新设计针对以上挑战，我们提出了JSIMPLIFIER，一款集代码预处理、静态抽象语法树分析、动态执行跟踪和大语言模型（LLM）智能变量重命名与代码美化于一体的综合性反混淆工具。JSIMPLIFIER采用三阶段流水线架构，每个阶段专门解决一类核心问题，形成了从”输入修复”到”逻辑还原”再到”可读性提升”的完整处理链条。预处理器：让”坏代码”变”好代码”（Preprocessor）预处理器是整个系统的基石，负责将各种”问题代码”标准化为可分析的格式。它首先进行代码有效性检查，使用容错性强的Meriyah解析器，即使面对不同灵活语法或不完整的代码也能生成完整的抽象语法树（AST）。接着进行词法清理，系统性地处理字符编码冲突，比如将过时的八进制转义序列（如\302）转换为标准的十六进制格式（如\xC2），并重建被分割的多字节UTF-8字符。在语义兼容化阶段，系统将遗留的JavaScript构造替换为跨平台等价物，确保在现代JavaScript环境中的兼容性。最后通过结构优化，利用AST作用域链遍历解决声明冲突，将代码重构为严格模式兼容的形式。反混淆器：静态与动态的完美协作（Deobfuscator）反混淆器采用混合分析设计，巧妙结合静态AST分析和受控动态执行。增强的静态AST分析 方面，JSIMPLIFIER配备强化表达式求值引擎，专门处理混淆代码中的复杂构造：对于LogicalExpressions，实现正确的短路求值处理嵌套的&&和||链（如False && anything直接返回False）；对于ES6解构赋值如[a, b, c] = [getValue(), obj.prop, func.call(this)]，JSIMPLIFIER扩展AssignmentExpression处理，解析左侧模式结构并递归遍历嵌套数组模…