摘要

在拥有数百万行代码和数万个代码仓库的超大规模工程环境中，如何平衡“开发者效率”与“应用安全”是所有科技巨头共同面临的挑战。LinkedIn 近期披露了其SAST能力的现代化改造细节。通过摒弃碎片化的旧系统，LinkedIn 基于 GitHub Actions 构建了一套原生、高韧性且具备“故障熔断”机制的扫描流水线，为企业大规模 DevSecOps 落地提供了一份参考。

背景：规模化带来的安全阵痛

在现代化改造之前，LinkedIn 的 SAST 体系面临着典型的大型企业“技术负债”问题：整个扫描生态是由一系列脱节的系统拼凑而成的。多年来积累的定制扫描器各自为政，导致覆盖范围不一致、维护困难，且难以引入新的检测规则。

随着 LinkedIn 将代码库全面迁移至 GitHub，安全团队决定借此机会重构安全基础设施。经过内部评估，团队选定了 CodeQL 和 Semgrep 作为核心扫描引擎，二者互补性强，且能很好地承接原有的自定义规则。

然而，工具的选择只是第一步，真正的挑战在于如何将这些工具无缝嵌入到数万个仓库的开发工作流中，且不引起开发者的反感。

拒绝“标准路径”：为何选择自定义 GitHub Actions？

GitHub 为 CodeQL 等工具提供了开箱即用的“铺装路径”，即通过预定义的 Action 快速集成。但 LinkedIn 的工程团队发现，标准配置无法满足其复杂的企业级需求：

  1. 构建环境复杂： LinkedIn 拥有独特的构建流程，标准数据库创建步骤无法直接运行。

  2. 数据盲区： 默认配置无法提供足够的观测指标来优化流水线性能。

  3. 定制化受限： 难以实现动态规则过滤、SARIF文件富化以及定制化的修复建议。

因此，LinkedIn 选择了一条更艰难但更灵活的道路：编写自定义的 GitHub Actions Workflow。

SARIF（静态分析结果交换格式）：一种基于JSON定义输出文件格式的 OASIS 标准，为静态分析工具提供统一的结果输出格式，从而解决不同工具在结果表达上的差异性问题，促进工具间的协作和结果集成。

重新设计的流水线架构

新的流水线并未简单调用扫描器，而是设计了精细的阶段控制：

  1. 规则预处理： 动态聚合默认规则与 LinkedIn 自定义规则。系统支持按仓库粒度“因地制宜”地启用或禁用特定规则，减少误报。

  2. 数据库构建： 深度适配内部构建系统。

  3. SARIF 富化： 这是提升开发者体验的关键一步。系统会向原始报警中注入 LinkedIn 特有的上下文和修复模版，让报警不再是冷冰冰的代码行号。

  4. 全链路监控： 对每个阶段的耗时、队列时间、资源分配进行打点，确保安全扫描不会成为 CI/CD 的性能瓶颈。

规模化分发难题：Stub Workflow 与漂移管理

当需要管理数万个仓库时，任何微小的配置变更都可能演变成一场运维灾难。如果将完整的 SAST Workflow 文件直接推送到每个仓库，一旦由于逻辑更新需要修改文件，团队就必须向数万个仓库发起 PR，这显然不可行。

LinkedIn 采用了一种巧妙的 “Stub Workflow” 策略：

  • 中心化逻辑： 真正的扫描逻辑托管在一个中心化的仓库中。

  • 分布式触发： 在每个业务仓库中，仅放置一个极简的 Stub 文件（仅几行代码）。该文件的唯一作用是调用中心化的 Reusable Workflow。

name: SecurityScan
on:
pull_request:
types:[opened,synchronize]
schedule:
-cron:"34 3 * * 4"# randomized to spread out the load
env:
VERSION:"1.0.0"
LAST_UPDATED:"2025-10-22"
permissions:
actions:read
contents:read
security-events:write
pull-requests:read
jobs:
sast-scan:
uses:static-analysis-actions/.github/workflows/sast-scan.yaml@production

这种设计使得安全团队只需更新中心仓库的逻辑，所有下游仓库即可即时生效，实现了一次修改，处处处同步”。

漂移管理系统 (DMS)

为了防止 Stub 文件被意外删除或修改，LinkedIn 开发了 **漂移管理系统 (Drift Management System，DMS)**。该系统每日巡检所有仓库：

  • 如果 Stub 文件缺失或版本不一致，DMS 会自动提交代码进行修复。

  • 同时，DMS 接入了仓库创建流程，确保新诞生的仓库在第一天就具备安全扫描能力。

阻断与韧性：在安全与速度间走钢丝

为了贯彻“左移”策略，LinkedIn 实施了 Blocking Mode（阻断模式）。利用 GitHub 的 Repository Ruleset 功能，系统强制要求 PR 合并前必须满足两个条件：

  1. 必须上传了 SARIF 扫描报告。

  2. 报告中不得包含超过风险阈值的漏洞。

创新的“故障安全”机制

在数万次扫描中，基础设施故障在所难免（如 GitHub API 超时、扫描器崩溃）。如果因为工具本身的故障导致开发者无法合并代码，将是对“开发者优先”原则的背叛。

为此，LinkedIn 设计了一套优雅的故障熔断机制：

  • 故障放行： 如果扫描流水线在任何阶段发生不可恢复的错误（非代码漏洞，而是系统错误），系统会自动上传一份空的 SARIF 文件。

  • 效果： 这使得 GitHub 的合并检查能够通过，开发者不会被工具故障阻塞。

  • 事后补救： 故障事件会被记录并触发给 On-call 工程师进行后续分析。

此外，他们还实现了多级熔断开关，允许安全团队按组织、仓库、语言甚至特定规则粒度一键关闭扫描，以应对突发的大规模误报或系统故障。

小结

LinkedIn 的 SAST 现代化改造案例向业界展示了企业级安全建设的重要经验：工具的堆砌不是能力，工程化的整合才是关键。

参考链接

Modernizing LinkedIn’s Static Application Security Testing Capabilities to protect our members： https://www.linkedin.com/blog/engineering/security/modernizing-linkedins-static-application-security-testing-capabilities

声明：本文来自玄月调查小组，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。