【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载导读xerj-security-audit是仓库 docs/case-studies/wordpress-security-audit/skill/ 中沉淀的一套可复制的 Claude Code 技能Skill它把覆盖率有保证的白盒安全审计完整工作流——建立危险函数知识库 → tree-sitter AST 全量普查 → 证明 0 遗漏 → 索引进 XERJ → AI 推理增强 → 溯源与推理——编码进一个SKILL.md安装后即可对任意 PHP或其他语言代码库执行同样的审计。读完本文你将掌握如何用 XERJ 作为 AI 的第二大脑索引一次、反复盘问绝不整文件加载如何证明我们枚举了每一个危险调用而非空口说我们读过代码以及如何把结论沉淀为可查询、可复用的审计账本。这个 Skill 解决什么问题传统代码安全审计有三种做法各有致命短板整库读代码load-allToken 消耗巨大且上下文装不下。在真实 WordPress core1,492 个 PHP 文件、约 61.9 万行上仅加载一遍就需要约 520 万 Token约为 200k 上下文窗口的 26 倍必须切块——切块后跨文件的调用关系正是漏洞藏身处就丢了结论只能靠扫读猜测。grep 字面搜索精确但无语义。grep 是文件级的无法表达同一函数内既有请求源又有无净化 SQL 汇或未认证 hook 可达某个汇这类跨文件关系在 WordPress 案例中SQLi 分流把 11,990 个函数收敛到 4 个而 grep 交给你 51 个整文件。单靠 AST 污点图能给出候选但无法回答审计最核心的问题——我们漏了吗这个 Skill 的回答是用tree-sitter 解析 100% 语法做全量调用点普查再用grep 与 AST 逐行对账证明零未解释残留最后把每个调用点索引进 XERJ让 AI 通过查询-阅读-推理的循环完成审计。整套方法的核心承诺是一条可辩护的覆盖率声明而不是vibe。安装与前置条件SKILL.md是一个自包含的 Claude Code 技能文件安装只需三步来自 skill/README.mdmkdir -p ~/.claude/skills/xerj-security-audit # 或 repo/.claude/skills/... cp SKILL.md ~/.claude/skills/xerj-security-audit/SKILL.md cp -r ../sink-census ~/.claude/skills/xerj-security-audit/ # 脚本 目录安装后即可在 Claude Code 中通过/xerj-security-audit调用或直接让 AIrun the XERJ security audit。要切换到其他技术栈通过扩展php_dangerous_functions.json即可——污点模型是数据不是代码。运行前需要声明并准备好三样东西见 SKILL.mdXERJ 以 ES 兼容协议运行在http://127.0.0.1:9200启动命令xerj --insecure --data-dir ./datapip install tree-sitter tree-sitter-php以及目标语言对应的 grammar目标源码树在磁盘上。工作流总览setup → map → AST census → prove 0 gaps → index → AI-enrich → reason整个审计是一个必须按序执行、每步如实汇报的循环php_dangerous_functions.json 275 个危险 built-in/构造28 类别 → 漏洞类 污点相关参数 │ ▼ tree-sitter AST任意格式下的每一个真实调用 AST census 11,191 个调用点真实 WordPress core 实测 │ ▼ grep AST 字符串/注释/内联 HTML 判定对照逐条对账每个出现点 COVERAGE PROOF 12,214 个 grep 命中 10,778 个 AST 调用 已证明的非调用0 个 UNEXPLAINED │ ▼ bulk 索引 XERJ wpsinks 每个调用点一个文档file, line, fn, class, arg │ ▼ AI 推理增强embedding pipeline 的对应物 enriched ledger reachable / guarded / severity / verdict —— 可查询的审计账本以下按步骤详解每条都对应仓库中的真实脚本与数据。第 1 步建立危险函数知识库map the dangerous functions这是审计的知识层。sink-census/php_dangerous_functions.json 映射了275 个 PHP 内置函数/语言构造、横跨 28 个类别在可读版 sink-census/PHP-DANGEROUS-FUNCTIONS.md 中为 287 个函数、30 个类别每个条目给出三样关键信息vuln class漏洞类别命令执行RCE-command、代码执行RCE-code、unserialize反序列化、include 加载器LFI-RFI、文件读写删、SSRF、SQL 驱动、LDAP 注入、XXE、动态可调用callable、变量注入、反射调用、弱加密/弱随机、类型混淆等safe vs unsafe recipe该调用的安全/危险用法说明taint-relevant argument污点相关参数哪个参数携带危险——这是污点图的关键。参数标注约定见文件头部 meta0-indexed dangerous argument、*任意、ret返回值即汇、recv方法接收者/URL 在别处设置、self语言构造操作数、cb:N第 N 个参数是回调攻击者可控制时为二阶 RCE。以几个代表性类别为例摘自 PHP-DANGEROUS-FUNCTIONS.mdcommand-execRCE-commandexec/shell_exec/system/passthru/proc_open/popen/pcntl_exec等污点参数均为 0ssh2_exec为参数 1code-evalRCE-codeeval、assert8.0 前字符串参数被 eval、create_function8.0 移除、preg_replace/e 修饰符会 eval 替换串7.0 移除等dynamic-callable二阶 RCEcall_user_func/call_user_func_array/array_map/array_filter/usort/preg_replace_callback等 27 个只要回调可被攻击者控制即构成二阶调用deserializationunserialize、yaml_parse、igbinary_unserialize、session_decode等 8 个——PHP 对象注入POP 链的入口type-juggling认证绕过in_array非严格模式、strcmp数组参数返回 NULL、hash_equals标注为SAFE——正确的常量时间比较知识库连安全函数也收录作为对照基准。这份清单本身聚合了 RIPS sinks、Psalm taint sinks、exakat、PHPCS-Security-Audit、Semgrep php、OWASP 等公开源。为其他框架/语言扩展它数据即代码改 JSON 不用改引擎。第 2 步AST 普查每一个调用点census every call sitesink-census/sink_census.py 用 tree-sitter 解析每个文件记录每一个已收录危险函数的调用点。它覆盖四类节点function_call_expression——普通函数调用exec(...)member_call_expression/scoped_call_expression——方法调用-loadXML、::query语言构造节点——echo_statementecho、include_expressioninclude、require_expression、print_intrinsicprint、shell_command_expression反引号执行等映射到漏洞类echo/print→XSSbacktick→RCE-commandinclude/require→LFI-RFIobject_creation_expression——危险类构造new ReflectionFunction→dynamic-invoke、new SoapClient→SSRF、new SimpleXMLElement→XXE、new ZipArchive/new PharData→zip-slip、new Imagick→image-rce-ssrf 等。tree-sitter 的优势在于无论格式、换行还是命名空间真实调用都会被 AST 捕获如\fopen(这是 grep 做不到的。脚本同时记录 AST 权威的字符串/注释/内联 HTML 行区间NONCODE_NODES {string, encapsed_string, comment, heredoc, nowdoc, text}——这是第 3 步覆盖率证明的判定依据oracle。实测结果真实 WordPress core11,191 个调用点覆盖 275 个内置函数/构造跨 1,492 个文件。第 2b 步普查危险模式patterns——sink 清单抓不到的漏洞类仅枚举危险函数是不够的——有一大类漏洞根本不是函数调用而是语言语义、输入形状或语义缺陷。这正是 sink-census/pattern_census.py 与 sink-census/php_dangerous_patterns.json 覆盖的维度。AST 可检测的模式包括宽松比较/!loose-eqmagic-hash0e1230e456、0false、null0等类型混淆认证绕过对涉及hash()/md5()/token/密码的变量特别标记switch宽松匹配switch-looseswitch($_GET[role])中0abc会匹配case 0strcmp数组参数strcmp-array?pw[]x使$_GET[pw]成数组strcmp(array,$secret)返回 NULLif(strcmp(...)0)即NULL0为真 → 认证绕过非严格in_array/array_searchin-array-loosein_array(1abc,[1,2,3])为真 → 白名单绕过错误抑制error-suppressionunserialize/file_get_contents隐藏安全相关失败变量变量$$xvar-variable请求可控的 key 造成任意变量覆盖不安全的setcookiecookie-flags缺少 HttpOnly/Secure/SameSite对请求值switch、Host 头信任$_SERVER[HTTP_HOST]、ORDER BY / LIMIT 注入正则检测。php_dangerous_patterns.json还收录了 AST 无法直接判定、需要推理清扫的语义类SQL 截断非 STRICT 模式下注册admin55空格x截断成admin、多字节字符集 SQLiGBK/Big5 addslashes绕过、二阶注入存储后原样拼接、phar:// 反序列化、TOCTOU 文件竞态、上传即执行、is_numeric绕过、正则锚点绕过、会话固定、上下文错误转义等——每一条都给出 attack攻击方式、detect检测方式标注 ast/regex/query/manual和 safe安全写法。完整对照见 sink-census/PHP-SECURITY-GUIDE.md。实测WordPress core 上2,077 个模式命中10 个 AST 可检测模式被索引进wppatterns。第 3 步证明覆盖率PROVE coverage——本方法的核心保证不可跳过AST 普查只有证明没漏才可信。sink_census.py的对账逻辑是对每个已收录函数独立用 grep 找出所有源码出现点再与 AST 调用点集合逐条对账。grep 命中的每一行必须属于两类之一是 AST 调用点匹配成功matched是可证明的非调用classify_nonast分类注释/文档块、字符串字面量借助 AST 字符串节点行区间判定能正确处理多行字符串和 docblock、函数定义、其他对象上的方法调用$response-header(...)≠header()内置函数、变量名$echo、已被 AST 覆盖的命名空间调用等。脚本输出的干净结果形如COVERAGE RECONCILIATION AST call sites: 10,778 grep occurrences: 12,214 UNEXPLAINED: 0 coverage PROVEN (0 gaps)真实数字grep 找到 12,214 个目录名出现点其中 10,778 个是 AST 调用点其余 1,436 个每一个都被证明为非调用字符串/注释/内联 HTML/定义/方法/变量名等UNEXPLAINED 残留为 0。论证之所以无懈可击tree-sitter 解析 100% 的 PHP 语法任何真实调用必然是调用表达式节点对账证明 grep 与 AST 的差集里没有任何真实调用藏身。文档还记录了一个有趣的工作示例最后两个顽固残留是__()多行帮助字符串里的英文单词 include正是 AST 字符串行区间判定而非基于行的 grep 过滤把它们正确归类。规则如果 UNEXPLAINED 0每一个残留都必须解决要么是提取器漏掉的真实调用——修复目录/节点处理要么是可证明的非调用。存在未解释残留时永远不要声称覆盖率。第 4 步索引 风险分流XERJwpsinks普查脚本把每个调用点 bulk 索引为wpsinks的一个文档字段file, line, fn, kind, class, argarg截断 200 字符外加预置的增强字段reachable/guarded/severity/ai_verdict/enriched。映射见 sink_census.py{mappings: {properties: { file: {type: keyword}, line: {type: integer}, fn: {type: keyword}, kind: {type: keyword}, class: {type: keyword}, arg: {type: text}, reachable: {type: keyword}, guarded: {type: keyword}, severity: {type: keyword}, ai_verdict: {type: text}, enriched: {type: boolean} }}}索引完成后风险画像就是一条聚合查询。WordPress core 实测分布来自 COVERAGE-AUDIT.md类别调用点数类别调用点数XSSecho/print3,799file-write178LFI/RFIinclude/require1,385variable-injection166type-juggle 认证绕过1,240weak-crypto142XSS-or-infoprintf/var_dump1,034SSRF107动态可调用二阶 RCE954file-delete61ReDoS/ereg709XXE26RCE-codeeval/assert467deserialization13file-read328RCE-command11SQL 驱动200dynamic-invoke反射6稀有类别才是重点整个 core 只有 11 个命令执行汇和 13 个反序列化汇——而现在你可以保证每一个都见过。大的类别XSS/输出、类型混淆、可调用则交给后面的污点图与授权图去判定可达性。第 5 步AI 推理增强成审计账本enrich_pipeline.pysink-census/enrich_pipeline.py 是增强循环对每个高风险点**AI 智能体而非model.encode**读取参数与外围代码判定并写回四个字段reachable可达性request / cache / trusted / literalguarded防护哪个防御在起作用如escapeshellarg、HMAC、is_serialized、allow-list、literalseverity严重度review / medium / low / noneai_verdict推理结论带file:line证据。这就是 embedding pipeline 的同构对应物——同样是索引 → 增强 → 查询但这里的增强是经过推理的安全判断并且跨轮次累积每个审过的 sink 都是下轮审计和 CI 直接复用的已存判决。脚本策略100% 增强稀有类别RCE-command 11/11、deserialization 13/13 全部带完整判决其余高风险类别批量打上severity:review排队等待逐点阅读。实测增强后账本查询来自 VERIFY-AND-TRACE.mdtotal sink sites: 11,191 by severity: {review: 1472, medium: 17, low: 9, none: 4} rare classes (RCE-command deserialization): 24/24 carry a full verdict (100%)示例判决真实存储内容File.php:88 [medium] feed-cache-file | simplepie-filterediterator reads cache file then unserialize; POI if cache dir writable第 5b 步通过 API 端到端追踪任意 sinktrace_sink.pysink-census/trace_sink.py 演示了数据确实活、可查以及追踪能力——全程不读本地文件只通过 XERJ API 做索引联接wpsinks → 该 sink AI 增强class, arg, reachable, guarded, verdict wpaudit → 外围函数sources / sinks / sanitizer / calls wpauthz → 该函数的 cap/nonce 守卫 wpaudit → 反向调用者谁调用它 他们是否读取请求源用法python3 trace_sink.py file line。文档中的工作示例——REST widget 实例的unserialize■ SINK ...class-wp-rest-widgets-controller.php:589 fnunserialize classdeserialization arg( $serialized_instance ) ENRICHMENT: severitymedium reachableREST-auth-optin guardedshow_instance_in_rest-gate ■ ENCLOSING FUNCTION save_widget() (line 526) reads sources: [$_POST,$_REQUEST] sanitizer-in-fn: False other sinks: [deser,lfi] AUTHZ: object-scoped-capFalse nonceFalse ■ REVERSE CALLERS of save_widget(): 2 ::create_item ::update_item ■ TRACE VERDICT: enclosing fn reads [$_POST,$_REQUEST] with a sink and no in-fn sanitizer - SOURCE-SINK candidate (confirm arg flow guards)追踪正确暴露出请求输入抵达反序列化汇——然后由你去读真实守卫show_instance_in_rest选择加入 widget 哈希确认或排除。图指路你来读这就是整个循环。追踪脚本还记录了两个已知的 XERJ 引擎注意事项诚实报告工具缺陷的体现term对 keyword数组只匹配第一个元素仓库已为此提交修复见 docs/research/xerj-keyword-array-term-fix.md因此反向调用者用代码内扫描_source的calls数组实现裸方法名load/query/get/save跨类冲突追踪对这些名字限制在同文件内解析并在输出中说明。第 6 步推理真实 bug——census 看不见的部分Sink 覆盖 ≠ 总覆盖。在第 6 步用案例研究中的其他检测器清扫 census 触及不到的三类问题对象级授权 / IDORwp_authz_graph.py、wp_checkuse_idor.py见 docs/examples/ast-vuln-graph/——危险形状是对象由请求输入命名却只检查了通用 cap 或没有检查校验器完整性wp_ssrf_ranges.py——一个不完整的允许/拒绝列表例如 SSRF 校验漏掉169.254网段净化器组合顺序wp_compose_index.py——一个净化器破坏另一个如先转义再反转义。每个候选都要先读、再执行验证把流程移植成可运行语言再跑并把可达性追溯到真实输入。第 6b 步过程间污点分析taint_analysis.pysink-census/taint_analysis.py 在 AST 导出后基于 XERJ 中的调用图做 source→sink 污点每个读取请求源的函数沿调用图 DFS 到它能到达的每个危险汇路径上无净化器按严重度排序、给出完整路径。它只走无歧义边同名函数仅一个定义支持函数内intra同函数内 sourcesink无净化与过程间inter跨调用边两类流。脚本明确声明这是高召回的可达性分流不是精确的逐参数数据流——WordPress core 的 SQL 流包含WP_Query安全和intval守卫的汇所以每个候选仍需人工/AI 阅读确认。实测产出 70 个候选流前 200 写入taint_flows.json。完整方法见 sink-census/TAINT-ANALYSIS.md。第 6c 步POP gadget 狩猎gadget_hunt.pysink-census/gadget_hunt.py 遍历每一个魔法方法__wakeup/__destruct/__toString/__call/__get/__set/__invoke/__unserialize等 15 个沿调用图追踪到危险调用——这就是反序列化 gadget 面。其中AUTO 触发的四个__wakeup/__unserialize/__destruct/__toString由 unserialize/free/print 自动调用被标记为LIVE gadget真正可利用的。实测 WordPress core131 个魔法方法0 个 AUTO 触发的到达危险汇——即使存在任意对象注入也没有核心 gadget 链可升级。完整分析见 GADGET-CHAINS.md。脚本还测量了 token 成本整个调用图的 XERJ 事实func/calls/sinks加载一次约数千 token而答案是几十个候选——比 grepread 便宜约 3,900 倍。诚实规则让结果可信的六条纪律这些规则来自 SKILL.md是方法论的一部分而非装饰图与事实出精度全文只用于导航——原始代码上的全文检索对安全太嘈杂先读、后执行验证——把流程移植成可运行语言再跑任何论断不得凭对框架的记忆必须引用拉取的file:line先追溯到攻击者可控输入再叫它 bug不制造发现——干净的阴性negative是合法结果报告基座/引擎缺陷——不可能的查询结果意味着工具错了而不是现实错了已知 XERJ 注意事项keyword数组上的term只匹配首元素——反向调用图请在代码中遍历_source布尔term按字符串匹配——请用true字符串精确陈述覆盖率声明目标中每个对已收录危险函数的调用都被零缺口普查枚举——而不是我们读了代码。这套方法赢得的覆盖率声明目标代码库中对已知危险内置函数的每一次调用N 个点、M 个函数、K 个文件都被零缺口 AST 普查枚举、索引并按漏洞类分流命令执行 / 反序列化 / SQL 汇的100% 携带 AI 判决。这就是我们读过代码永远给不出的、可辩护的覆盖率声明。真实 WordPress core 上的完整声明COVERAGE-AUDIT.md11,191 个调用点、275 个函数、28 个类别、1,492 个文件0 缺口RCE-command / deserialization / driver-SQL 三类 100% 有 AI 判决。案例实测XERJ 辅助审计 vs 让 Claude 读完所有文件案例研究 README.md 给出了可复现的对照Claude 读所有文件XERJ 辅助审计本案例审一遍 core 的 Token仅加载约 5,200,000全程约 26,000约 199× 更少放得进一个上下文否——约为 200k 窗口的 26×必须切块是——定向查询 只读被标记的代码过程间可达性切块即丢失bug 是跨文件的调用/hook 图跨所有文件保留接地 / 幻觉扫读 520 万 token → 靠猜每个论断引用拉取的file:line可复现否——依赖它读了什么是——脚本 查询精确复现覆盖率装进窗口的就是全部AJAX 95 · REST 90 · file-scope 41 · engine约 199× 更少的 token 且质量更高——因为图决定读什么agent 精确读每个候选而不是扫读一个装不下的干草堆。案例审计覆盖的结论完整见 FINDINGS.mdAJAX 95 个 handler、REST 90 个权限检查对象级授权0 IDORmap_meta_cap授权引擎失败即关闭fail closedSQL 双重prepare反转义仅靠placeholder_escape才安全唯一真实弱点wp_http_validate_url允许169.254.0.0/16云元数据→SSRF——靠读IP 范围覆盖发现模式扫描器看不见不完整的 allow-list移植执行验证追溯到未认证可达pingback_ping反序列化 POP gadget核心0 个可自动触发的链审计还顺带暴露了一个真实的 XERJ 引擎 bugkeyword 数组term只匹配首元素已修复并记录在案。在其他代码库复用与扩展把docs/case-studies/wordpress-security-audit/sink-census/*和本 Skill 一起复制走SKILL.md 给出了安装命令然后把sink_census.py指向你的源码树、扩展php_dangerous_functions.json或为你的语言加 grammar 平行目录即可。证明步骤与增强循环与语言无关——仓库 docs/examples/ast-vuln-graph/scan_multilang.py 已经用同一套 tree-sitter 引擎覆盖 PHP/Python/Go/Rust/Java每种语言只需在LANGS配置里加一行sources/sinks/sanitizers模型是数据不是代码。复现命令完整版见 COVERAGE-AUDIT.md 与 VERIFY-AND-TRACE.mdcd sink-census python3 sink_census.py /path/to/wordpress # AST 普查 覆盖率证明 索引 wpsinks python3 pattern_census.py /path/to/wordpress # AST 可检测模式 - wppatterns python3 enrich_pipeline.py # AI 判决 - 增强账本 python3 trace_sink.py file line # 通过 API 端到端追踪任意 sink诚实的局限XERJ 不找 bugAST 污点/授权模型产生候选XERJ 负责存储与查询。把原始文件块直接喂给它其安全价值基本消失召回受模型约束文件作用域的源或被$GLOBALS洗白的源不可见。grep 有完美字面召回和糟糕精度此方法以召回换精度与 token精度检测器有已知的误报驱动因素接收者类型化的汇、自作用域写入、多态 cap——每个候选仍需要一次人/AI 阅读确认价值在于数量少到读得完sink 覆盖 ≠ 总漏洞覆盖不覆盖逻辑缺陷、缺失授权/IDOR、不完整校验器——这些由案例研究中的其他检测器负责覆盖率只和目录一样完整保证是对已收录函数的每次调用为框架 sink 扩展 JSON 后重跑即可普查与证明无需改动。把这条方法放进 CI 或下一次代码评审索引一次、证明零缺口、图决定读什么、读到的都写成可查询的判决——这就是把我们审过了变成可辩护、可复用、可复现的工程事实。赞分享【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载相关推荐XERJ 驱动零遗漏白盒审计用 AST 危险函数普查证明 WordPress 安全审查覆盖度XERJ 驱动零遗漏白盒审计用 AST 危险函数普查证明 WordPress 安全审查覆盖度 这篇技术指南基于 COVERAGE AUDIT.md https用 XERJ 构建可证明零遗漏的 PHP 白盒安全审计sink 普查与危险模式双轴完全指南用 XERJ 构建可证明零遗漏的 PHP 白盒安全审计sink 普查与危险模式双轴完全指南 本指南围绕 xerj security audit 技能源于对真用 XERJ 给 WordPress Core 做白盒安全审计一套 199× 省 Token 的 AI 审计方法论用 XERJ 给 WordPress Core 做白盒安全审计一套 199× 省 Token 的 AI 审计方法论 本文基于仓库中 docs/case stu上一篇AutoRAG项目中的NumPy 2.0兼容性问题解析下一篇3步解决Layui DropDown遮罩穿透难题从现象到源码修复创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考