Serverless 依赖供应链安全实践

Serverless 最容易让人产生一种错觉：既然不用管理服务器，依赖供应链安全也就轻松了。我的感受恰恰相反。主机和操作系统交给云厂商之后，风险并没有消失，而是集中到了函数代码、第三方依赖、构建过程、事件源权限和部署版本上。函数短暂、分散、数量多，出了问题往往比一台长期运行的服务更难追踪。

先管清楚“函数里有什么”

依赖供应链安全的第一步，不是急着买工具，而是知道每个函数到底带了哪些东西。函数依赖库、构建产物和配置都应纳入清单追踪，软件物料清单（SBOM）可以帮助团队明确部署单元中的组件构成。对于来自公共仓库的依赖，要关注依赖混淆和恶意包注入风险；对于长期未使用的函数版本，也应及时清理，减少遗留入口。

签名验证同样不能只用于容器镜像。函数包和部署产物也需要确认来源与完整性，避免构建阶段被植入内容后一路进入生产环境。Serverless 的问题在于，运行环境由平台托管，传统基于代理的检测很难直接嵌入函数，因此更应该把检查前移到函数构建阶段，在发布前识别危险调用和异常依赖。

把权限和发布流程连起来

我认为，函数供应链安全最容易被忽略的环节，是依赖风险与权限风险叠加。一个本身看似普通的恶意包，如果所在函数拥有过大的访问权限，影响范围就会被迅速放大。因此，函数应坚持最小权限原则：只授予完成任务所需的访问能力，尤其要重新检查环境变量、存储访问和事件源许可策略。

安全检查不能停在一次扫描。CI/CD 管道中可以同时纳入函数依赖检查、产物签名验证和策略即代码，让不符合基线的构建无法继续发布。部署后还要保留函数调用链、日志和指标，便于把异常调用与具体版本对应起来。

Serverless 依赖治理的核心，不是证明“平台替我们负责了安全”，而是建立一条可追溯的链：依赖从哪里来，经过什么构建，拥有何种权限，最终被哪个事件触发。链条越清楚，供应链风险才越不容易变成事后才看见的问题。