6.7 SAST、DAST与软件供应链安全

6.7 SAST、DAST 与软件供应链安全

本节摘要：SAST（静态应用安全测试）在代码层找漏洞模式，DAST（动态应用安全测试）对运行中的应用做黑盒探测，两者互补构成自动化安全测试的主力；软件供应链安全则把视野扩展到代码之外的一切依赖——第三方库、构建工具、更新通道，近年最重的几起事件都发生在这里。本节鉴定两类测试的分工与供应链的攻防新格局，是全册最后一篇。承接 6.6 节的 SDL 流水线，本节给流水线装上测试武器，并回答"代码之外还有什么会出事"。

代码之内与代码之外

安全测试要回答的问题其实分两句。第一句："我们自己写的代码有没有漏洞？"——SAST 与 DAST 是这句的主答者。第二句："我们没写的那些代码可信吗？"——现代应用动辄依赖数百个第三方包，这句的答案决定了软件供应链安全为什么突然变得重要。

先把第一句的两位主角鉴定清楚，再处理第二句。

验明正身：SAST 与 DAST

**SAST（静态应用安全测试）**读源码（或字节码）找漏洞模式，不需要运行程序。它的天然主场是开发早期与每次代码提交——速度快、能精确定位到文件与行号、与 CI 流水线是天作之合。它的固有短板：只能找"有代码指纹"的漏洞，业务逻辑漏洞（6.6 节人工审计的主场）看不见；误报率高到需要专人调优规则；跨服务的组合漏洞也超出它的视野。

**DAST（动态应用安全测试）**对着运行中的服务做黑盒探测——发构造的请求、观察响应，像一位不知疲倦的初级渗透测试员。它的主场在测试环境部署之后：验证的是"跑起来的应用"的真实行为，语言与框架无关（它根本不看代码）。短板同样清晰：覆盖依赖入口可发现性（找不到的表单它测不了）、定位模糊（报"这个接口有问题"而不报哪行代码）、对逻辑漏洞同样失明。

两者的互补关系用一张表钉死：

流水线里的标准编排是：提交触发 SAST（分钟级反馈给写代码的人），测试环境部署触发 DAST（发现运行时问题），重大版本叠加人工渗透（3.4 节）。三层过滤后，能漏到生产的已知类漏洞所剩无几——注意"已知类"三个字，逻辑漏洞依然要靠人。

验明正身：软件供应链

软件供应链指从代码到产品的整条生产链：你写的代码、引入的第三方依赖、构建工具链、制品仓库、分发与更新通道。它的安全问题只有一句话就能说清：你的系统强度取决于你最不设防的那个环节，而那个环节往往不归你管。

近年标志性事件的形态值得逐个认识。其一是依赖投毒：攻击者在公共包仓库发布与知名包拼写相近的恶意包（抢注typo名），指望开发者手滑引入；或接管某位原作者长期失修的包名，推一个带后门的"更新"。看一个真实的防御场景：

构建机日志(事后取证还原):
  npm install express  → 正常
  npm install expres   → 命中 typo 包(攻击者预注册的恶意包)
                         安装脚本执行: 回传环境变量与 ~/.ssh 内容
  三周后: 该构建产物中的服务开始向陌生域名外联
教训: 锁定依赖清单(精确版本) + 私有仓库代理白名单 + 依赖完整性校验
​

其二是构建系统入侵：不打产品，打产线——攻入构建服务器，在构建过程注入后门，产物带着官方签名正常分发（签名也没用，因为签名的是被污染的产物）。其三是更新通道劫持：劫持软件的自动更新，让用户"主动"下载恶意版本。

三条形态的共同点：攻击的不是你，是你信任的东西。这与 4.4 节证书体系的逻辑同构——信任链上任何一环失守，下游全数沦陷；也与 2.4 节的 APT 选择题呼应——打终端难了，打供应链这个"一次投毒、全网收货"的杠杆显然更划算。

工程实践要点

依赖清单要"三件套"管理。 锁文件（精确版本，杜绝"顺手升级"）、私有仓库代理（只有白名单里的包能进内网）、依赖完整性校验（安装时核对哈希与签名）。三件套挡住绝大多数投毒路径，成本却只是构建配置里几行设定。

