该论文介绍 DARPA「Translating All C to Rust (TRACTOR)」项目框架下的一套标准化评测基准。研究背景是:C 与 C++ 等内存不安全语言长期承载大量关键软件,缓冲区溢出、释放后使用等内存安全漏洞也随之成为持续性的安全风险来源;而编程语言、程序分析与人工智能技术近年来的进展,使通过自动翻译把遗留 C 代码库迁移到 Rust 等内存安全语言成为可行的现代化路径。TRACTOR 项目的目标是为大规模 C 代码库向安全、高性能、可维护的 Rust 迁移提供可扩展的技术能力。MIT Lincoln Laboratory 作为该项目独立的测试与评测(independent test and evaluation)机构,构建了这套标准化基准,以便对各类 C-to-Rust 翻译工具进行系统化、可复现的横向比较。基准由难度递进的测试题库(progressively challenging test batteries)以及规模更大的里程碑项目(milestone projects)组成,并配套评测基础设施与度量指标,分别从四个维度评估翻译结果:correctness(功能正确性)、safety(安全性)、idiomaticity(是否符合 Rust 惯用风格)以及 performance(性能)。报告描述了基准的构成与设计、评测流程与指标定义,并说明基准和配套评测基础设施已公开提供,用以支持 C-to-Rust 翻译技术更广泛的研发与评估。读者对象为程序分析、软件工程、自动化程序迁移方向的研究者,以及负责遗留系统现代化与内存安全治理的工程与安全团队。

该论文聚焦生成式 AI 编码助手在软件开发中带来的一个被忽视的环节：开发者对 AI 生成代码的“评估行为”，而非最终产出的代码本身。研究背景是：AI 编码助手（自动补全、对话式工具、AI Agent）正迅速改变开发流程，且已被证实会生成不安全代码。既有工作多测量“AI 辅助开发者最终产出的代码是否安全”，但很少有人系统研究开发者在采纳前如何评估这些建议——他们能否识别其中的漏洞、依据哪些线索做出判断、以及信任程度如何影响其选择。作者认为，无论使用何种形态的 AI 编码工具，这个“人工评估”步骤都是安全开发的基础环节，因此需要先把它单独隔离出来研究。 方法上，作者开展了一项远程观察性研究，共招募 100 名参与者，实验设计刻意切断“写代码”与“评估代码”的耦合：参与者需针对四个 C 语言链表（linked-list）编程任务产出既安全又可用的代码。在每个任务中，参与者可以浏览五条 AI 生成的候选建议，这些建议在“安全性”和“功能正确性”两个维度上被有意设计成不同组合；参与者从中选择一条，并在此基础上编辑成最终提交版本。实验后，所有参与者填写问卷，测量其决策过程、对 AI 生成代码安全性的感知与信任；此外还有 23 名参与者接受了更深入的访谈，用于挖掘其判断依据与推理过程。 主要贡献可概括为：首次以较大样本（100 人）并通过观察 + 问卷 + 访谈三重手段，专门刻画开发者对 AI 生成代码的安全评估过程，识别其使用的判断线索、信任对采纳行为的影响，以及评估能力的局限；研究设置（可循环浏览五条不同安全/功能权衡的建议再选择）也为后续人因安全研究提供了可复用的实验范式。需要注意的是，本条目仅基于论文摘要，摘要未披露具体定量结果（如漏洞识别率、信任与选择之间的相关性方向等），这些结论需查阅全文。适合人群：AI 编码助手研发与产品团队、安全编码培训设计者、软件工程与人机交互（HCI/Security）研究者、以及负责 AI 代码审查流程的 AppSec 团队。

