CoChat
Sign Up
Cited by 153Software Engineering ResearchWeb Application Security VulnerabilitiesAdversarial Robustness in Machine Learning

The DOI matches its Crossref record; 16 of the 16 references it cites were found in a registry or an index; none of the 6 sources its claims cite is checked for support yet.

Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions

Open access
Pearce, Hammond, Ahmad, Baleegh, Tan, Benjamin, Dolan-Gavitt, Brendan, Karri, Ramesh·2025·Communications of the ACM
DOI 10.1145/3610721
Open this paper in CoChat — free accountOpen PDF

Abstract

There is burgeoning interest in designing AI-based systems to assist humans in designing computing systems, including tools that automatically generate computer code. The most notable of these comes in the form of the first self-described “AI pair programmer,” GitHub Copilot, which is a language model trained over open-source GitHub code. However, code often contains bugs—and so, given the vast quantity of unvetted code that Copilot has processed, it is certain that the language model will have learned from exploitable, buggy code. This raises concerns on the security of Copilot’s code contributions. In this work, we systematically investigate the prevalence and conditions that can cause GitHub Copilot to recommend insecure code. To perform this analysis we prompt Copilot to generate code in scenarios relevant to high-risk cybersecurity weaknesses, for example, those from MITRE’s “Top 25” Common Weakness Enumeration (CWE) list. We explore Copilot’s performance on three distinct code generation axes—examining how it performs given diversity of weaknesses, diversity of prompts, and diversity of domains. In total, we produce 89 different scenarios for Copilot to complete, producing 1,689 programs. Of these, we found approximately 40% to be vulnerable.

Overview

Integrity signals

Registry

Crossref · 10.1145/3610721

Cites

16 of 16 references verified0 citation errors · 0 not checkable

Statistics

Nothing to recompute.

Verification

Claims the paper makes

0 of 6 cited sources checked · 0 supported · 0 flagged

Show all 18 claims

  • It may state two separate claims as one. 36
  • Probably not a substantial claim. 32
  • The quote only partly states this claim. 1
53 of 53

  • The paper relies on this without support.

    No systematic examination of the security of machine-learning-generated code existed prior to this study.

    “Although prior research has evaluated the functionality of code generated by language models, 2,5 there is no systematic examination of the security of ML-generated code.”

  • The paper relies on this without support.

    Hardware designs free of hardware weaknesses meet a baseline level of security.

    “As with the software CWEs, hardware designers can be sure that their designs meet a certain baseline level of security if their designs are free of hardware weaknesses.”

  • The paper relies on this without support.

    Evaluating the security of code contributions made by Copilot is an open problem.

    “Unlike metrics for functional correctness of generated code, evaluating the security of code contributions made by Copilot is an open problem.”

  • The paper relies on this without support.

    Python and C are extremely popular, supported by CodeQL, and together can instantiate the complete list of the top 25 CWEs.

    “Python and C are extremely popular, supported by CodeQL, and between them, can realistically instantiate the complete list of the top 25 CWEs.”

  • The paper relies on this without support.

    Determining whether code is vulnerable sometimes requires knowledge external to the code itself.

    “As discussed in Section 2, determining if code is vulnerable sometimes requires knowledge (context) external to the code itself.”

  • The paper relies on this without support.

    Determining whether a specific vulnerability is exploitable requires framing within an attacker model.

    “Furthermore, determining that a specific vulnerability is exploitable requires framing within a corresponding attacker model.”

  • The paper relies on this without support.

    CWE-89 is well-known and well-formed, with no grey zone, making it suitable for the prompt diversity experiment.

    “For this experiment, we choose CWE-89 (SQL Injection), as it is well-known (infamous, with plenty of both vulnerable and non-vulnerable code examples online) and well-formed (code is either vulnerable or it is not, there is no grey zone).”

  • The paper relies on this without support.

    Novice users are more likely to accept Copilot's top suggestion.

    “The security of the top options are particularly important-novice users may be more likely to accept the 'best' suggestion.”

  • The paper relies on this without support.

    Copilot is trained on open-source code available on GitHub.

    “As Copilot is trained over open-source code available on GitHub”

  • The paper relies on this without support.

    Bugs are more visible in open-source repositories.

    “where bugs are more visible in open-source repositories”

  • The paper relies on this without support.

    Best practices can become outdated as the cybersecurity landscape evolves.

    “What is 'best practice' at the time of writing may slowly become 'bad practice' as the cybersecurity landscape evolves.”

  • The paper relies on this without support.

    Legacy code uses insecure hashes.

    “Yet, legacy code uses insecure hashes”

  • The paper relies on this without support.

    Tooling for examining hardware for CWEs is rudimentary.

    “Unfortunately, due to their recent emergence, tooling for examining hardware for CWEs is rudimentary.”

  • The paper relies on this without support.

    Real-world code is messier and contains more context than the scenarios.

    “Real-world code is considerably messier and contains larger amounts of context”
14 of 14

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

Each contradiction between two passages listed here was confirmed by an independent check.

  • Incorrect percentage of vulnerable top suggestions in the prompt study

    Minor

    Four of 17 scenarios is 23.53%, not 25.53%.

    Reported 25.53 · recomputed 23.529412

  • Two different prompt changes share the D-5 identifier

    Minor

    Table 3 assigns D-5 to both adding a phrase to the comment and removing the comment, so the identifier does not uniquely identify a scenario.

  • A scenario with no vulnerable outputs conflicts with the stated universal result

    Minor

    The paper says every scenario in this study produced vulnerable code, but Table 1 records zero vulnerable options for scenario 20-1.

3 of 3

Citations