软件物料清单（SBOM）开始成为标配。 给每个产物附一份"成分表"（用了哪些包、什么版本），平时是 6.4 节漏洞管理的底账（新漏洞爆发时秒查"我受不受影响"），出事时是波及面排查的起点。监管与大客户采购正在把 SBOM 变成交付要求。

⚠️ 常见坑：SAST 上线即被误报淹没，三个月后团队学会无视它的报告——工具从此形同虚设。正确启动姿势是先跑影子模式（只报告不卡构建），花两周调规则基线，误报降到团队可消化后再启用拦截。

💡 关键直觉：判断组织的供应链风险，问一个问题就够——"昨天某个常用库爆出恶意版本，你需要多久能确定自己用没用、在哪些产物里？"答案含糊，说明锁文件与 SBOM 的账是糊涂的。

鉴定结论

• SAST 管代码内已知模式、DAST 管运行时真实行为，加上人工渗透构成三层测试，逻辑漏洞始终要靠人；
• 供应链攻击的三形态（依赖投毒、产线入侵、更新劫持）共同点是攻击信任链而非终点；
• 锁文件、私有仓库白名单、完整性校验三件套是投毒的廉价解，SBOM 是波及面排查的底账；
• 全册至此收卷：从 CIA 的三根柱子到供应链的成分表，术语鉴定完毕。术语会老化，鉴定方法不会——把"验明正身、拆机理、看攻防两侧"的习惯带走，比带走任何一份词条都有用。

附卷：一个恶意依赖事件的时间线复盘

把一起依赖投毒事件的公开复盘（细节泛化）改写成时间线，看三道防线各自的表现：

T-2 周: 攻击者接管某失修开源包的发布权, 推出带安装钩子的"修复版本"
T-0:    开发者为了修一个 unrelated 问题, 放宽版本约束重装依赖, 命中投毒版本
T+3 天: 构建产物带着后门进入灰度环境 (SAST 无感——后门不在自研代码里)
T+6 天: 安全研究员在社区披露该包异常, 厂商告警推送到各订阅方
T+6 天+2h: 团队 SBOM 检索确认未发布到生产, 仅灰度; 立即冻结构建并清除
T+1 天: 依赖约束收紧为锁定版本, 私有代理白名单上线, 复盘归档
​

时间线里最刺眼的是 T+3 天那一行：SAST 对这类攻击天然失明，因为它扫描的是"你写的代码"，而恶意藏在"你引用的代码"的安装脚本里。6.7 节正文的三件套（锁文件、私有仓库白名单、完整性校验）对应的正是这个盲区——T-0 的放宽版本约束是事故起点，锁文件本可以在那一行直接拦下。SBOM 在 T+6 天的表现同样值得圈点：从"社区披露"到"确认自己是否中招"只花了两小时，这份底气全部来自成分表的完备。反过来，没有 SBOM 的组织在同一时刻要做的事是"全网人肉排查依赖树"，以天计。

给读者的收尾自测就一句：把本时间线代入自己的团队，T-0 那一行的"放宽约束重装依赖"会不会发生？T+6 天那晚，你需要多久回答"我们中没中招"？两个答案分别对应三件套与 SBOM 的成熟度——全册的最后一个术语，就用这两问收官。

附卷二：私有仓库代理的搭建要点

三件套里工程量最大的是私有仓库代理，五个要点记牢：要点一，全量代理而非白名单散配——所有包管理器（前端、后端、系统级）统一指向代理，绕过代理的直连下载在网络层禁掉，漏一条通道就破一个口。要点二，新包入库有冷静期——新发布的包在代理侧延迟数天才可拉取，投毒包的安装钩子多半活不过冷静期。要点三，哈希锁定——锁文件记录哈希并在安装时强校验，内容不符直接失败。要点四，入库审查留痕——引入新依赖走一个轻量申请（用途、维护活跃度、许可证），记录本身就是将来的波及面底账。要点五，代理自身要高可用——它是所有构建的必经之路，代理挂了等于产线停了，因此它自己也要有备份源与演练。

五要点做完，供应链攻防的"防"就立住了；"攻"侧的持续验证可以交给 6.7 节正文说的对抗演习——红队定期尝试投一个无害的"标记包"进构建，看流程多久抓住。防与验都齐了，这条产线才算看住。