一、为什么SAST单干看不清外部问题？

SAST（静态应用安全测试）是扫你自己写的代码，就像你自己开咖啡店，只检查自己做咖啡的操作有没有卫生问题，比如有没有用脏手、有没有给咖啡杯消毒。但你用的咖啡粉、奶精、杯子都是别人提供的第三方货，这些货里有坏东西（比如过期咖啡粉），SAST根本看不到，因为它不碰别人写的代码。比如你是做外卖平台的开发者，自己写了处理用户地址的代码，SAST检查这段代码，发现没有硬编码的地址或者泄露，完全没问题。但你用了一个第三方的地址解析包，这个包的旧版本有漏洞，攻击者传一个恶意地址时，这个漏洞就会被触发，导致用户地址泄露。这就是SAST的盲区——它只守自己的一亩三分地，不管外人的坑。

1.1 SAST的“看不见”到底是什么

SAST的核心是分析你提交的代码文本，识别你自己写的逻辑里的安全问题，比如有没有SQL注入的可能、有没有硬编码密钥。它的规则是针对“你写的代码”设计的，不会去扫描node_modules（前端依赖文件夹）或者Maven仓库里的第三方代码。哪怕你代码里调用了别人的包，SAST也只会检查你调用这个包的语法对不对，不会查这个包本身有没有漏洞。

二、SCA能补上SAST的哪些缺口？

SCA（软件成分分析）是专门找第三方组件问题的，相当于你给咖啡店的每一件进货都做质检，不管是直接买的咖啡粉，还是咖啡粉用的豆子——哪怕是层层嵌套的间接依赖，它都能查出来。比如你用lodash这个包，lodash自己又依赖了isObject之类的子包，SCA会把整个依赖关系拆成一棵树，把每个节点的包、版本、所有已知漏洞列出来。

2.1 SCA的“超能力”——扒光所有外来者的问题

SCA的工具（比如npm audit、Snyk、Dependabot）会扫描项目的依赖配置文件（package.json、pom.xml），拉取对应仓库里的漏洞库，对比每个依赖的版本，告诉你哪个包、哪个版本有什么漏洞，比如原型污染、密钥泄露。但它有个缺点：只告诉你“有漏洞”，不告诉你“你的代码里哪里用到了这个有漏洞的包”，就像你知道咖啡粉过期了，但不知道店员哪天用了这个过期粉做咖啡，你还是没法精准解决问题。

2.2 联动的核心：把“自家调用路径”和“外部依赖树”捏一起

要补这个缺点，就得把SAST和SCA的结果合并：SAST告诉你自己的代码里哪个函数调用了某个第三方函数，SCA告诉你这个第三方包的某个版本有漏洞，把这两个信息拼起来，就能精准定位到“你的代码第X行调用了有漏洞的第三方函数”，相当于你不仅知道咖啡粉过期，还知道上周三的拿铁用了这个过期粉，马上就能改。

三、用JavaScript示例讲清合并逻辑

我们用JavaScript来做示例，技术栈明确标注：技术栈为 JavaScript。先准备一个简单的有漏洞的项目，再看SAST、SCA、联动扫描的不同结果，最后讲合并的方法。

3.1 准备带漏洞的项目

第一步，初始化项目，安装有漏洞的lodash包（4.17.20版本有原型污染漏洞）：

mkdir demo-sast-sca && cd demo-sast-sca
npm init -y
npm install lodash@4.17.20

第二步，写业务代码（app.js），这里只做一个简单的权限查询，调用lodash的get方法：

// 功能：根据权限路径，获取用户的对应权限
// 用lodash.get安全提取嵌套对象属性，避免直接用[]可能带来的安全问题
function getUserPermission(user, permissionPath) {
  // 调用lodash.get，示例中如果传入特殊路径，会触发lodash旧版本的漏洞
  return _.get(user, permissionPath);
}

// 测试数据：模拟带权限的用户信息
const testUser = {
  id: 1001,
  username: "zhangsan",
  permissions: {
    "order.create": true,
    "order.delete": false,
    "payment.view": true
  }
};

// 正常调用，应该返回true
console.log(getUserPermission(testUser, "permissions.order.create"));

