本文针对星载（onboard）卫星飞行系统中日益广泛使用的开源软件（OSS）开展了一次实证性安全分析。研究背景在于：现代卫星任务为加速研发，大量采用可复用框架、共享库与社区维护组件，但这些组件被引入到补丁更新代价极高、失效可能直接影响任务运行的航天环境中，从而把常规软件供应链风险带入了高可靠性领域。作者收集了 126 个公开卫星相关代码仓库，构建并执行了一条多工具组合的自动化分析流水线，涵盖四个环节：(1) 生成软件物料清单（SBOM）以识别组件构成；(2) 软件成分分析（SCA）以匹配已知漏洞与依赖风险；(3) 静态应用安全测试（SAST）扫描自研源码；(4) 基础设施即代码（IaC）配置审查与密钥/凭据扫描。为控制噪声，作者又施加了基于规则的清洗、面向星载范围的过滤以及基于指纹的去重，最终得到包含 2,827 条安全发现的数据集。结果表明：安全发现分布广泛但高度不均衡；中等严重度占 49%，中等及以上合计占 72%。作者采用基于 CWE 的分类体系，把全部发现归入八个弱点族，其中内存安全与代码质量类占比最高，其次是输入验证与注入类。从代码归属看，81.4% 的发现位于项目自研代码中，外部依赖代码仍是不可忽视的来源。作者明确强调，这些发现并不证明针对具体任务的真实可利用性，其价值在于对开源星载软件生态中反复出现的安全模式给出实证刻画，量化其普遍程度，并帮助任务方确定最应优先投入安全审查的领域。该工作适合航天软件工程、供应链安全与嵌入式安全方向的读者参考。

该论文提出并量化了「静态通过、动态失败」（Static-Pass Dynamic-Fail, SPDF）现象：代码通过了静态安全扫描，但在真实运行时仍可被利用。作者指出，静态分析因可扩展、可复现、成本低，被广泛当作软件供应链与 AI 生成代码的安全闸门，但它无法直接观察运行时的利用行为；那些依赖对抗性输入、执行上下文或漏洞链式组合才能触发的缺陷，往往能绕过静态检查而在实践中仍具可利用性。然而业界普遍把「静态扫描通过」等同于「行为安全」，这正是论文试图挑战的假设。为验证这一问题，作者构建了一个三阶段智能体流水线：第一阶段用 Bandit 与 Semgrep 组成的复合静态闸门做初筛；第二阶段由 LLM 驱动的 CWE（通用弱点枚举）推理，对静态无告警的样本重新审视，判断是否存在候选弱点；第三阶段在隔离的 Docker 容器中执行自主可利用性验证，以获得运行时证据。实验覆盖 SecurityEval、RedCode 与 CyberNative 三个数据集的 1355 份 Python 样本。在 654 份复合静态闸门零告警的样本中，LLM 阶段在 235 个文件中识别出 394 个候选漏洞；动态验证在 95 个文件中确认或部分确认了可利用性，得到 14.53% 的「包含式流水线比率」——即约每 7 份静态干净样本中就有 1 份被流水线发现候选弱点并获得运行时利用证据。分数据集看，候选「文件—CWE」对中的确认率差异明显：RedCode 为 33.7%，CyberNative 为 28.6%，SecurityEval 仅 5.4%。值得注意的是，包括 CWE-338（弱伪随机数）与 CWE-916（口令哈希计算量不足）在内的若干高频确认类别，Bandit 与 Semgrep 均未告警。作者由此论证：静态分析通过率与运行时安全性并非可互相替代的同一度量，而是软件保障体系中不同层级的指标。

该论文聚焦于静态分析在软件安全中的核心地位与 CodeQL 等工具面临的现实瓶颈：构建高覆盖率查询套件通常需要大量人工投入。尽管大语言模型（LLM）在代码推理方面展现出潜力，但其生成结构化、可执行安全查询的实际能力仍缺乏系统评估。为此，作者开展了一项实证研究，利用美国国家漏洞数据库（NVD）中的漏洞数据，评估 LLM 合成 CodeQL 查询的能力，并探索将 LLM 作为自动 CodeQL 查询生成器的可行性。研究系统评测了多种 LLM 架构在大量真实漏洞场景下的表现，重点衡量其生成的查询对检测覆盖率和精确率的提升程度。结果显示，LLM 生成的查询能够显著增强基线 CodeQL 查询，平均 F1 分数提升达 82%。此外，论文提供了详细的成本效益分析：直接使用 LLM 扫描整个代码仓库在计算和财务上往往不可行，而利用 LLM 合成 CodeQL 查询则是一种可扩展且成本有效的替代方案。该研究的核心贡献在于证明 LLM 可以有效弥合非结构化漏洞报告与形式化静态分析规范之间的鸿沟，为大规模自动化漏洞检测提供了一条可扩展路径。适合静态分析研究者、SAST 工具开发者、DevSecOps 工程师以及漏洞管理团队阅读。

