升级至指定版本后仍遭Amazon Inspector报xlsx漏洞，原因何在？

可能原因及排查步骤 #

• 扫描工具版本识别逻辑缺陷
  多数漏洞扫描工具依赖解析package-lock.json或node_modules/xlsx/package.json里的版本号判断风险，但你采用直接引用tgz包的方式，部分工具可能无法正确识别包的实际版本，进而误判为旧版本。手动检查node_modules/xlsx/package.json的version字段，确认是否为0.19.3，如果是，大概率是工具的识别bug。
• 间接依赖引入旧版xlsx
  项目中可能存在其他依赖间接拉取了旧版本的xlsx，即便你直接安装了0.19.3，node_modules里也可能存在多版本实例。运行npm ls xlsx或yarn list xlsx查看完整依赖树，若发现旧版本，可通过yarn的resolutions或npm的overrides配置，强制所有依赖统一使用0.19.3版本。
• ECR镜像缓存残留
  构建镜像时可能复用了旧缓存层，导致镜像内的xlsx版本并非预期的0.19.3。尝试用docker build --no-cache清理缓存后重新构建镜像，再进行扫描验证。
• 漏洞数据库误报或滞后
  部分漏洞数据库未及时更新，或错误将已修复的漏洞关联到0.19.3版本。可前往对应漏洞的CVE详情页面，确认其影响版本范围，查看0.19.3是否真的在修复范围内。

验证方法 #

1. 进入容器内部，执行npm show xlsx version或直接查看node_modules/xlsx/package.json确认实际版本。
2. 在本地项目中运行npm audit扫描，若本地扫描无此漏洞，基本可确定是ECR扫描工具的问题。
3. 尝试将依赖改为标准版本号形式"xlsx": "0.19.3"，重新构建镜像后再扫描，验证是否为tgz链接导致的识别异常。

内容的提问来源于stack exchange，提问作者user68288