[GHAS CodeQL Series] - Your Complete Guide to Organization-Wide Code Security

[ghostinhershell]

Welcome! This post consolidates our three-part series on implementing GitHub Advanced Security (GHAS) with CodeQL across your organization by @vishaljsoni. Whether you're just getting started or ready to enforce merge blocking, this guide links you to each step in the journey.

---

Part 1: Setting Up Organization-Wide Code Scanning

🔗 [Full post → Setting Up Organization-Wide Code Scanning

This part covers the foundation: enabling GHAS and CodeQL scanning across your organization.

Key topics:

• Prerequisites: Organization owner or security manager role, repository inventory, tech stack assessment
• Phased rollout strategy: Start with pilot repositories to tune alert policies before scaling
• Enabling GHAS: Navigate to Organization Settings → Code security and analysis to enable for all or new repositories
• Configuring code scanning: Set up CodeQL analysis workflows, scanning rules, and severity levels
• Best practices: Avoid enabling on all repos at once; develop a communication and triage plan to prevent alert fatigue

---

Part 2: Implementing Alert-Mode Repository Rulesets

🔗 Full post → Implementing Alert-Mode Repository Rulesets

With scanning in place, this part focuses on configuring repository rulesets in alert mode so CodeQL findings surface as actionable code scanning alerts without yet blocking merges.

Key topics:

• What is alert mode? CodeQL raises alerts that are visible in the Security tab and on pull requests, allowing teams to track, triage, and fix issues
• Creating rulesets: Configure organization-level or repository-level rulesets targeting CodeQL
• PR integration: Ensure scanning runs on pull requests via GitHub Actions so alerts appear in the PR review flow
• Viewing & triaging alerts: Use Security → Code scanning alerts to manage findings
• Best practices: Regularly update CodeQL query packs; use alert mode as a stepping stone before enforcing blocks

---

Part 3: Blocking Vulnerable Code Merges

🔗 Full post → Blocking Vulnerable Code Merges

The final step: moving from visibility to enforcement. This part shows how to block PRs with unresolved CodeQL vulnerabilities from being merged.

Key topics:

• Switching from alert mode to blocking mode: Update your repository rulesets to require CodeQL checks to pass
• Branch protection / rulesets: Configure required status checks so that CodeQL scan results must pass before merge
• Severity thresholds: Define which alert severities (e.g., critical, high) should block merges vs. remain informational
• Handling exceptions: Process for dismissing or resolving alerts when a merge is urgently needed
• Best practices: Communicate enforcement timelines to developers; provide guidance on how to resolve common alert types

---

🚀 Recommended Adoption Path

1. Enable & Scan (Part 1)
   └─ Roll out CodeQL scanning org-wide in a phased approach

2. Alert & Triage (Part 2)
   └─ Surface findings as alerts; build team familiarity with triage workflows

3. Enforce & Block (Part 3)
   └─ Require clean scans before merging to prevent vulnerable code from shipping

---

💬 Questions or Feedback?

Please post questions in the individual discussion threads linked above, or reply here for general series feedback. Happy securing! 🔒

[P-r-e-m-i-u-m]

hay @ghostinhershell This is a really well-structured series — the phased approach (scan → alert → block) is exactly the right way to roll this out without overwhelming dev teams with alert fatigue on day one.
The part about severity thresholds in Part 3 is something a lot of orgs skip past too quickly. Defining what actually blocks vs. stays informational makes a huge difference in developer buy-in.
Thanks for putting this all together in one place, super useful to have as a reference!

[salasrpena]

The phased rollout is helpful. Could the guide include a minimal repository ruleset example showing how to block merges based on CodeQL alert severity?

It would also help to clarify the difference between requiring the CodeQL analysis workflow to complete successfully and requiring its findings to meet a security threshold. A successful scan does not necessarily mean there are no vulnerabilities.

An example covering an existing alert, a newly introduced alert, and a dismissed alert would make the enforcement behavior easier to understand.