xiaohack's Blog - SCA
type: channel
link: https://blog.xiaohack.org/tag/sca/
items: 艾体宝方案 | 从AI模型到云生态：构建系统化的企业AI安全管理体系【系列文章（4）】
items: 【论文分享】从噪声到信号：如何在千万级软件包中精准定位漏洞影响？
items: 补齐SDLC最后一块拼图：LLM 在应用安全中的实践探索

艾体宝方案 | 从AI模型到云生态：构建系统化的企业AI安全管理体系【系列文章（4）】
type: item
date: 2026-01-29T15:27:12+08:00
description: 随着人工智能（AI）技术的不断进步和广泛应用，AI已经渗透到金融、医疗、制造、自动驾驶等多个行业。尽管AI带来了巨大的创新和效率提升，但随着其应用范围的扩大，AI的安全性问题也逐渐暴露出来。AI应用安全不仅仅局限于算法模型的本身，更多的是涉及数据隐私、对抗攻击、模型滥用、合规性问题以及垂直行业应用中的特殊风险。因此，企业需要全面识别并应对这些AI应用中的潜在风险，构建健全的AI安全管理体系。一、AI应用安全的核心挑战AI应用的安全风险源自多个层面，既包括算法层面的风险，也涉及数据、系统、法律等多维度的安全隐患。1.1 AI模型算法滥用风险随着AI生成内容的普及，模型算法的滥用已成为迫切需要解决的安全隐患。特别是在生成式AI领域，AI模型可能被用来生成虚假信息、深度伪造内容等，直接影响社会舆论，甚至对企业造成直接经济损失。虚假有害信息的传播：生成的AI内容可能被恶意用于传播虚假信息、误导公众、制造恐慌或进行欺诈活动。例如，某些不法分子利用AI生成的新闻报道或虚假视频，制造社会不稳定因素。多模态深度伪造的风险：深度伪造技术融合了视频、音频、文本等多模态内容，生成高度逼真的虚假信息。这类攻击不仅可能带来经济损失，还会破坏公众的信任基础，影响法律和社会规范的实施。模型透明性不足：AI应用在实际运行中，许多模型尤其是复杂的深度学习模型，往往缺乏足够的透明度，用户无法理解模型的决策过程。这种“黑箱”性质不仅增加了用户的使用风险，也使得当出现错误决策时，问题难以被迅速定位和解决。1.2 AI应用开发安全风险AI应用开发不仅仅是技术问题，还涉及硬件、软件以及协同环境的整合，这就使得AI开发中的安全风险更加复杂和多样化。端侧AI安全风险：在边缘计算环境中，由于端侧设备的硬件限制，AI模型可能需要进行压缩或优化，这样的处理虽然可以提升运行效率，但也可能导致模型的鲁棒性和安全性下降，出现性能下降或“安全税”现象。此外，端侧部署通常要求在设备端实现实时推理，并依赖云边协同架构进行模型更新和任务调度，这也带来了异构硬件兼容性和网络延迟等潜在风险。智能体的安全风险：AI智能体是由AI模型驱动的自主系统，能够执行复杂任务。随着AI智能体与外部环境的不断交互，智能体的安全风险也在增加。攻击者可能通过篡改协议或利用自主决策链路的不可预测性，导致智能体做出错误决策，从而产生安全漏洞。具身智能的安全隐患：具身智能涉及到现实世界中的物理行动，其安全风险不容忽视。传感器设备可能泄露个人信息，具身智能体的物理行为可能被恶意攻击者控制，从而导致人身伤害或财产损失。例如，服务机器人操作不当，或自动驾驶汽车发生事故，都是具身智能安全风险的典型表现。智能物联网（AIoT）安全：智能物联网设备融合了AI算法与物联网的物理特性，部署在受限的边缘环境中，面临着传感器噪声、物理攻击、以及复杂环境干扰等问题。与传统物联网设备相比，AIoT还面临着AI特有的安全威胁，如对抗样本攻击、训练数据投毒和模型窃取等问题。1.3 AI垂直行业应用的安全风险AI技术在垂直行业的应用，虽然带来了行业的革新，但也带来了独特的安全风险。不同的行业面临的AI应用安全问题各具特点。AI在医疗行业的安全风险：AI在医疗领域的应用极大地提高了诊断效率和精确度，但也伴随着巨大的技术与伦理风险。训练数据的偏差、系统漏洞可能导致医疗设备发生错误，甚至误诊。此外，AI系统在处理敏感的患者信息时，若未采取充分的加密与权限管理，可能会导致患者隐私泄露，进而带来法律与伦理上的问题。AI在新闻领域的滥用风险：随着AI生成内容技术的普及，新闻行业面临着虚假新闻传播的风险。某些不法分子可能利用AI模型生成虚假报道、伪造证据，借此操纵舆论或进行诈骗活动。如何确保生成内容的真实性与可信度，成为新闻行业亟待解决的安全挑战。AI在金融行业的安全风险：金融行业的AI应用包括身份验证、交易监控等多个方面，面临着深度伪造技术带来的身份验证问题。攻击者通过深度伪造技术伪造身份信息，可能突破金融机构的身份核查系统，实施盗刷或恶意注册等欺诈行为，造成极大的经济损失。AI在编程领域的安全风险：AI辅助编程不仅提高了开发效率，但也带来了代码安全隐患。AI生成的代码可能存在常见漏洞（如SQL注入、跨站脚本攻击等），同时AI生成的代码缺乏架构设计，可能导致后期维护困难。由于过度依赖AI生成的代码，开发人员可能减少了必要的人工审查，从而放大了潜在的安全风险。二、AI应用安全的解决方案与应对措施针对上述AI应用中的安全风险，企业需要采取多维度的防护措施，构建全方位的AI安全管理体系。2.1 提高模型的鲁棒性和透明性为了应对AI模型的滥用风险，企业应加大对AI模型的鲁棒性和透明度的建设。例如，采用对抗训练增强模型的抗干扰能力，采用可解释性AI（XAI）技术提升模型的透…

