LinkedIn重新设计了其静态应用安全测试（static application security testing，SAST）流水线，以便在基于 GitHub 的多仓库开发环境中提供统一、可强制执行的代码扫描能力。该举措源于公司的安全左移（shift-left）战略，也就是通过在 Pull Request 中直接提供快速、可靠且可落地的安全反馈，增强 LinkedIn 代码与基础设施的安全性，帮助保护用户与客户。
从宏观层面来看，SAST指的就是通过分析源代码，在开发生命周期早期识别潜在的漏洞。在 LinkedIn 的规模下，传统方案依赖多个相互独立的扫描器与定制化集成，导致覆盖度不均、流水线健康状况可见性有限，并给开发者带来额外的负担。此次重新设计旨在标准化扫描能力、简化接入流程，并将安全更深度地嵌入开发者工作流，同时避免引入性能瓶颈。
在设计初期，LinkedIn 工程师确立了核心指导原则，那就是优先以开发者为中心的安全设计，最小化对工作流的干扰；具备可扩展性，允许其他团队添加规则或集成；具备高韧性，避免故障影响开发者；具备可观测性，能够在大规模场景下监控覆盖范围与性能表现。
新架构基于GitHub Actions进行编排，并整合了两款核心扫描引擎CodeQL与Semgrep，选择它们是因为二者覆盖范围互补且易于扩展。LinkedIn 工程师实现了自定义工作流，用于管理规则执行、编排扫描流程并处理扫描结果。所有漏洞发现结果均基于SARIF标准进行规范化，并补充元数据，为开发者与安全团队提供清晰的修复指引与可落地的上下文信息。
使用 CodeQL 的 GitHub Actions 工作流的宏观概览 (图片来源：LinkedIn博客文章)
LinkedIn 工程师最初希望使用 GitHub Required Workflows 来强制执行安全流水线，并在数万个仓库中实现定时扫描，但该功能不支持定时任务与自动部署。因此，工作流文件必须被推送到每个仓库才能可靠地传播变更，这在大规模场景下会带来一定的挑战。
为了解决该问题，LinkedIn 在每个仓库中部署了轻量级的桩工作流（stub workflow），将实际执行委托给集中维护的中心工作流。这种设计使得扫描逻辑、强制策略与可观测性埋点的更新能够即时生效，无需修改单个仓库。同时，还有一套漂移管理系统（Drift Management System） 持续校验桩工作流的存在与否与配置情况，新仓库也会自动预置该文件。这套组合方案确保了 LinkedIn 多仓库环境下的统一覆盖与强制执行，在大规模场景下保持可靠性与开发者工作流效率。
强制机制通过GitHub仓库规则集（repository rulesets）来实现，也就是阻塞 Pull Request 合并，直到静态分析完成且漏洞处于可接受的风险阈值内。为避免扫描器故障或基础设施异常中断开发者流程，LinkedIn 构建了多重安全机制，包括紧急停止开关（kill switches）与自动降级策略。在故障场景下，系统会注入空 SARIF 报告以解除阻塞的合并请求，同时仍会采集遥测数据用于事后分析。
阻塞模型的流程（图片来源：LinkedIn博客文章)
正如 LinkedIn 的工程师所强调的：
我们从碎片化的生态系统，转向了一套统一、原生基于 GitHub 的安全流水线，在不拖慢开发者速度的前提下，提供一致的覆盖度与可落地的安全反馈。
该 SAST 流水线会收集详细的执行指标、故障报告与接入统计数据，使安全团队能够监控覆盖范围、可靠性与组织级影响。LinkedIn 指出，SAST 只是整体应用安全战略的一部分，该战略还包括依赖项扫描与密钥检测，共同构成一套覆盖代码与基础设施的一体化安全防护体系。
原文链接：
LinkedIn Leverages GitHub Actions, CodeQL, and Semgrep for Code Scanning
