01 · 函数供应链全景
OWASP Serverless Top 10将"不安全的第三方依赖"（SAS-06）与"密钥存储不当"（SAS-07）均归入代码与依赖域。函数的单体依赖量虽小于传统应用，但函数数量庞大、制品形态多样（代码包、Layer、容器镜像）、部署频率极高，供应链的"单位风险密度"反而更高。函数供应链应按下述六环节逐一建立控制点：
| 环节 | 典型风险 | 控制点 |
|---|---|---|
| 源代码 | 密钥硬编码、危险函数、不安全反序列化 | 代码评审清单；Semgrep类静态规则；git-secrets/gitleaks提交扫描 |
| 第三方依赖 | 存在漏洞的组件、恶意包投毒、依赖混淆 | lockfile强制提交；私有仓库（如AWS CodeArtifact）；依赖扫描门禁 |
| 打包制品 | zip包含.dev凭证与测试数据；Layer来源不可信；镜像基础层漏洞 | 构建清单白名单；Layer仅可信来源；镜像固定digest+扫描 |
| IaC与部署 | 模板硬编码密钥、默认角色过宽、环境漂移、长期AK | checkov/tfsec扫描；OIDC联邦部署；策略即代码门禁 |
| 发布与签名 | 未签名制品被篡改、未授权部署 | AWS Signer代码签名（官方支持）；发布审批与环境隔离 |
| 事件源绑定 | 触发器在管道外被手工增改（持久化通道） | 事件源映射纳入IaC与变更审计；漂移检测 |
02 · 依赖与包治理
- lockfile是信任根：npm/package-lock.json、pip/requirements.txt（带哈希）、go.sum等必须提交入库；CI以lockfile为准安装，杜绝构建时浮动解析。依赖混淆与仿冒包的主要入口正是"构建时按名取最新版本"。
- 私有仓库隔离：AWS CodeArtifact、Azure Artifacts、私有npm/PyPI源将公网包代理与内部包命名空间隔离；内部包以作用域（scope）前缀独占，防止攻击者注册同名公网包。
- 扫描门禁：Dependabot/npm audit（JS）、pip-audit/safety（Python）、GitHub Advisory/OSV情报源比对；镜像与文件系统层面可用Trivy/Grype兜底。
- 真实投毒事件的警示：event-stream（2018年，比特币钱包相关包投毒）、ua-parser-js（2021年，窃取凭据与加密货币）、colors/faker维护者事件（2022年）均波及Node函数常见依赖——函数场景无人工运维环节，投毒包的执行几乎无人目击，门禁与私有源不可省略。
03 · 打包制品安全：zip、Layer与镜像函数
3.1 代码包（zip）基线
- 构建清单白名单：仅打包运行时所需文件，排除.env、测试夹具、本地密钥与CI临时文件；构建后列出包内清单并比对预期。
- 制品可追溯：构建号、代码commit哈希、依赖锁版本写入制品元数据；发布记录保留180天以上。
3.2 Layer（层）专项
- Layer版本发布后不可变（AWS官方文档），这为回滚与审计提供了天然锚点——所有Layer变更以新版本发布，禁止就地修改。
- 第三方Layer风险：Layer代码在函数执行权限下运行任意逻辑；仅使用组织自建或官方来源Layer；引入新Layer须经代码级审查。
3.3 容器镜像函数（2020年12月起支持）
- 基础镜像限定官方镜像或经内部评审的等效镜像（Lambda对镜像函数的基础镜像有官方兼容性要求，见官方文档）；以digest固定版本，禁用latest类浮动标签。
- 镜像入仓后触发扫描（ECR增强扫描/Inspector），高危漏洞未修复不得发布；签名验证（cosign/sigstore）嵌入CI，验证失败阻断部署（Lambda无运行时准入钩子，验证责任在流水线）。
- 镜像函数把容器供应链问题完整引入函数域——主课题子课题03的SBOM/SLSA/sigstore方法论直接适用，不再重复展开。
04 · IaC与部署管道安全
主流函数以基础设施即代码部署：AWS SAM、Serverless Framework、Terraform、Pulumi，国内阿里云Serverless Devs、腾讯云SCF CLI。IaC把"配置错误"变成了"可批量复制配置错误"，其安全要求：
| 控制项 | 要求 | 工具/依据 |
|---|---|---|
| 模板静态扫描 | 每次合并前扫描公开面、宽权限、未加密资源、明文密钥 | checkov、tfsec（开源，规则覆盖AWS/Azure/GCP） |
| 部署身份 | CI以OIDC联邦短期凭证部署，禁止长期AK入库 | GitHub Actions OIDC→AssumeRoleWithWebIdentity（官方文档） |
| 分支与环境隔离 | 分支保护+CODEOWNERS；dev/stg/prod分账号或分角色部署，生产部署需审批 | GitHub分支保护；AWS Organizations多账户 |
| 漂移治理 | 控制台手工变更与IaC状态定期比对；事件源映射纳管 | Terraform plan漂移检测；AWS Config规则 |
| Git历史治理 | 密钥提交即视为泄露：吊销+轮换+历史清理 | git-secrets/gitleaks提交拦截；GitHub secret scanning推送保护 |
05 · 代码签名、SBOM与Log4Shell案例
5.1 函数代码签名
AWS Lambda支持代码签名（AWS Signer，官方功能）：为函数配置签名配置文件后，平台在发布（PublishVersion/部署）时验证部署包签名，未签名或签名者不被信任的版本将被拒绝。这把"谁允许往生产函数写代码"从账户级细化为签名者级——配合OIDC部署身份，可构成"CI签名→平台验签"的完整信任链。注意：代码签名验证的是部署时刻的完整性，运行时依赖漏洞仍需扫描兜底。
5.2 SBOM对函数依然必要
函数依赖少而分散，恰是SBOM易落地场景：构建时以Syft生成CycloneDX/SPDX格式清单，归档至制品库；应急场景（如Log4Shell）按SBOM分钟级定位受影响函数。SBOM格式与消费方法继承主课题子课题03（SPDX为ISO/IEC 5962:2021、CycloneDX为OWASP项目）。
5.3 函数制品SBOM最小字段集（课题建议）
| 字段 | 说明 |
|---|---|
| 组件名与版本 | 精确到semver（含Layer与镜像基础层组件），版本号不得含浮动范围符 |
| 来源与哈希 | 制品来源仓库地址与commit哈希；包级哈希（如npm的integrity）用于比对复现 |
| 依赖层级 | 直接依赖与传递依赖分层标注——投毒与漏洞定位均依赖层级信息 |
| 构建环境 | 构建镜像digest与CI运行ID，支撑"同代码同产物"复现验证 |
| 许可证 | 逐组件许可证标识，满足合规审计与商用准入检查 |
| 时间戳与签名 | SBOM生成时间与生成工具（Syft等）版本；SBOM本身随制品签名一并归档 |
5.4 Log4Shell（CVE-2021-44228）的两层责任实证
| 层级 | 处置主体 | 依据 |
|---|---|---|
| 托管Java运行时 | AWS完成修复并向存量函数热修补（官方博客，2021年12月） | 平台责任面 |
| 函数打包自带依赖（fat-jar内log4j-core） | 客户自行升级依赖并重新部署——官方明确该层责任在客户 | 客户责任面（本课题范围） |
供应链治理的本质判断：函数越小，依赖越隐含（打包进zip/jar后不可见）。没有SBOM与锁版本的组织，在Log4Shell级事件中只能全量人工排查——这正是供应链控制点（第01节表）必须逐环节落实的根本原因。
本节参考来源（第6页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
OWASP Serverless Top 10（SAS-06第三方依赖、SAS-07密钥存储）：owasp.org/www-project-serverless-top-ten。
GitHub Docs：在AWS中配置OpenID Connect（CI/CD联邦凭证）：Configuring OpenID Connect in AWS。
AWS Lambda官方文档：Layer（版本不可变性与使用约束）、容器镜像函数：Lambda layers；Creating Lambda container images。
AWS官方文档：Lambda代码签名（AWS Signer）：Configuring code signing。
AWS CodeArtifact：aws.amazon.com/codeartifact；GitHub secret scanning：About secret scanning。
checkov：checkov.io；tfsec：aquasecurity.github.io/tfsec；Trivy：trivy.dev；Syft：github.com/anchore/syft；cosign：github.com/sigstore/cosign。
AWS Security Blog：Log4Shell期间Lambda函数的处置说明（托管运行时修复与热修补层，2021年12月）：AWS Security Blog。
NVD官方条目 CVE-2021-44228：nvd.nist.gov/vuln/detail/CVE-2021-44228。