【论文分享】从噪声到信号：如何在千万级软件包中精准定位漏洞影响？
type: item
date: 2026-01-25T00:11:23+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）。这张图不仅看清了包内部的函数调…

补齐SDLC最后一块拼图：LLM 在应用安全中的实践探索
type: item
date: 2026-01-24T19:38:17+08:00
description: 导语随着 DevSecOps 的不断推进，应用安全已被广泛纳入SDLC的各个阶段。然而，在代码扫描、依赖分析、漏洞检测等能力逐步成熟的同时，一个长期存在却难以解决的问题始终横亘在安全工程实践中：安全工具“能发现问题”，却难以判断问题是否真实、是否可利用、是否值得优先处理。大量规则驱动的扫描结果不仅带来了高误报率，也持续消耗着研发与安全团队的精力。近年来随着大语言模型（LLM）的快速发展，为这一困境提供了新的可能。不同于传统规则或静态特征匹配，LLM 在语义理解、上下文推理和条件组合分析方面展现出独特优势，使其具备参与安全“判断层”的潜力。将 LLM 引入 SDLC，不再只是生成代码或辅助文档，而是尝试参与到安全结果的理解、验证与决策之中。本文结合实际应用安全建设经验，围绕 LLM 在 SDLC 中的落地实践展开，重点探讨其在硬编码、SCA、漏洞挖掘等场景中的应用方式与工程化思路。SDLC 应用安全流程SDLC名词解释 SAST（静态应用安全测试）通过对源代码或编译产物进行静态分析，在不运行系统的情况下发现潜在的安全缺陷，如 SQL 注入、XSS、不安全函数调用和硬编码敏感信息等，适合在开发阶段提前发现问题。 SCA（软件成分分析）聚焦于项目中使用的第三方开源组件，识别依赖库及其传递依赖中已知的安全漏洞、风险版本和许可证问题，帮助团队降低因外部组件引入的安全风险。 DAST（动态应用安全测试）在系统运行状态下，从攻击者视角对应用进行测试，通过捕获流量包修改参数重放，模拟真实攻击行为验证系统是否存在可被实际利用的漏洞，如注入攻击、未授权访问等 硬编码（Hard Coding），是指在程序中直接把固定的值写死在源码里，而不是通过配置文件、环境变量等方式获取，比如下面这些情况，都属于硬编码：用户名、密码、token或加密密钥等 为什么我们需要SDLC？产品一句话需求 → 开发自己理解 → 按照个人习惯去开发 → 功能上线后出现大量漏洞 → 被外部利用造成损失而SDLC要做的就是把漏洞扼杀于摇篮之中，而不是靠后期凭经验渗透测试发现。但目前传统的SDLC存在大量告警/误报，推送大量工单给研发会导致业务间摩擦度增加，因此理想情况是把真正需要修复的工单交给研发处理硬编码规则下引入AI判断，减少误报问题背景：目前硬编码扫描是根据规则的正则匹配，存在一定的局限性和误报整体流程结合硬编码规则 + AI 判断保留高召回，同时降低误报率硬编码规则先行使用固定规则（正则、逻辑判断）先筛掉明显非风险项，让 AI 只处理模糊/不确定案例AI 判断做辅助只对硬编码规则未覆盖、可疑的候选项输出风险判断，输出结果可附置信度或分类标签置信度 + 白名单控制AI 输出带置信度，低于阈值直接忽略，对常见合法值、默认值设置白名单提示词 promot通过定位文件的位置，结合上下文判断实际风险等级，把AI分析结果输出你是一个资深应用安全专家，精通代码安全、凭证泄露、真实攻击利用分析。 现在给你一个【疑似硬编码凭证】的扫描结果，请你进行【可利用性研判】。 输入信息如下（JSON）： %s 请严格按以下维度进行分析： 1. 该硬编码是否为真实敏感凭证 2. 是否存在被外部攻击者利用的可能 3. 是否依赖运行环境 4. 泄露后的安全影响 5. 修复建议 请以 JSON 格式输出分析结果 模型输入字段释义 字段 释义 match 匹配到的硬编码内容（部分脱敏显示） rule key类型 path 硬编码所在的完整文件路径 branch 分支 code 上下5行代码 增加输出长度，避免截断"extra_body": map[string]interface{}{ "think_mode": true, "max_output_tokens": 1024, 实现效果如果是走正常的流程，secret_value会被 generic-api-key规则名字标记严重程度为medium开启AI分析选项后，通过定位文件的位置，结合上下文交给ai分析，AI判断实际危害程度为低在代码中发现硬编码的敏感信息'DEMO_SECRET'，其值为'secret_value'。根据规则'generic-api-key'，这可能是一个API密钥或其他类型的敏感凭证。该变量位于'E:\SDLC平台\backend\uploads\demo.py_scan\demo.txt'文件中，并且注释表明它看起来像一个Key，但无实际用途。由于这是一个测试环境中的示例代码，风险相对较低。 掩码输出硬编码片段代码中存在：const apiKey = "sk_live_9f83a0b7..."AI分析后会直接原样输出，给出完整的佐证片段，这样是不符合数据安全合规要求的，就会产生 二次扩散风险。正确掩码后的做法，AI 只需知道这是一…

补齐SDLC最后一块拼图：LLM 在应用安全中的实践探索
type: item
date: 2026-01-21T09:02:26+08:00
description: 导语随着 DevSecOps 的不断推进，应用安全已被广泛纳入SDLC的各个阶段。然而，在代码扫描、依赖分析、漏洞检测等能力逐步成熟的同时，一个长期存在却难以解决的问题始终横亘在安全工程实践中：安全工具“能发现问题”，却难以判断问题是否真实、是否可利用、是否值得优先处理。大量规则驱动的扫描结果不仅带来了高误报率，也持续消耗着研发与安全团队的精力。近年来随着大语言模型（LLM）的快速发展，为这一困境提供了新的可能。不同于传统规则或静态特征匹配，LLM 在语义理解、上下文推理和条件组合分析方面展现出独特优势，使其具备参与安全“判断层”的潜力。将 LLM 引入 SDLC，不再只是生成代码或辅助文档，而是尝试参与到安全结果的理解、验证与决策之中。本文结合实际应用安全建设经验，围绕 LLM 在 SDLC 中的落地实践展开，重点探讨其在硬编码、SCA、漏洞挖掘等场景中的应用方式与工程化思路。SDLC 应用安全流程SDLC名词解释 SAST（静态应用安全测试）通过对源代码或编译产物进行静态分析，在不运行系统的情况下发现潜在的安全缺陷，如 SQL 注入、XSS、不安全函数调用和硬编码敏感信息等，适合在开发阶段提前发现问题。 SCA（软件成分分析）聚焦于项目中使用的第三方开源组件，识别依赖库及其传递依赖中已知的安全漏洞、风险版本和许可证问题，帮助团队降低因外部组件引入的安全风险。 DAST（动态应用安全测试）在系统运行状态下，从攻击者视角对应用进行测试，通过捕获流量包修改参数重放，模拟真实攻击行为验证系统是否存在可被实际利用的漏洞，如注入攻击、未授权访问等 硬编码（Hard Coding），是指在程序中直接把固定的值写死在源码里，而不是通过配置文件、环境变量等方式获取，比如下面这些情况，都属于硬编码：用户名、密码、token或加密密钥等 为什么我们需要SDLC？产品一句话需求 → 开发自己理解 → 按照个人习惯去开发 → 功能上线后出现大量漏洞 → 被外部利用造成损失而SDLC要做的就是把漏洞扼杀于摇篮之中，而不是靠后期凭经验渗透测试发现。但目前传统的SDLC存在大量告警/误报，推送大量工单给研发会导致业务间摩擦度增加，因此理想情况是把真正需要修复的工单交给研发处理硬编码规则下引入AI判断，减少误报问题背景：目前硬编码扫描是根据规则的正则匹配，存在一定的局限性和误报整体流程结合硬编码规则 + AI 判断保留高召回，同时降低误报率硬编码规则先行使用固定规则（正则、逻辑判断）先筛掉明显非风险项，让 AI 只处理模糊/不确定案例AI 判断做辅助只对硬编码规则未覆盖、可疑的候选项输出风险判断，输出结果可附置信度或分类标签置信度 + 白名单控制AI 输出带置信度，低于阈值直接忽略，对常见合法值、默认值设置白名单提示词 promot通过定位文件的位置，结合上下文判断实际风险等级，把AI分析结果输出你是一个资深应用安全专家，精通代码安全、凭证泄露、真实攻击利用分析。 现在给你一个【疑似硬编码凭证】的扫描结果，请你进行【可利用性研判】。 输入信息如下（JSON）： %s 请严格按以下维度进行分析： 1. 该硬编码是否为真实敏感凭证 2. 是否存在被外部攻击者利用的可能 3. 是否依赖运行环境 4. 泄露后的安全影响 5. 修复建议 请以 JSON 格式输出分析结果 模型输入字段释义 字段 释义 match 匹配到的硬编码内容（部分脱敏显示） rule key类型 path 硬编码所在的完整文件路径 branch 分支 code 上下5行代码 增加输出长度，避免截断"extra_body": map[string]interface{}{ "think_mode": true, "max_output_tokens": 1024, 实现效果如果是走正常的流程，secret_value会被 generic-api-key规则名字标记严重程度为medium开启AI分析选项后，通过定位文件的位置，结合上下文交给ai分析，AI判断实际危害程度为低在代码中发现硬编码的敏感信息'DEMO_SECRET'，其值为'secret_value'。根据规则'generic-api-key'，这可能是一个API密钥或其他类型的敏感凭证。该变量位于'E:\SDLC平台\backend\uploads\demo.py_scan\demo.txt'文件中，并且注释表明它看起来像一个Key，但无实际用途。由于这是一个测试环境中的示例代码，风险相对较低。 掩码输出硬编码片段代码中存在：const apiKey = "sk_live_9f83a0b7..."AI分析后会直接原样输出，给出完整的佐证片段，这样是不符合数据安全合规要求的，就会产生 二次扩散风险。正确掩码后的做法，AI 只需知道这是一…