Skip to content

07 · 供应链与依赖安全 ​

现代应用的代码里第三方依赖占比越来越高,"你用的依赖就是你的代码"。本篇讲SCA 扫描、锁文件、来源信任与漏洞响应,把供应链安全变成可重复的流程。

速览卡 ​

项内容
一句话定位依赖来源、版本锁定、漏洞发现与响应的闭环
核心内容风险面、锁文件、SCA/CI、漏洞响应、来源信任
读完能回答npm audit 报高危怎么处理?依赖被投毒怎么办?
相关板块C16 服务端安全纵深 | D02 CICD | S06 运维安全

一、先给结论:供应链安全是四个动作 ​

text
① 锁:锁文件 + 可复现构建
② 扫:SCA 进 CI,阻止高危合入
③ 信:只信可信源,校验发布物
④ 应:漏洞来了有升级/缓解流程

一句话:供应链攻击的目标是"让合法依赖替你干活",所以核心是"别什么都装、装上要锁、锁了要扫、扫了要处理"。


二、风险面:依赖能怎么伤你 ​

风险例子
已知漏洞老版本 lib 有公开 CVE
恶意投毒同名包、伪装包带后门
上游被攻破维护者账号被盗,发布恶意版
依赖链污染间接依赖被替换(如 PyPI 重名抢注)
许可证风险用了禁止商用/传染性许可

关键认知:不只是直接依赖,间接依赖(传递依赖) 才是多数供应链事故的藏身处。


三、锁文件:可复现构建的基石 ​

工具锁文件
npm/pnpmpackage-lock.json / pnpm-lock.yaml
piprequirements.txt + 哈希 / poetry.lock
Gogo.sum
Java/Maven版本固化 + 仓库镜像校验

锁文件必须入库:它保证"CI 和本地构建出一模一样的依赖树",是扫描与审计的前提。


四、SCA:把扫描嵌进 CI ​

text
提交 → CI 依赖扫描 → 高危阻断 → 否则放行
工具场景
npm audit / pip-audit快速本地/CI 扫描
Dependabot / Renovate依赖升级 PR 自动化
Snyk / 商业 SCA完整漏洞库 + 许可证治理
SBOM 生成记录依赖清单,便于追溯

扫描的难点是噪音:天天报"有 CVE"却不升级,等于没扫。关键是把"高危且可达"作为阻断条件,让告警可行动。


五、漏洞响应:从告警到修复 ​

步骤动作
评估看 CVE 是否影响当前用法(可达性)
升级升到修复版本,跑回归测试
缓解升不了时加防护(如拦截、降权)
通报影响外部时同步用户与合规
复盘更新依赖策略,防止同类再漏

别一告警就慌:先问"这个 CVE 在我这可达吗"。远程可利用 + 影响业务路径才是一级响应。


六、来源信任:装包前的纪律 ​

检查说明
包名拼写警惕官方包的"相似名"(typosquatting)
下载量/维护度新包大下载量突然出现要警惕
发布者校验校验哈希/签名,优先官方源
最小安装别用一行命令装"全家桶"
私有仓库企业内统一代理源 + 白名单

与 C16 的分工:C16 讲依赖风险在服务端纵深里的位置,本篇把"发现与响应流程"做完整。


七、自检清单 ​

  • [ ] 所有项目有锁文件且已入库
  • [ ] CI 里跑了依赖扫描,高危会阻断合入
  • [ ] 知道每个直接依赖是干什么的,无"来源不明"的包
  • [ ] 有漏洞响应流程:评估→升级→缓解→通报
  • [ ] 依赖升级有测试覆盖,不是盲升

八、常见误区 ​

误区事实
"只查直接依赖"传递依赖才是多数漏洞藏身处
"锁文件不用入库"不入库就无法复现,也无法审计
"扫描报漏就必须全升"要先评估可达性,避免为修而修
"版本越新越安全"新版可能引入破坏或新问题,要验证

九、动手练习 ​

练习 A:做一次依赖体检 ​

给当前项目跑一次 npm audit(或等价工具),列出高危项,判断哪些可达、哪些只是间接依赖。

练习 B:配 Dependabot ​

给一个仓库开启依赖更新 PR,体验一次"自动升级 + 跑 CI"的闭环。

练习 C:写响应手册 ​

给团队写一份"依赖漏洞告警后 1 小时内做什么"的流程,覆盖评估、升级、缓解、通报四步。


相关文档 ​

本区 ​

其他域 ​