在node.js调试器中需通过--trace-module-resolution启动并执行process.mainmodule.children查看运行时模块树，配合https.request钩子、strace及eslint-plugin-security规则实现sdk动态加载与危险行为的深度审计。
Node.js调试器里怎么看到SDK实际加载的模块树
直接看 node_modules 目录没用——很多SDK会动态 require、用 eval 加载字符串代码，或通过 require.resolve 绕过静态分析。必须在真实运行时观察模块加载链。
启动调试时加 --trace-module-resolution 参数，能打印出每个 require() 的完整路径和解析结果：
node --trace-module-resolution --inspect-brk app.js
然后在 VSCode 调试控制台里执行 process.mainModule.children，能看到当前已加载的所有模块及其父子关系。重点关注那些名字含 crypto、child_process、net 或来自非 npm 官方源（比如 github:xxx/yyy）的子模块。
- 如果某个 SDK 的子模块里出现
require('fs').writeFileSync调用，说明它可能写本地文件 - 发现
require('https').request但目标域名不在白名单里，就得查它是否静默上报数据 -
process.env被读取多次，尤其在初始化阶段，可能是为了提取密钥或环境特征
如何拦截SDK的网络请求并检查其 payload
VSCode 自带的调试器不抓 HTTP 流量，得靠 Node.js 的 http 和 https 模块钩子。在入口文件顶部插入以下代码：
const origRequest = require('https').request;
require('https').request = function(...args) {
const opts = args[0];
if (opts.hostname && /api|track|log|metric/.test(opts.hostname)) {
console.warn('[SDK TRACKING]', opts.hostname, opts.path);
}
return origRequest.apply(this, args);
};
这样不用装额外代理工具，也不依赖 Chrome DevTools Network 面板。注意：某些 SDK 会检测并绕过这种 monkey patch，所以建议配合 strace -e trace=connect,sendto node app.js（Linux/macOS）做交叉验证。
- 只对明确信任的域名放行，比如
yourbank-api.com；其他一律 warn 或 throw - 如果 SDK 使用
fetch（而非https.request），需额外 patchglobalThis.fetch - 避免在生产环境启用该 hook，仅用于本地安全审计
ESLint 怎么配置才能捕获 SDK 里的危险调用
默认 ESLint 规则只扫你写的代码，对 node_modules 里的 SDK 是盲区。必须启用 eslint-plugin-security 并显式开启 detect-object-injection 和 detect-non-literal-fs-filename 这类规则，再把 node_modules/** 加进 lint 范围：
"rules": {
"security/detect-object-injection": "error",
"security/detect-non-literal-fs-filename": "error"
},
"ignorePatterns": ["!node_modules/**"]
关键点在于：不能只依赖 no-eval 这种表面规则——很多恶意 SDK 用 Function('return ' + payload)() 绕过，而 eslint-plugin-security 的 detect-eval-with-expression 才真正匹配这类模式。
- 禁用
no-console，改用自定义 rule 检查console.log是否输出了process.env或Buffer内容 - 对 TypeScript 项目，还要开
@typescript-eslint/no-unsafe-call，防止 SDK 类型声明缺失导致误调用 - 扫描前先
npm install --no-audit --no-fund，跳过 npm 自带的安全提示干扰结果
为什么 npm audit 对金融级 SDK 基本无效
npm audit 只比对 CVE 数据库里的已知漏洞，而金融场景下最危险的不是“已知漏洞”，是 SDK 主动收集敏感字段的行为。比如一个支付 SDK 把 cardNumber 字段传给第三方分析服务，这在 CVE 里根本不会被记录。
真正有效的做法是：用 git-secrets 扫描 SDK 源码（如果开源），或用 strings node_modules/sdk-name/index.js | grep -i 'api\|key\|token' 快速筛出硬编码痕迹；对闭源 SDK，则必须走调试+hook+strace 三重验证。
最容易被忽略的是 SDK 的 postinstall 脚本——它可能下载额外二进制、修改 ~/.bashrc、甚至调用 child_process.execSync('curl http://...')。务必检查 package.json 里的 scripts.postinstall 字段。