该研究关注自动驾驶（AV）软件的安全弱点发现难题：现代自动驾驶系统依赖数百万行安全关键代码，而通用静态分析工具并不理解哪些代码会实际影响车辆运动控制，因此可能既漏报关键缺陷、又产生大量无意义告警。作者提出的核心问题是：如果把明确的自动驾驶安全知识注入大语言模型（LLM），能否比基于规则的传统工具取得更好的弱点检出效果。为回答该问题，他们首先从公开漏洞记录、安全公告以及 AV 安全文献中归纳出一套面向自动驾驶的漏洞分类法，共包含 18 个弱点类别，并将其集成到名为 LLMSec-AV 的 LLM 安全分析框架中。评估对象是开源自动驾驶栈 Autoware：框架把它分解为 770 个翻译单元、4,673 个函数，并在四种提示条件下分析其中 161 个函数，这些条件分别涉及分类法上下文注入、从 374 条历史披露记录中做检索增强，以及多步分析流程。评估基准是作者从上游修复提交中挖掘出的 46 个真实弱点位置，并额外构建了与控制告警数量匹配的置换基线以消除数量偏差。对照组使用 CodeQL、Semgrep、cppcheck 和 Clang Static Analyzer 扫描同一份代码，其中 CodeQL 与 Semgrep 还加入了 AV 专用规则；同时对 LLM 生成的模糊测试驱动用 AFL++ 和 sanitizer 进行了实测。结果显示出明显的对比：LLM 各条件最高可命中 46 个已知弱点位置中的 76%，显著优于传统分析器；CodeQL、Semgrep 和 Clang Static Analyzer 一个都没匹配上，cppcheck 虽然产生 1,301 条告警却只匹配到 1 个。值得注意的是，不使用分类法上下文的“无辅助提示”检测性能与使用了分类法的条件相近，说明分类法本身并未提升召回率；真正的增益体现在可解释性上——加入分类法上下文后，被归入具体弱点类别的发现占比从近乎为零提升到 80% 以上，显著改善了人工分诊效率。此外，18 个弱点类别中有 6 类无法被直接表达为静态分析规则。总体而言，该工作提出了面向自动驾驶的、机器可读的漏洞分类法，并证明 LLM 可以作为传统分析器的补充手段，在真实 AV 软件中识别并组织与安全相关的发现。

本文是一篇关于静态应用安全测试（SAST）工具采用障碍的文献综述。研究背景是现代软件漏洞频繁导致安全事件，对企业和个人造成严重影响，而SAST工具本可通过识别和修复代码漏洞来加固应用安全，但许多开发团队并未在其开发环境中采用此类工具。作者通过系统梳理近期相关文献，旨在揭示开发者对SAST工具持保留态度的原因，并识别他们在实际使用中遇到的具体问题。研究发现，开发者在使用SAST工具时面临多种可用性问题，这些问题可分为两类：一类是工具固有特性所致，需要开发者投入一定的时间和精力去适应和配置；另一类是工具自身的缺陷，需要SAST工具厂商进行改进。作者认为，要推动SAST工具的广泛采用和持续使用，开发者需要接受学习曲线和初始投入，同时工具厂商应简化使用流程、降低使用门槛。此外，解决SAST采用的主要障碍需要综合考虑技术因素和人员因素，包括提升工具的准确性、可解释性、集成便利性，以及加强对开发者的安全培训。该论文的核心贡献在于系统归纳了SAST采用障碍的类别，并提出了双管齐下的解决路径。适合安全研究人员、DevSecOps实践者、SAST工具设计师以及软件工程管理者阅读，以理解工具落地中的真实痛点。

