最直接方式是用npm audit配合shell脚本批量扫描:遍历含package.json的目录,执行npm audit --audit-level=high --json,再用jq提取高危/严重漏洞数。

使用npm audit配合Shell脚本批量扫描
Linux下最直接的方式是调用 npm audit 命令,它原生支持识别项目中已知的高危/中危漏洞(基于npm官方安全数据库)。对单个项目执行 npm audit --audit-level=high 可只报告 high 及以上等级问题。在 Shell 脚本中遍历多个 npm 项目目录,逐个进入并运行该命令即可实现批量预警。
关键点:
- 确保目标项目已安装依赖(
npm install),否则npm audit无法读取node_modules和package-lock.json - 添加
--json参数可输出结构化 JSON,便于后续解析(如用jq提取漏洞数量、CVE ID、包名等) - 通过
npm audit --production可跳过devDependencies,更贴近生产环境风险面
构建可扩展的扫描脚本框架
写一个 Shell 脚本(例如 scan-npm-vulns.sh),接收项目根目录列表或自动发现子目录中的 package.json:
示例逻辑片段:
#!/bin/bash
PROJECTS=("$@")
[[ ${#PROJECTS[@]} -eq 0 ]] && PROJECTS=(*/)
<p>for dir in "${PROJECTS[@]}"; do
[[ -f "$dir/package.json" ]] || continue
echo "=== Scanning $dir ==="
(cd "$dir" && npm audit --audit-level=high --json 2>/dev/null) | \
jq -r 'select(.vulnerabilities != null) |
"(.path) | (.vulnerabilities.high // 0) high, (.vulnerabilities.critical // 0) critical"'
done</p>
说明:
- 脚本兼容传入路径参数(
./scan-npm-vulns.sh project-a project-b)或自动匹配当前目录下所有含package.json的子目录 - 用
jq提取关键字段,避免人工翻阅冗长文本;若未安装jq,可用grep+awk替代基础统计 - 错误重定向
2>/dev/null屏蔽非致命警告(如 registry 不可达),保持输出干净
集成定时任务与轻量级告警
将脚本加入 cron 实现每日自动扫描,并在发现高危漏洞时触发通知:
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
例如添加到 crontab:
# 每天凌晨2点扫描,结果存日志,有 high/critical 漏洞则发邮件 0 2 * * * /path/to/scan-npm-vulns.sh /opt/projects/ >> /var/log/npm-audit.log 2>&1 && \ grep -q "high\|critical" /var/log/npm-audit.log && \ echo "⚠️ NPM vulnerability alert!" | mail -s "NPM Audit Alert" admin@example.com
进阶建议:
- 用
tee同时输出到控制台和带时间戳的日志文件,方便回溯 - 扫描结果可导出为 CSV 或 Markdown 表格,供团队同步查阅
- 结合
npm audit fix --dry-run --audit-level=high预览可自动修复项,辅助制定升级计划
补充:应对私有Registry与离线环境
若项目使用私有 npm 仓库(如 Nexus、Verdaccio)或需离线扫描,需额外配置:
操作方式:
- 设置
NPM_CONFIG_REGISTRY=https://your-registry.com环境变量,使npm audit查询对应源的安全数据(需该 registry 支持/-/v1/security/audits接口) - 离线场景可搭配 Node.js 安全工作组 提供的
security-advisories数据快照,用自研脚本比对package-lock.json中的版本号 - 对超大规模项目(数百个),建议用
parallel替代 for 循环,提升扫描吞吐(注意 node 进程内存限制)
不复杂但容易忽略










