$ loading_
帮助开发者排查 Pysa 漏报污点问题，比较输出并定位污点流丢失位置。
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "pysa-false-negative-debugger" 技能： 1. 下载 https://raw.githubusercontent.com/facebook/pyre-check/main/.llms/skills/pysa-false-negative-debugger/SKILL.md 2. 保存为 ~/.claude/skills/pysa-false-negative-debugger/SKILL.md 3. 装好后重载技能，告诉我可以用了
请帮我调试一个 Pysa 漏报问题。我预期这个入口参数会传播到危险汇点，但结果中没有告警。请分析可能在哪个调用链、模型或特性处理环节丢失了污点流，并给出排查步骤。
给出污点流可能中断的位置、关键排查节点，以及后续验证建议。
我有两个 Pysa 输出目录，一次是旧版本，一次是新版本。请比较它们的差异，找出为什么新版本少了一条预期的污点告警，并指出可能受影响的规则、模型或调用关系。
输出差异摘要，并解释导致告警消失的潜在原因与定位线索。
请根据这段代码和 Pysa 分析结果，追踪从 source 到 sink 的污点传播路径，精确指出污点在哪个函数、返回值、参数传递或模型定义处被截断。
返回清晰的传播路径说明，并标出污点丢失的具体位置。
Systematic workflow that identifies exactly where and why taint flow is lost by comparing two Pysa result directories. Accepts static analysis issue URLs (e.g., https://www.internalfb.com/security/static_analysis/issue/<issue_instance_id>?database=<database>).
REQUIRED BACKGROUND: Load the pysa-json-models skill to understand trace element syntax (ports, call info, kinds).
The user must provide:
https://www.internalfb.com/security/static_analysis/issue/<issue_instance_id>?database=<database>From the URL, extract:
216172782209137158)databasexdb.pysa-instagram-sharded.1Get the issue handle:
db <database> -e "SELECT handle FROM issues WHERE id=(SELECT issue_id FROM issue_instances WHERE id=<issue_instance_id>);"
If the query fails, ask the user for help.
Example handle:
accounts.service.Service.async_is_phone_suspicious:5120:0:Call|accounts.service.Service._async_helper|0|f:ec82abb59a9d0e207fe4f5acc361f0ad
Extract:
: (e.g., accounts.service.Service.async_is_phone_suspicious): (e.g., 5120)All commands below use buck run to invoke the explorer. The shorthand <explorer> means:
buck run fbcode//tools/pyre/tools/pysa_model_explorer_cli:pysa_model_explorer --
Run <explorer> --help for usage details.
Suppressing build noise: Always append 2>/dev/null to explorer commands to suppress buck build output that clutters the results. Only retry without 2>/dev/null if the command produces empty or unexpected output, so you can see the actual error message from buck.
Confirm the issue exists in FOUND:
<explorer> /tmp/FOUND get-issues <root-callable> --handle <handle>
If not found, ask the user for help.
Confirm it does NOT exist (or is very different) in NOT-FOUND:
<explorer> /tmp/NOT-FOUND get-issues <root-callable> --code <code>
The result should be empty or contain very different issues (different locations).
Check these options in order: A → B → C.
In the issue from FOUND, examine "traces" → entries with "name": "forward".
Each root (trace element) may have multiple kinds with different "length" values. Pick the root whose minimum "length" across its kinds is smallest (missing length = 0, which is always shortest).
If it's an origin: the source comes from a user-annotated function. Check if at least one of the leaves have a model in NOT-FOUND:
<explorer> /tmp/NOT-FOUND get-model <leaf-callable> --show sources --kind <kind>
If none of the leaves have source taint in NOT-FOUND, taint is lost at one of these leaf callables. If at least one does, the source trace is intact — move to Option B.
If it's a call with "resolves_to": [<callee-callable>, ...]: check if those callables have source taint in NOT-FOUND. If there are multiple entries (overrides), check all of them — taint is lost only if ALL are missing:
<explorer> /tmp/NOT-FOUND get-model <callee-callable> --show sources --kind <kind>
Interpret the results:
…
用于运行、调试与更新 Pysa 污点分析端到端集成测试及期望结果
帮助你为复杂问题编写调试测试并反复验证，快速定位异常根因。