该论文关注 AI 编程助手大规模进入软件开发生命周期后带来的安全风险,但指出当前研究存在明显偏向: 大量工作聚焦于「AI 生成代码中是否存在漏洞」这一检测问题,而缺乏对漏洞严重性、任务语境与整体风险水平的系统化评估方法。为填补这一空白,作者提出安全风险评估框架 SRF(Security Risk Assessment Framework)。SRF 在方法论上由三部分构成: 第一,威胁建模,用于在评估前明确资产、信任边界与潜在攻击面; 第二,安全分析,借助静态分析工具对生成代码进行扫描; 第三,基于漏洞严重性(criticality)的定量风险评估,把检测结果映射为可比较的风险等级,从而避免只给出「有/无漏洞」的二元结论。实验设计上,作者选取一组与安全相关的编程任务作为基准,覆盖输入处理、文件处理等不同类别,并让多个主流 AI 开发工具分别生成实现代码,统一使用 Bandit 与 Semgrep 进行静态分析。结果显示: 所有被评估的 AI 工具生成的代码均会引入安全漏洞,说明这并非个别产品的问题,而是当前生成式编码范式的共性风险;风险等级随任务类型显著变化,输入处理与文件处理类任务的风险明显更高,而较简单的任务仍维持在低风险区间;不同工具之间存在差异,但工具间差异小于任务类别之间的差异,提示「任务语境」比「工具品牌」更能解释风险高低。作者据此认为,SRF 提供了可复现的评估流程与实用框架,可帮助组织在采纳 AI 编码工具时量化其安全影响。适合关注 AI 辅助开发治理的安全团队、DevSecOps/SSDLC 工程师、代码审计人员以及 AI 合规与风险管理岗位阅读。由于仅依据摘要,具体的任务清单、提示词设置、样本量与统计细节无法确认。

Python 应用在机器学习、科学计算等关键领域广泛存在，这些应用常通过集成 C 等底层语言编写的原生代码来提升性能或实现互操作。然而，原生代码中的缺陷（即 native code bugs）通常隐蔽且难以察觉，给整个 Python 应用的质量带来了额外挑战。尽管已有相关研究，但学术界和工业界对这些缺陷的系统性理解仍然不足。本文首次针对 Python 应用中的原生代码缺陷进行了深入的大规模实证研究。作者从 GitHub 上真实的开源 Python 项目中人工筛选并分析了 216 个原生代码缺陷，结合自动化工具与人工分析，系统梳理了这些缺陷的常见症状（如崩溃、内存错误）、引入位置（如绑定层、扩展模块）、外在表现特征、根本原因（如内存管理错误、类型转换问题、引用计数问题）以及修复模式。研究获得了一系列新颖的发现，例如这些缺陷往往集中在特定类型的 API 边界处，且某些根因在不同项目中反复出现。作者还总结了有效的修复策略和代码审查中值得关注的信号，为 Python 生态中的开发者、代码审查者以及安全人员提供了第一份系统的证据基础，有助于改进工具检测、测试方法和编程实践，从而降低原生代码引入的安全与稳定性风险。

本文针对C语言内存安全加固研究中普遍存在的“单漏洞类孤立评估”问题，提出了一种全新的跨语言比较评估范式。过去数十年，研究者提出了许多针对C语言的内存安全回填机制，但这些机制几乎总是在孤立条件下、针对特定漏洞类型进行评估，导致实际工程实践中难以判断多种防御机制叠加后带来的综合性能开销、互操作冲突和保护覆盖缺口。作者主张应像评估原生内存安全语言（如Rust和Go）那样，对C语言的复合加固方案进行整体性基准测试。为此，他们设计了一套标准化的跨语言任务集，同时部署多种先进的内存安全回填机制，并测量其组合使用时的性能与防护效果。实验结果显示，分层部署的C语言防御机制会带来累积的、依赖工作负载的性能惩罚；部分机制之间存在根本性的架构不兼容；即便叠加多项加固，其防护范围仍无法达到Rust或Go等原生安全语言的水平。这些发现揭示了一个关键的工程决策缺口：在遗留C代码库中向后移植安全特性的真实成本往往被隐藏，使开发团队难以在加固旧系统和迁移到现代安全语言之间做出明智选择。作者因此呼吁内存安全研究领域应放弃孤立评估模式，转向更全面、可比较的评估框架，以帮助高风险决策（如是否重写系统）建立在可靠的数据基础上。该研究对系统软件、嵌入式设备、网络服务等依赖C语言的高危场景具有重要参考价值，也为安全团队评估长期投入方向（是修补还是迁移）提供了方法论支撑。