GITHUB COPILOT SECURITY CHECKLIST

GitHub Copilot is the most widely deployed coding assistant in the world. The risk profile is also the most well-studied: Copilot suggestions occasionally regenerate near-verbatim secrets from training data, scaffold insecure SQL and crypto patterns, and bias toward whatever the surrounding code already does — which means an insecure pattern in one file becomes the suggestion in every adjacent file. The checklist below is what we look for first when we audit a Copilot-heavy repo.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once Copilot is part of your team’s everyday flow.

How to use this checklist

Walk it once on a representative branch, then make the relevant items part of your PR template and your org’s Copilot policy. The Copilot-specific items don’t show up in normal review because reviewers focus on the intentional diff — the dangerous changes are the suggestions developers accepted without thinking.

Critical (fix before launch)

1. Verify Copilot did not suggest hardcoded credentials

Why it matters. Copilot’s training corpus contains real keys committed to public repos. The model occasionally regenerates near-verbatim values when the surrounding context resembles the training context. The result is a hardcoded API key, JWT secret, or AWS credential pasted by autocomplete.

How to check. Run gitleaks detect --source . and trufflehog filesystem . on the diff. Search the diff for sk_, sk-proj-, eyJ, AKIA, xoxb-, and BEGIN PRIVATE KEY.

How to fix. Move every credential to env vars or a secret manager. Add gitleaks as a pre-commit hook so the next regeneration can’t repeat the mistake.

2. Audit Copilot-generated SQL for parameterization

Why it matters. Copilot scaffolds string-concatenated SQL when the surrounding code doesn’t use a query builder. This is the most common Copilot security regression we see, especially in Python and Node scripts.