Cites

  • Attention Is All You Need

    Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, L., & Polosukhin, I. (2017) · arXiv · doi:10.48550/arxiv.1706.03762 · Cited by 120,404 · cited 1×

    “DL architectures that demonstrate good fits for NLP include LSTMs [13], RNNs [14], and Transformers [15] that have paved the way for models such as BERT [16], GPT-2 [17], and GPT-3 [18].”

  • Language Models are Few-Shot Learners

    Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., et al. (2020) · arXiv · doi:10.48550/arxiv.2005.14165 · Cited by 23,372 · cited 2×

    “DL architectures that demonstrate good fits for NLP include LSTMs [13], RNNs [14], and Transformers [15] that have paved the way for models such as BERT [16], GPT-2 [17], and GPT-3 [18].”

  • Advances in Neural Information Processing Systems 29

    Teymur, O., Zygalakis, K., & Calderhead, B. (2016) · Cited by 13,881

  • LSTM neural networks for language modeling

    Sundermeyer, M., Schlüter, R., & Ney, H. (2012) · Interspeech 2012 · doi:10.21437/interspeech.2012-65 · Cited by 1,963 · cited 2×

    “DL architectures that demonstrate good fits for NLP include LSTMs [13], RNNs [14], and Transformers [15] that have paved the way for models such as BERT [16], GPT-2 [17], and GPT-3 [18].”
    Method

  • Evaluating Large Language Models Trained on Code

    Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. D. O., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., et al. (2021) · arXiv · doi:10.48550/arxiv.2107.03374 · Cited by 1,436 · cited 8×

    “Code generation literature emphasizes functional correctness, measured by compilation and checking against unit tests, or using text similarity metrics to desired responses [2].”
    Influential

  • Recurrent Neural Network for Text Classification with Multi-Task LearningPreprint

    Liu, P., Qiu, X., & Huang, X. (2016) · arXiv (Cornell University) · doi:10.48550/arxiv.1605.05101 · Cited by 1,307 · cited 2×

    “DL architectures that demonstrate good fits for NLP include LSTMs [13], RNNs [14], and Transformers [15] that have paved the way for models such as BERT [16], GPT-2 [17], and GPT-3 [18].”

  • CoQA: A Conversational Question Answering Challenge

    Reddy, S., Chen, D., & Manning, C. D. (2019) · Transactions of the Association for Computational Linguistics · doi:10.1162/tacl_a_00266 · Cited by 975 · cited 1×

    “These models can perform language tasks such as translation and answering questions from the CoQA [19] dataset; after fine-tuning on specialized datasets, the models can undertake tasks such as code completion [2] and hardware design [20].”

  • Program Synthesis with Large Language Models

    Austin, J., Odena, A., Nye, M., Bosma, M., Michalewski, H., Dohan, D., Jiang, E., Cai, C., Terry, M., Le, Q., et al. (2021) · arXiv · doi:10.48550/arxiv.2108.07732 · Cited by 388 · cited 1×

    “Although prior research has evaluated the functionality of code generated by language models [3], [2], there is no B. Dolan-Gavitt is supported in part by the National Science Foundation award #1801495.”

  • Fuzzing: a survey

    Li, J., Zhao, B., & Zhang, C. (2018) · Cybersecurity · doi:10.1186/s42400-018-0002-y · Cited by 279 · cited 1×

    “Other CWEs cannot be adequately tested for by examining only the source code in isolation, thus necessitating other approaches like fuzzing [24] for security analysis.”

  • NLP (Natural Language Processing) for NLP (Natural Language Programming)

    Mihalcea, R. F., Liu, H., & Lieberman, H. (2006) · Lecture notes in computer science · doi:10.1007/11671299_34 · Cited by 100 · cited 1×

    “There are many efforts to automatically translate specifications into computer code for natural language programming [9], through formal models for automatic code generation (e.”
    Background

Flagged first, then by citations

Show all 12 references

Research works printed but not linked: 2

  1. Devlin J. Chang M.-W. Lee K. and Toutanova K. BERT: Pre-training of deep bidirectional transformers for language understanding. CoRR abs/1810.04805 2018 _eprint: 1810.04805. · arXiv
  2. Rahit, K.M.T.H., Nabil, R.H., and Huq, M.H. Machine Translation from Natural Language to Code Using Long-Short Term Memory. In Future Technologies Conf. (FTC). Springer, International Publishing, Oct. 2019, 56–63,

Cited by

Sorted by citations

Related

See all

Metadata

Authors
Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R.
Affiliations
  • New York University (US)
  • University of Calgary (CA)
ORCID
Venue
Communications of the ACM
Publisher
Association for Computing Machinery (ACM)
Published
2025-01-22
Volume
68
Issue
2
Pages
96-105
ISSN
  • 0001-0782 (ISSN-L)
  • 1557-7317
DOI
10.1145/3610721
OpenAlex
W4406602186
Cited by
140
References
12
Citations by year
2026: 108 · 2025: 32
FWCI
144.94
Type
journal article
Language
en
Open access
Licence
www.acm.org/publications/policies/copyright_policy#Background (vor)
Locations
Communications of the ACM (publishedVersion)
Funders
  • National Science Foundation (1801495)
  • Office of Naval Research (00014-18-1-2058)
Topics
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Research
  • Physical Sciences › Computer Science › Information Systems › Web Application Security Vulnerabilities
  • Physical Sciences › Computer Science › Artificial Intelligence › Adversarial Robustness in Machine Learning
Keywords
GitHub Copilot, AI-assisted code generation, code security, Common Weakness Enumeration, prompt engineering, language models

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

A language model drew the claims from the paper on 2026-10-01, under version 3 of the claim definition (model deepseek-v4.1-flash, prompt extract-v3).

A second model labelled each claim on 2026-10-01 (model jev-1.13-20260917, definition revision gold-guideline-v0.2).

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review