Safeguard
AI Security

5 best practices for adopting GitHub Copilot securely

GitHub Copilot has 1.3M+ paid seats. Five concrete, evidence-based practices for locking down content exclusion, licensing, code quality, and prompt injection risk.

James
Principal Security Architect
7 min read

GitHub Copilot now sits inside more engineering workflows than any other AI coding assistant, with GitHub reporting more than 1.3 million paid Copilot seats and over 50,000 paying organizations as of early 2024. That scale is exactly why security teams can no longer treat Copilot as an IDE plugin to rubber-stamp. Copilot ingests private repository context to generate suggestions, can propose code patterns lifted from public repos with unknown licenses, and — per an August 2024 Legit Security disclosure — its Chat interface could be manipulated through prompt injection to leak private repository data. None of this makes Copilot unsafe to use. It means adoption needs the same rigor as any other tool with broad code and data access: explicit scoping of what it can see, verification of what it produces, and monitoring of how it's used. Here are five practices that make that rigor concrete.

How do you prevent GitHub Copilot from indexing sensitive files and secrets?

You prevent it by turning on Copilot content exclusions, a Business/Enterprise-tier control GitHub took generally available in February 2024 that lets admins block specific paths, files, or entire repositories from being used as Copilot context. In practice, that means excluding .env files, Terraform state, secrets/ directories, and any infrastructure-as-code that embeds credentials, at both the repository and organization level via the copilot-content-exclusion.yml config or the org settings UI. This control only exists on Copilot Business and Enterprise — Copilot Individual has no equivalent — which is itself a reason to prohibit individual-plan Copilot for anyone touching company repos.

The stakes are not hypothetical. GitGuardian's 2024 State of Secrets Sprawl report found 12.8 million secrets exposed in public GitHub commits during 2023 alone, a 28% increase over 2022. Most of those leaks came from ordinary developer mistakes, not AI tooling — but it shows how easily credentials end up sitting in the exact files an AI assistant will read for context if you don't explicitly wall them off. Treat content exclusion as a day-one configuration step, not an optional hardening measure you'll get to later.

Should your organization allow Copilot suggestions that match public code?

No — for most enterprises, the "suggestions matching public code" setting should be set to block, not left on the default. GitHub added this filter in February 2023, after the November 2022 Doe v. GitHub lawsuit alleged that Copilot reproduced GPL-licensed code without attribution or license notice. The filter blocks suggestions of roughly 150 characters or more that match public repositories, but it's a pattern match, not a legal guarantee — shorter snippets and paraphrased structures can still slip through with license or IP provenance nobody reviewed.

Set the org-wide policy to block matching suggestions, and don't stop there: run SBOM generation and license scanning against every PR that includes Copilot-authored code, the same way you'd scan a newly added open-source dependency. If a Copilot suggestion introduces a licensing conflict, you want it caught in CI, not in a legal review six months after it ships to production.

Does GitHub Copilot generate insecure code, and how do you catch it?

Yes — peer-reviewed research has repeatedly found Copilot proposes vulnerable code in a meaningful share of security-relevant scenarios, so every Copilot suggestion needs to pass through the same SAST and SCA gates as human-written code, with no exceptions for "it's just a small function." The foundational study, Pearce et al.'s 2021 "Asleep at the Keyboard?" from NYU, tested Copilot against 89 scenarios spanning MITRE's top 25 CWEs and found that 39.33% of the 1,689 generated completions contained a vulnerability — SQL injection, path traversal, and hardcoded credentials among the most common. Follow-on testing through 2023 by academic and industry researchers found similar rates persisted even as Copilot's underlying models improved, particularly in scenarios involving cryptographic operations and deserialization.

The fix isn't banning Copilot from writing security-relevant code — that's unenforceable. It's making AI-authored code visible and testable: GitHub Enterprise now attributes Copilot-generated changes in PR metadata, so you can tag those PRs for mandatory SAST scanning and a second reviewer before merge, rather than trusting that "it compiled and passed the happy-path test" means it's safe.

Can attackers manipulate GitHub Copilot Chat through prompt injection?

Yes — in August 2024, security researcher Omer Mayraz at Legit Security publicly disclosed a working proof-of-concept in which hidden instructions embedded in a repository — inside a README or a code comment invisible in the rendered view but readable by Copilot's context window — caused Copilot Chat to leak information from private repositories and surface attacker-controlled links to users who simply asked it an ordinary question. The attack didn't require the victim to do anything unusual; querying Copilot Chat about a poisoned repo was enough to trigger the exfiltration path. GitHub patched the issue by restricting how Copilot Chat renders hidden content and tightening reference filtering, but the underlying pattern — untrusted text reaching a model with access to sensitive context — isn't unique to this one bug.

Treat every piece of text Copilot ingests (READMEs, issue bodies, comments, even dependency descriptions) as untrusted input, the same way you'd treat user-supplied data reaching a web app. Disable Copilot Chat features you don't actively need, such as web access or third-party skill integrations, and review Copilot Chat query logs periodically for patterns that look like data exfiltration rather than normal developer questions.

How do you enforce consistent Copilot security policies across hundreds of repositories?

You enforce it centrally through GitHub's organization-level Copilot policy settings and audit log streaming, not by asking individual teams to configure things consistently on their own. GitHub Enterprise Cloud has shipped Copilot-specific audit log events — policy changes, enablement/disablement, content exclusion edits — since 2023, and these can be streamed to a SIEM such as Splunk or Microsoft Sentinel for continuous monitoring instead of periodic manual review. For organizations managing Copilot access across tens of thousands of repositories, doing this through the UI repo-by-repo doesn't scale; use the Enterprise policy APIs to push exclusion rules and suggestion-matching settings uniformly.

Pair that with a quarterly access review of exactly who has Copilot enabled and why, tied to least-privilege principles rather than defaulting every engineer to "on." Map which repositories have Copilot active against your existing SBOM inventory so that when an AI-assisted change introduces a new component, you know it happened and can trace it back to a specific PR and author — human or AI-assisted.

How Safeguard Helps

Safeguard closes the gap between "Copilot wrote it" and "Copilot's suggestion is safe to ship" by treating every AI-authored change the same way your supply chain security program already treats any other change: verify it, don't assume it. Reachability analysis confirms whether a vulnerable pattern a Copilot suggestion introduces is actually exploitable in your running application, so teams triage real risk instead of chasing every flagged line across a diff. Griffin AI, Safeguard's detection engine, is tuned to recognize the specific insecure patterns AI coding assistants repeat most often — hardcoded secrets, missing input validation, deprecated crypto calls — and flags them before merge rather than after deployment. Safeguard also generates and ingests SBOMs on every build, so a new dependency a Copilot suggestion pulls in is automatically reconciled against your component inventory and license policy. When Griffin AI identifies a fixable issue, Safeguard opens an auto-fix pull request with the patch already applied, so security teams spend their time reviewing fixes instead of manually rewriting what an AI assistant got wrong.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.