DEV#POPPER（npm 供应链 RAT）
DEV#POPPER藏在 npm 包里的后门
亦作、亦称：npm 供应链 RAT · DEV#POPPER · DEVPOPPER
DEV#POPPER 是 npm 供应链攻击中植入的远程访问木马家族，通过污染依赖在开发者机器建立持久控制，是 AI 工具链依赖污染的典型样本。
植入路径
攻击者污染流行 npm 包（如植入恶意 postinstall 脚本）或通过依赖混淆抢注同名私有包。开发者一旦安装，后门随依赖链进入环境，可窃取凭据、建立持久控制，并接触 AI 助手能读到的 .env、SSH 密钥、云凭据。
防御要点
使用 lockfile + 完整性校验锁定依赖、审查可疑 postinstall 脚本、启用 SLSA 来源证明验证包来源、在隔离环境中安装与构建依赖、对出站流量做基线监控。核心是不盲目信任任何第三方依赖。
常见误解
日常交流中容易听到的简化说法，未必准确，但能帮助理解误解从何而来。
- 「藏在 npm 包里的后门」
- 「装个依赖就被种了木马」
相关术语
和本术语关联紧密的其他词条，便于串联理解。
🎯 考点练习
含该术语的高频面试题，含标准答案与追问。
- 高级场景查看详解 →
MCP 协议的供应链安全风险有哪些？以 Ruflo CVSS 10.0 为例分析
MCP 把"模型说话"升级为"模型动手"，攻击面随依赖、Server、工具描述、运行时四条供应链路径扩张。Ruflo CVSS 10.0 是生态扩张快于安全成熟的缩影。防御靠零信任 + 纵深防御：来源固定、最小权限、沙箱隔离、human-in-the-loop、把工具输出当不可信数据、完整审计。
- 高级场景查看详解 →
AI Agent 自主发现 0day 漏洞带来哪些安全影响？如何防御？
当 AI Agent 能自主发现 Redis 等软件的 0day 并构建 RCE，攻防双方的能力天平被重新校准。防御侧要把 AI 用于主动审计与红队、缩短检测-响应时间、收敛暴露面，并假设"攻击者也有同等 AI 能力"来设计纵深防御。
- 高级系统设计查看详解 →
如何设计 AI Agent 的最小权限系统？从 AgentForger 攻击谈起
Agent 天生在信任边界内部、行为合法，传统边界防御失效。最小权限系统要把 Agent 当独立身份主体，授予动态、短期、可吊销的权限，高影响操作走 JIT 授权与 human-in-the-loop，并用行为基线检测与不可篡改审计兜底，目标是"单点失守不致命"。
- 高级场景高频查看详解 →
如何防御 AI Agent 供应链攻击？从 OpenAI/Hugging Face 与 Claude 共享泄露事件出发
考察候选人对 AI Agent 供应链攻击面的理解：模型分发渠道投毒、工具/MCP 来源不可信、对话数据信任边界泄露，以及从信任链管理角度的系统性防御。
延伸阅读
从知识库精选 1 篇文章，帮助深入理解该术语。
外部参考
维基百科：查看「DEV#POPPER」词条本页内容为本站原创撰写；维基百科链接仅作延伸参考。