该论文针对软件开发中安全漏洞发现与修复的滞后性问题，提出了一种通用且自动化的静态应用安全测试（SAST）工具集成流程。研究背景指出，SAST 工具虽能有效检测漏洞，但因误报率高、缺乏对原生流水线的支持等可用性问题，在企业中的广泛采用受到阻碍。作者设计了一个聚合 SAST 工具输出并将其接入开发者熟悉的缺陷跟踪系统的过程，从而在开发生命周期内简化安全漏洞的识别与沟通，提升修复效率。该流程是通用化的，不绑定特定工具或平台，但论文以 SonarQube 为 SAST 工具，在基于 GitLab 的开发环境中完成了实证实现。实验结果显示，开发者对该结构化实现、实时反馈和主动漏洞管理持积极态度，尽管存在学习曲线以及安全编码与工作流中断之间的权衡等挑战，但整体上对安全意识和响应能力的正面影响表明，该流程有望增强软件开发实践的安全态势。论文主要贡献在于提出一种可落地、可复用的 SAST 集成模式，减少安全工具与开发工作流之间的摩擦，使漏洞信息能够更早、更直接地触达开发者。适合关注 DevSecOps、应用安全工具链优化及安全开发流程改进的安全工程师、DevOps 团队和软件开发管理者阅读。

该研究聚焦于静态应用安全测试（SAST）工具在发现 Web 应用漏洞时受到代码风格影响的问题。尽管 SAST 工具被广泛使用，但已知其存在诸多局限性，而编码风格对漏洞检测能力的影响此前鲜有系统研究。作者通过组合商业与开源的多种安全扫描器，对 PHP 和 JavaScript 代码进行了大规模实验，归纳出超过 270 种会阻碍现有工具分析的代码模式。这些模式被定义为“可测试性陷阱”（Testability Tarpits），即当代码中出现这些模式时，SAST 工具的分析能力会显著下降，可能导致漏报。基于这一发现，作者提出了一种在软件开发生命周期中识别这些模式的方法，从而向开发者提供关于代码可测试性的重要反馈。该方法不仅帮助开发者了解代码被静态分析的有效程度，还能辅助评估残余风险：即使静态分析器未报告任何发现，代码中仍可能隐藏漏洞。此外，文章还探讨了通过代码转换来提升代码对 SAST 工具的友好度，为增强安全测试效果提供了可行路径。该研究的核心贡献在于首次系统性地量化了代码模式对 SAST 检测能力的影响，并构建了模式清单，为提升 Web 应用安全测试的准确性和覆盖率提供了新的视角。适合安全研究人员、SAST 工具开发者和应用安全工程师阅读。

本文针对静态应用安全测试（SAST）工具中普遍存在的设计权衡问题展开研究。SAST工具在工业界和学术界广泛使用，但为了提升精度、缩短运行时间或增强可扩展性，往往会在检测能力上做出牺牲。这些牺牲建立在某些关于目标代码或分析技术的假设之上，而这些假设会直接影响检测结果。核心研究问题是：这些牺牲真的能带来预期的性能提升吗？背后的假设是否成立？作者提出CAUSEC，一个因果分析框架，将SAST工具的假设形式化为可测试的安全假设，结合假设驱动的因果建模、效应估计和验证方法，从而解释假设与检测性能之间的因果关系，而非简单相关性。为理解安全假设的常见特征，作者对检测加密API误用的SAST工具进行了系统文献综述，识别出57个假设，并进行了定性分析。随后，他们选取一个流行假设，在四个高度相关的工具上使用包含57,038条人工标注警报的数据集进行验证，展示了CAUSEC的实用性和鲁棒性。实验分析产生了几项关于假设和因果效应的关键发现，并总结为三条对未来工作有指导意义的要点。该研究为SAST工具的设计、评估和选择提供了新的因果视角，有助于安全团队更科学地理解工具行为，优化漏洞检测流程。

本文关注静态应用安全测试（SAST）工具的高误报率问题。SAST工具在现代安全软件开发中不可或缺，但生成的误报（FP）告警会带来大量人工审查成本，并降低开发者信任。现有误报缓解方法面临两大挑战：一是不同SAST工具与漏洞类别间差异大，难以学习历史误报中的复用模式；二是所用知识大多静态，无法随新验证案例积累而更新。为此，作者提出Memoir，一种记忆驱动的误报识别框架，将历史误报告警转化为可复用的语义记忆。Memoir包含两个核心模块：其一，历史语义记忆构建模块，通过LLM引导的标注、模式聚类和记忆合成，将历史FP告警结构化，提取可复用的行为模式；其二，记忆驱动识别与演化模块，在预测前检索相关记忆，并针对分类一致性和安全不变式进行语义验证，然后将已验证的预测回添至记忆库，使知识库随案例积累持续演化。实验在CWE-Bench-Java基准上进行，Memoir取得了99.43%的F1分数、98.88%的召回率以及100%的精确率，一致优于其他基线。此外，在顶尖IT公司生产软件系统上的工业案例研究表明，学习到的记忆库无需重新训练即可有效泛化至不同SAST工具。对于安全工程实践而言，Memoir提供了一条利用大语言模型与记忆演化机制降低SAST误报的可行路径。