GitHub Security MCP: 39 tools, 45 checks, full posture audit

A GitHub organization’s security posture isn’t one setting — it’s org-level 2FA and SSO, per-repo branch protection, the YAML in every Actions workflow, secret scanning coverage, dependency health, and who has access to what. No single dashboard shows all of it, so an audit means clicking through settings pages, grepping workflow files, and pulling API data into a spreadsheet. Hours per org.

github-security-mcp runs that audit for an agent instead. It gives 39 tools and 45 security checks across 6 categories over the Model Context Protocol — the agent calls GitHub’s APIs directly, grades org settings, repo configs, workflows, secrets, supply chain, and access control, and hands back a prioritized list of what to fix. It’s on npm under MIT (v0.1.0), and it does not require GitHub Enterprise: Enterprise-only checks return NOT_APPLICABLE rather than failing, so the audit still completes on a Free or Team plan.

What it checks

Six categories, 45 checks, each returning the same shape — { checkId, severity, status, details, remediation } — so the agent can aggregate and sort them uniformly:

Category	Checks	Covers
Organization	10	2FA enforcement, SSO/SAML, default visibility, member privileges, OAuth apps, webhooks, audit log
Repository	13	branch protection, secret scanning, code scanning, Dependabot, deploy keys, CODEOWNERS
Actions	8	script injection, pull_request_target, token permissions, action pinning, runners, environments, OIDC
Secrets	5	scanning coverage, push protection, custom patterns, secret scoping
Supply Chain	5	dependency graph, Dependabot updates, SBOM, known vulnerabilities
Access Control	4	team permissions, external collaborators, GitHub Apps, PAT scopes

github_run_all fires every check against an org and repo in one call; github_audit_summary and github_audit_report turn the findings into a rollup or a full markdown report.

The checks that actually bite: Actions

Most misconfigurations are a shrug on their own. The GitHub Actions ones are not — they’re how real supply-chain compromises happen, and they’re the sharpest thing this server finds.

• Script injection (ACT-001). An untrusted field like ${{ github.event.issue.title }} interpolated straight into a run: block is arbitrary command execution — the title is the shell. An attacker opens an issue, the workflow runs their command. The fix is to pass it through an environment variable, never inline it into the script.
• pull_request_target + checkout (ACT-002). This pattern runs with repository write access and secrets, against code from a fork. Any outsider’s pull request can execute with your credentials. It’s the single most dangerous workflow shape on GitHub.

The analysis is honest about its method: it fetches the workflow YAML through the Contents API and matches patterns with regex — GitHub exposes no parsed-workflow API — so it reliably catches the common shapes (injection, PR-target, unpinned @v4 tags instead of SHA pins, write-all token defaults) and can miss something deeply nested or built dynamically. It’s a strong first pass, not a formal proof.

The point is the chains

Run the whole thing against a 50-repo org and the value isn’t the individual flags — it’s that one read shows how they combine:

github_run_all({ org: "acme-corp", repo: "main-app" })

  34 findings — 4 critical, 7 high, 12 medium, 11 low
  Org:          2FA not enforced, no SSO
  Repo:         no branch protection on main, no code scanning
  Actions:      script injection in deploy.yml:47, write-all token, unpinned actions
  Secrets:      7 unresolved secret-scanning alerts
  Supply chain: 3 critical Dependabot alerts open 90+ days
  Access:       platform team has admin on 47 repos (3 members)

A missing branch-protection rule is bad. A missing branch-protection rule plus script injection in a workflow plus a write-all token is a compromise path waiting to be walked. The remediation the agent returns is specific — “Settings → Branches → require PR reviews on main,” “move ${{ github.event.issue.title }} into an env: var,” “rotate the seven exposed secrets” — not a severity number to go look up.

Where it fits in CyberStrike

github-security-mcp is one of the built-in MCP servers in the CyberStrike suite, and it slots into the recon chain the others start: OSINT discovers that a target uses GitHub and which org → github-security runs the full posture audit → cve-mcp scores the critical Dependabot alerts it surfaces by real exploitation likelihood → the darknet server checks whether any of that org’s tokens have turned up in stealer-log dumps. Four servers, one assessment — the layering argument from MCP vs A2A.

Getting started

The token does all the work, so scope it tight — a fine-grained PAT with read-only organization and repository permissions is enough for a full audit, and it should come from the environment, not a checked-in config (the reasoning is in ten ways to secure your MCP servers):

{
  "mcpServers": {
    "github-security": {
      "command": "npx",
      "args": ["-y", "github-security-mcp"],
      "env": { "GITHUB_TOKEN": "github_pat_…" }
    }
  }
}

Then point an agent at your org and ask it to run github_run_all. The audit is read-only — it reports what to change; it doesn’t change anything itself.

Published on npm as github-security-mcp (MIT). Part of the CyberStrike embedded MCP server suite — see also OSINT, cve-mcp, the darknet MCP server, and MCP vs A2A.