第三步，项目的依赖配置文件package.json，这里明确写了lodash的旧版本：

{
  "name": "demo-sast-sca",
  "version": "1.0.0",
  "description": "SAST+SCA联动示例项目",
  "dependencies": {
    "lodash": "4.17.20"
  }
}

3.2 分开看SAST和SCA的结果

先测SAST，用ESLint的安全插件扫描，命令：

npx eslint app.js --plugin security --rule "security/detect-object-injection: error"

结果显示：app.js没有代码级别的安全问题，SAST完全没发现漏洞——因为漏洞在lodash包里，不在你自己写的app.js里。

再测SCA，用npm audit命令：

npm audit

结果会高亮显示：lodash@4.17.20存在原型污染漏洞，攻击者可以构造特殊路径修改对象原型，但完全没提你的app.js里哪里用到了这个lodash，也没法告诉你这个漏洞会不会被你自己的代码触发。

3.3 合并依赖树和调用路径的具体方法

现在用Snyk这个联动工具，它会同时跑SAST和SCA，把两个结果合并成一份清晰的报告： 第一步，安装Snyk CLI：

npm install -g snyk
snyk auth # 用GitHub账号登录，或者用API密钥登录

第二步，跑联动扫描命令：

snyk code test --sarif-output saast-result.sarif && snyk test --sarif-output sca-result.sarif

第三步，看合并后的结果：打开saast-sca的合并报告，会明确显示：在app.js的第7行（就是调用_.get的那一行），你的代码调用了lodash@4.17.20的get方法，而这个方法存在原型污染漏洞，路径是：你的app.js第7行 → lodash的get函数 → lodash包本身，这就是把SAST的调用路径和SCA的依赖树合并后的结果。你不用再猜哪里有问题，直接找到对应行，要么升级lodash，要么换安全的方法实现功能就行。

四、联动方案的实际应用、优劣和坑点

4.1 核心应用场景

最典型的场景是电商和用户中心的支付、登录模块：比如你用第三方的JWT验证包，SAST查自己的JWT生成代码没问题，但SCA发现这个包有密钥泄露漏洞，联动扫描后会告诉你你的user.js第15行调用了这个包的decode方法，马上就能修复。还有社交平台的用户头像上传模块，用了第三方的图片处理包，联动后能发现这个包的文件解析漏洞，避免用户上传恶意图片导致服务器被入侵。

4.2 技术优缺点

优点：1. 补全SAST的盲区，把检查范围从自己的代码扩大到整个依赖链；2. 精准定位漏洞的代码位置，不用盲找；3. 覆盖嵌套依赖，比如你用的包自己又依赖了10个小分包，联动会把所有的路径都串起来，不会漏掉间接依赖的漏洞。 缺点：1. 依赖树复杂的时候，合并调用路径会消耗更多的计算资源，大项目可能要等几分钟；2. 不同工具的输出格式不统一，需要做格式转换，比如Snyk和CodeQL的SARIF格式，要写脚本合并；3. 漏洞库更新不及时，可能会漏报新出的漏洞，或者误报过时的漏洞。

4.3 必须注意的坑

  1. 别把测试依赖算进来：比如你用了Jest做测试，测试依赖里的包有漏洞，联动扫描会把这个也列出来，容易混淆，扫描的时候要过滤掉devDependencies；2. 验证合并结果：有些SCA的漏洞是理论上的，你自己的代码根本不会调用，所以要手动用概念验证代码测一下，确认漏洞真的会被你的代码触发；3. 定期更新工具：Snyk、npm audit的漏洞库每月更新一次，工具版本太旧的话，扫不出新漏洞。

五、总结

SAST和SCA的联动是现代代码安全的必做项，之前很多开发者只做SAST，导致第三方组件的漏洞偷偷藏在生产环境里。合并依赖树和调用路径是让这个联动从“知道有漏洞”变成“知道哪里有漏洞”的关键——它把你自己的代码和所有外部包的关系串成了一条清晰的线，再也不用对着SCA的报告迷茫“这个漏洞在哪里才会触发”。不管你是前端还是后端开发者，只要用到第三方包，学会用联动的方式扫安全，就能避开很多因为组件漏洞导致的线上故障。