LinkedIn has redesigned its static application security testing pipeline (SAST) to provide consistent, enforceable code scanning across a GitHub-based, multi-repository development environment. The initiative was a result of the company’s shift-left strategy by delivering fast, reliable, and actionable security feedback directly in pull requests, strengthening the security of LinkedIn’s code and infrastructure and helping protect members and customers.
At a high level, SAST analyzes source code to identify potential vulnerabilities early in the development lifecycle. At LinkedIn’s scale, legacy approaches that relied on multiple disconnected scanners and custom integrations resulted in uneven coverage, limited visibility into pipeline health, and friction for developers. The redesign aimed to standardize scanning, simplify adoption, and more deeply embed security into developer workflows without introducing bottlenecks.
At the start of the redesign, LinkedIn engineers established key guiding principles, prioritizing developer-first security to minimize workflow interruptions, extensibility to allow other teams to add rules or integrations, resilience to prevent failures from affecting developers, and observability to monitor coverage and performance at scale.
The new architecture leverages GitHub Actions to orchestrate two primary scanning engines, CodeQL and Semgrep, chosen for their complementary coverage and extensibility. LinkedIn engineers implemented custom workflows to manage rule execution, orchestrate scanning, and process results. Findings are normalized using the SARIF standard and enriched with metadata to provide clear remediation guidance and actionable context for both developers and security teams.
High-level overview of GitHub Actions workflow using CodeQL (Source: LinkedIn Blog Post)
LinkedIn engineers initially aimed to use GitHub Required Workflows to enforce pipeline execution and schedule scans across tens of thousands of repositories, but the feature does not support scheduling or automatic deployment. Consequently, workflow files had to be pushed into each repository to propagate changes reliably, creating scale challenges.
To solve this, LinkedIn implemented a lightweight “stub workflow” in every repository that delegates execution to a centrally maintained workflow. This design allows updates to scanning logic, enforcement policies, and observability instrumentation to propagate instantly without modifying individual repositories. A Drift Management System continuously verifies the stub’s presence and configuration, while new repositories are automatically provisioned with it. The combined approach ensures consistent coverage and enforcement across LinkedIn’s multi-repository environment, maintaining reliability and developer workflow efficiency at scale.
Enforcement is handled through GitHub repository rulesets that block pull request merges until static analysis completes and vulnerabilities remain within acceptable risk thresholds. To prevent developer workflows from being disrupted during scanner outages or infrastructure failures, LinkedIn built multiple safety mechanisms, including kill switches and automated fallback behavior. In failure scenarios, empty SARIF reports are injected to unblock merges while still capturing telemetry for post-incident analysis.
Blocking mode process (Source: LinkedIn Blog Post)
As emphasized by LinkedIn Engineers:
We moved from a fragmented ecosystem to a unified, GitHub-native security pipeline that provides consistent coverage and actionable feedback without slowing developers down.
The SAST pipeline collects detailed execution metrics, failure reports, and adoption statistics, enabling security teams to monitor coverage, reliability, and organizational impact. LinkedIn notes that SAST is only one component of a broader application security strategy, which also includes dependency scanning and secret detection, forming an integrated approach to protecting both code and infrastructure.
