<strong>LinkedIn’s approach to code scanning is simple and pragmatic:</strong> integrate <strong>GitHub Actions</strong> for orchestration, use...
How LinkedIn Uses GitHub Actions + CodeQL + Semgrep to Scale Code Scanning
LinkedIn’s approach to code scanning is simple and pragmatic: integrate GitHub Actions for orchestration, use CodeQL for deep semantic analysis, and apply Semgrep for fast pattern checks and custom rules, enabling scalable scanning across millions of lines of code while keeping noise manageable. I’ve seen this combo work in large monorepos in real teams.
Key Takeaways:
- GitHub Actions handles CI orchestration and workflow automation.
- CodeQL provides deep semantic SAST and queryable inventory.
- Semgrep supplies fast, customizable pattern checks and low-friction rule creation.
- Combining tools reduces blind spots and balances speed with depth.
What is LinkedIn’s code scanning approach?
Short answer: automated CI scans at scale.
LinkedIn stitches GitHub Actions, CodeQL, and Semgrep into a layered scanning pipeline, where Actions orchestrates runs, CodeQL finds complex semantic issues, and Semgrep catches idiomatic or policy-rule problems quickly, plus they feed results into a centralized triage flow so engineers can act without drowning in false positives.
Why does that matter?
LinkedIn’s method treats scanning as part of daily craftsmanship rather than as a one-off audit.
I worked on similarly large systems where the worst outcome wasn’t a missed vulnerability but a backlog of ignored alerts that killed trust in tooling—so I appreciate that LinkedIn focuses on meaningful signals, not volume.
Is that practical at scale?
Core Benefits and Importance
Faster feedback, deeper insight, and disciplined follow-up.
When GitHub Actions runs a quick Semgrep job on pull requests and a scheduled CodeQL job for deeper analysis, teams get immediate guidance plus periodic comprehensive sweeps—this reduces developer interruption while maintaining rigorous coverage.
Sounds balanced, right?
Here are the main benefits I’ve observed and used on real projects:
- Immediate PR feedback: Semgrep's low runtime catches common anti-patterns and insecure usage quickly, so developers get actionable fixes during code review.
- Deep semantic detection: CodeQL uncovers flows and logic-level vulnerabilities that pattern matching misses, such as cross-file taint propagation.
- Reduced alert fatigue: Prioritizing findings and tuning rules reduces noise so teams actually fix issues, not just mute alerts.
- Centralized telemetry: Standardizing SARIF inputs and integrating with triage dashboards turns raw findings into metrics that leaders use for stewardship and resource prioritization.
I remember a late-night incident where an injected test case exposed sensitive logic across services, and a scheduled CodeQL run caught it after Semgrep had missed the unique control-flow path; that reinforced for me the dignity of careful, layered work.
Would you rather trust a single tool or a composed pipeline?
Step-by-Step Implementation Guide
Start small, then scale by policy and automation.
I recommend a phased rollout: begin with Semgrep in PRs, add CodeQL scheduled and incremental runs, then tune and bridge results into central triage; I’ve executed this plan across multiple repositories and the trick is incremental policy enforcement, not big-bang change.
Ready to try?
1) Baseline: add Semgrep to PR workflows.
Create a lightweight GitHub Actions job that runs Semgrep on changed files only, set rule severity tags, and block merges only for high-severity matches—this gives rapid wins without disrupting engineers.
2) Introduce CodeQL: scheduled and incremental.
Run CodeQL in a nightly scheduled Action and configure incremental analysis for main branches; this finds complex flow issues and builds an analyzable query corpus for repeatable checks.
3) SARIF normalization and centralization.
Convert results to SARIF, ingest into a single dashboard or GitHub Code Scanning Alerts view, and map results to owner teams so fixes land quickly.
4) Rule hygiene and ownership.
Create a rule-review process and assign Security Champions to own rule sets and triage queues—this keeps the backlog manageable and honors the dignity of the developer’s time.
5) Metrics and policy gating.
Track mean time to remediate, true-positive rate, and scan uptime; then use those metrics to define soft and hard policy gates for environments like production.
Throughout my career, I’ve seen teams that skipped rule ownership end up with orphan alerts and no fixes; conversely, teams with stewardship principles actually improved code quality steadily.
Want the exact workflow templates?
Comparison Table
Short table to compare the combined approach versus a typical single-vendor alternative.
Below is a compact comparison between LinkedIn’s combined strategy (GitHub Actions + CodeQL + Semgrep) and a common competitor approach like Snyk that offers an integrated scanning suite.
| Feature / Measure |
GitHub Actions + CodeQL + Semgrep |
Snyk (typical integrated suite) |
| Orchestration |
GitHub Actions flexible workflows, self-hosted runners supported |
Integrated with GitHub/GitLab, less flexible outside their pipeline |
| Deep semantic analysis |
CodeQL for cross-file taint, logic flows, queryable DB |
SAST heuristics and signatures, good but less queryable |
| Fast pattern checks |
Semgrep for custom rules, quick PR feedback |
Fast SAST/IAST checks available, fewer custom rule primitives |
| Rule customization |
High—write CodeQL queries and Semgrep patterns |
Moderate—custom policies and rule packs, vendor-specific |
| False positive control |
High with layered tuning and ownership |
Variable; vendor tuning helps but can still generate noise |
| Cost model |
OSS tools plus infra cost for Actions/runners |
Paid tiers per developer and scanning volume |
| Scalability |
Proven at monorepo scale, needs engineering ops |
Easy to start, may require more spend at scale |
This table is a practical summary, not an absolute judgment.
In my experience, picking either route depends on resources—if you have strong engineering ops and security engineering, the composed path buys flexibility and transparency; if you want quick uplift with less craft, a vendor like Snyk is reasonable.
Which fits your team?
Common Mistakes to Avoid
Ignore false positives at your peril.
I’ve watched teams bury alerts under labels and then wonder why developers stop caring—if you don’t assign ownership and reduce noise, the scans become wallpaper.
Seems obvious, yet it happens.
Other common errors I’ve seen:
- Over-blocking on day one: Blocking merges for every medium finding without staged enforcement causes friction and workarounds—start with advisory findings and raise enforcement as teams adapt.
- Not normalizing outputs: Different scanners produce different formats; if you don’t unify into SARIF or a single telemetry system, you’ll end up with fragmented queues and missed fixes.
- Rule sprawl and no review cadence: Teams copy rules from public repos and disable them later; institute quarterly rule reviews and require owner sign-off for new entries.
- Skipping infra resilience: Relying on ephemeral runners without capacity planning means flaky scans; balance self-hosted and cloud runners and monitor Action latency.
Frankly, most guides say install a scanner and you’re done, but my experience shows that people fail at the organizational bits—policy, ownership, and remediation workflows—not at the tooling itself.
Want to avoid these traps?
Frequently Asked Questions
Short answers to the most common queries.
I’ll be blunt: these are the questions dev teams ask first, and I’ve answered them based on real deployments and mistakes.
Read on.
Q1: How do you split responsibilities between CodeQL and Semgrep?
CodeQL handles deep semantic, cross-file taint and control-flow analysis while Semgrep catches idiomatic mistakes and enforces style/policy rules quickly on PRs; use Semgrep for fast feedback and CodeQL for nightly deep sweeps.
Q2: Will combining tools increase false positives?
Not if you design staging and tuning—use severity mapping, owners, and SARIF normalization to deduplicate findings and only escalate real risks to blocking status.
Q3: How expensive is running this at LinkedIn scale?
There are infrastructure costs—runner capacity, storage for SARIF, and time for rule maintenance—but using open tools plus organizational discipline often costs less than commercial licenses at massive scale.
Q4: Can this approach integrate with ticketing and bug triage?
Yes—convert SARIF findings into tickets or feed them to triage dashboards and assign to Security Champions so fixes are tracked with the same dignity as any bug fix.
Final Thought
Security tooling is a craft, not a checkbox.
I’ve implemented layered scanning in several organizations and I still prefer a carefully composed pipeline—GitHub Actions for orchestration, CodeQL for semantic rigor, and Semgrep for rapid policy checks—because it respects developer time while protecting users; that mix reflects stewardship of our craft and responsibility toward those who rely on our code.
Ermenildo V Castro