How to check. Search the codebase for f"SELECT, f"INSERT, `SELECT ${, + user_id +, format("SELECT, and .execute("..." %. Any match is a potential injection.

How to fix. Replace with parameterized queries — ? for SQLite, $1 for Postgres, named bindings for ORMs. Don’t accept the Copilot suggestion that “fixes” the warning by escaping quotes manually.

3. Review suggestions in security-sensitive files line by line

Why it matters. Copilot is most useful for boilerplate. It’s most dangerous in auth, crypto, and payment code — exactly the files where a wrong suggestion costs the most. Random samples of accepted Copilot suggestions in these files show 30-40% have at least one security-relevant issue (CWE-89, CWE-79, CWE-798).

How to check. Add auth/, crypto/, payments/, and migrations/ to a CODEOWNERS rule that requires manual human review. Reject blanket approvals on PRs that touch these paths.

How to fix. Treat Copilot suggestions in these directories as “first draft from a junior developer” — useful, but every line needs a human to confirm.

4. Block Copilot in repos where IP or PII could leak

Why it matters. Copilot sends your prompt context (open files, recent edits) to GitHub for processing. Even with retention disabled, certain enterprise contexts (HIPAA, classified, customer datasets, unreleased trade secrets) require Copilot Business with explicit Zero Data Retention contracts — or no Copilot at all.

How to check. Audit the repos your org’s Copilot license covers. Confirm sensitive repos either use Copilot Business with ZDR, or are excluded from Copilot via .github/copilot-disable or org-level policy.

How to fix. Use Copilot’s content exclusions feature. Disable Copilot in the IDE for sensitive directories. Document the policy where developers will see it.

5. Disable Copilot Chat sharing for repos with secrets

Why it matters. Copilot Chat persists conversation history. A developer pasting a stack trace that contains a database URL, or a config file with an API key, leaves that data in the chat history — accessible to future prompts and to whatever training/retention policy applies.

How to check. Audit Copilot Chat history in your IDE for prefixes like sk_, sk-proj-, eyJ, and connection strings.

How to fix. Clear chat history. Set Copilot to private mode for sensitive repos. Educate the team on what not to paste.

6. Verify Copilot did not regenerate code with weakened crypto

Why it matters. Copilot still suggests MD5, SHA-1, ECB mode AES, and Math.random() for security purposes — because those patterns appear frequently in its training data. If your codebase has weak-crypto patterns anywhere, Copilot will tend to propagate them.

How to check. Search for md5, sha1, ECB, MODE_ECB, Math.random() (in security context), and Random() (Java/.NET, in security context).

How to fix. Use crypto.randomBytes() (Node), secrets.token_bytes() (Python), SecureRandom (Java). Use SHA-256 or higher for hashing, GCM or CTR for AES modes.

High (fix in the first week)

7. Enable Copilot’s duplicate-detection filter

In Copilot settings, enable “Block suggestions matching public code”. This drops suggestions that closely match training data — including suggestions that closely match real keys committed to public repos.

8. Require code review on every Copilot-heavy PR

If a PR’s commit messages or LOC pattern suggests Copilot autocomplete did most of the work, require an extra reviewer. The “I just wrote this myself” mental model doesn’t apply — it’s “I autocompleted this and skimmed the result.”

9. Run static analysis on Copilot-authored diffs

Semgrep, CodeQL, or your SAST of choice should run in CI on every PR. Copilot’s failure modes (SQL injection, hardcoded secrets, weak crypto) are exactly what these tools catch.

10. Disable Copilot for vendored or third-party code

vendor/, node_modules/, third_party/ — Copilot has nothing useful to add here, and editing third-party code with autocomplete is a recipe for invisible regressions.

11. Pin Copilot policy in org settings

GitHub Enterprise Cloud lets you set org-level Copilot policy. Pin it to the team’s agreed defaults (duplicate detection on, retention off where supported, content exclusions for sensitive paths) so individual settings can’t drift.

12. Audit Copilot Workspace plans before approving

If your team uses Copilot Workspace, the plan it generates is itself a thing to review — not just the diff. A plan that says “delete the auth middleware to fix the failing test” is the regression; the diff is the symptom.

Medium (fix when you can)

13. Document which files Copilot is allowed to suggest in

Per-repo .github/copilot-disable files give you fine-grained control. Use them on auth, crypto, and migration paths.

14. Audit accepted-suggestion telemetry per developer

Copilot exposes per-user metrics. A developer with very high acceptance rates on security-sensitive files is a flag for additional review, not a punishment.

15. Add CI gates that flag dangerous patterns

CI lints that fail on eval(, exec(, os.system(, subprocess.call(shell=True, dangerouslySetInnerHTML, cors() (no args), and crypto.createHash('md5') catch the most common Copilot regressions.

16. Educate the team on Copilot’s known failure modes

A 30-minute session on “what Copilot gets wrong” — SQL injection, hardcoded crypto, missing input validation — pays back more than any tooling.

17. Set up secret-scanning alerts on the org

GitHub’s secret scanning is free for public repos and Advanced Security for private. Enable it everywhere; review the findings weekly.

18. Verify your Copilot Business contract covers data handling

Read it. Confirm the retention, training, and data-residency clauses match what you told your security team they would.

After every Copilot-heavy session

• Read the diff in full — autocomplete is fast, review should not be.
• Search the diff for hardcoded secrets, weak crypto, and string-concatenated SQL.
• Re-run security tests separately.
• Confirm no new dangerous dependencies snuck in.
• Diff Copilot-touched config files (especially CI workflows) carefully.

Common attack patterns we see in Copilot-heavy projects

The autocompleted secret. Developer typed const stripeKey = and accepted the autocomplete. The suggestion was a real key from the training corpus. Stripe rotated the key within hours but the bundle had already shipped.

The SQL injection that “looked right”. Copilot suggested f"SELECT * FROM users WHERE email = '{email}'". Code review approved because the function’s description was clear. SQL injection ships to production.

The MD5 password hash. Copilot helpfully completed hashlib.md5(password.encode()).hexdigest() for a “password hash” function. Auth flow in production now uses MD5.

The relaxed CORS. Copilot’s autocomplete for cors({ origin: filled in '*'. Reviewer didn’t catch it. API serves authenticated responses cross-origin.

Related Resources

How to Secure GitHub Copilot

Step-by-step guide for hardening a Copilot-using team — org policy, content exclusions, CI gates, and the review patterns above in long form.

Is GitHub Copilot Safe?

In-depth analysis of Copilot’s data handling and known failure modes — what GitHub stores, what model providers see, and what we find when we audit a Copilot-heavy codebase.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app right now. VibeEval drives a real browser through the deployed result of Copilot-authored work, attempts the SQL-injection and missing-validation attacks above, and reports what got through — with file and line numbers to fix.