LSCBench：重建粒度、判分对照与当次证据
LSCBench：重建粒度、判分对照与当次证据
知识点轴：benchmark-evaluation / sandbox-security / harness-runtime；MCP Gateway 的出站/凭据与 A2A 的任务权限可迁移为题型，不是论文实测对象。原文 v1 页眉 2026-10-10，代码快照最后提交 10-21，均不是今日首发。本轮读主文 §3–5、构造附录相关段、固定 README、一个 SSRF 题的合同/配置/判分驱动/安全测试/轴读取器；没有跑作者模型、容器或攻击。
为什么值得深挖，而不只抄安全通过率
cwe-bench-defense-verifier-and-discovery-contract已经覆盖未知漏洞审计与 功能 F ∧ 安全 S。LSCBench 的新增价值是：同一漏洞场景派生 function/file/repo 三种重建范围，以多种对照检验“测的是行为，不是补丁字符串”，再用隔离判分器和当次报告绑定结果。这能改进用户未来的私有 coding-agent 题池，而不是再造一个榜单。repo 指声明的源码范围，不总是整个仓库；论文也说明大仓库会保留其余 substrate。
作者称 150 个场景对应 450 题、7 种语言与 24 CWE。固定 GitHub tree 未截断，本轮本地枚举实得 function/file/repo 各150个任务目录，公开 catalog 有2700条尝试、6个模型、450个唯一路径。这只是文件清单核对，不是确认每条轨迹判分正确或独立重放。^[raw/articles/lscbench-2610-14766v1-pinned-verifier-2026-10-23.md]
一阶机制：出题、对照与判分分别守什么
- 控制任务粒度，不泄露补丁形状：function 以完整函数等语义单元挖空，file 移除被修文件，repo 清空声明源码范围；保留调用者、构建与运行约束。说明书只规定功能/接口/可达性，不直接点名漏洞与补救。每种范围是独立尝试，不是同一 agent 逐步获得更多信息；因此跨粒度全通过衡量一致性，不是重试 pass@k。
- 对照必须挑战裁判：作者先要求漏洞版
F通过/S失败、修复版F通过/S通过；另用“仍是漏洞代码、只把补丁贴成注释”的 narrated candidate 排除源码字符串匹配伪解。最终 Harbor 门要求 oracle 同时过两轴、nop 两轴都不过。这些对照检验不同错误：nop不能替代仍能正常运行的漏洞负例，oracle也不能替代不同写法的合法解。与verifier-hardening-output-boundary-and-fresh-solvability的旧解回放/新盲解门互补，不能互相省略。 - 隔离的是环境，也要限制输入：separate verifier 在新容器接收声明可编辑产物，再按冻结脚本重建/启动。样本
task.toml中 agent 为no-network，verifier 为separate，setup/verifier 所在环境可联网；这不等于“全流程无网络”。模型API放行、构建下载、DNS与callback均须分别记有效出站规则。只在提示里说“不改其他文件”不等于 runner 已强制只接收允许文件。 - 当次报告胜过 shell 成功码：样本
tests/test.sh在 verifier 运行时生成随机32位hex token，以 token 命名 JUnit；构建失败写两轴0。脚本不把子runner的退出码当判分真值，因为结尾echo可能掩盖测试失败；而读取同次测试报告并拆 F/S。split_axes.py区分 xunit 的 file/classname，未收集、全skip、error或报告不可读不能当通过。部分skip而仍有运行用例时并不会自动判0，仍须核预期测试清单/收集数量。 - nonce只是证据的一部分：不可预知文件名降低预置旧报告机会，但不能单独证明报告来自可信测试。要同时守住 verifier 身份、不可变测试、允许产物、报告写入权限、fixture和环境继承；脚本注释还记录了运行token丢失、fixture未拷贝、分两次pytest时完整性canary被排除等迁移错误。这里是固定源码阅读，不是对整套runner已无漏洞的认证。
数据应该怎样解释
论文主结果为每题一次尝试的 pass@1，缺失轴记失败；作者报告功能通过73.6%–91.3%，联合通过最高25.1%，同场景三粒度联合通过最高12%。这些是作者在特定模型×harness条件下的数据，不是用户Hermes的安全通过率。同一场景的三题相关，450题不等于450个独立漏洞；跨粒度场景率、题目率和“已功能通过条件下的安全率”分母不同。论文不同模型使用不同harness，未提供本站多次重复/成本回放，不能拿榜单差异全归因模型。
论文的功能中性题意还会隐藏业务安全策略：例如哪些地址可访问、哪些字段该保密。测“自行推断安全边界”与测“遵守明确企业policy”是不同任务。内部题池应分别设有/无显式策略两组，别把不明确的业务契约当万能模型能力标尺。
给 Hermes / 私有 runner 的可执行迁移
- 从一个自有小场景开始，同样业务接口做三种源码范围；密封BASE/漏洞版/GOLD、题意、镜像、构建和判分器版本。不要把公开题测试/canary抄进agent上下文；raw归档不晋升为skill或可信指令。
- 固定四类对照：GOLD、可运行漏洞版、narrated伪补丁、nop；再补不同实现的合法解。记录
计划→可构建→服务就绪→测试实际收集→F/S→联合结果，基础设施故障保留独立原因，即使对外计分为0，也不都归因模型。 - 判分器仅接收允许产物；运行时生成report nonce，绑定task/attempt/产物hash/测试清单/镜像与模型-harness版本。报告、真实服务状态与日志分开留证；正常功能不可仅通过“攻击未打通”推断。
- SSRF样本安全测试用callback查询观察是否产生出站命中；本轮所读文件中的部分分支以未返回200表示未观测到命中。这仍要求callback健康、请求可到达和预期事件被收集的独立正例。没有读取该镜像内完整functional suite/fixture或复现，不能断言它已经存在可利用的误判。
边界与待验证
测试数量与当次nonce都不能证明“hack-free”；公开已知漏洞、镜像/依赖缓存和题目构造模型可能引入污染或共同盲区。源码tree中的该题未单独暴露 test_func.py/conftest.py（请求404），完整镜像内容、产物转移执行、callback健康、成本/重复和真实攻击覆盖尚未独立验证。下一步应先在隔离合成题核对照和判分证据，不在生产仓库/服务运行PoC。
关联：Agent-Benchmarks负责分母与重复；Harness-Engineering负责实际装配；LLM-Wiki-Optimization-Log收敛为稳定准则；llm-wiki-optimization-2026-10-23记录本轮选材与验收。
写入记录
- 2026-10-23 09:10 CST：新增LSCBench构造对照、三重建粒度、隔离产物/当次JUnit证据与内部题池迁移；区分清单核对、固定源码阅读和未做的模型/容器复现。
- 2026-10-23 09:13 CST：补关键清单/论文来源定位；本轮定向检查通过，云端语义检索相关问法实际召回本文。