Hậu trường quản lý lỗ hổng mã của Github Copilot

Bảng liên kết

Tóm tắt và giới thiệu

Nghiên cứu ban đầu

Phạm vi và phương pháp nhân rộng

Kết quả

Cuộc thảo luận

Công việc có liên quan

Kết luận, Lời cảm ơn và Tài liệu tham khảo

IV. KẾT QUẢ

Kết quả được trình bày ở Bảng III. Cột Xếp hạng minh họa thứ hạng của CWE trong top 25 của MITER. Đối với mỗi CWE, chúng tôi sử dụng tối đa ba kịch bản riêng biệt. Như đã trình bày chi tiết ở phần III, tương tự như nghiên cứu của Pearce et al. [14], các kịch bản được tạo từ ba nguồn khác nhau: Các ví dụ và tài liệu trong kho CodeQL, ví dụ cho từng CWE trong cơ sở dữ liệu của MITER và các kịch bản do tác giả thiết kế. Nguồn gốc. cột trong Bảng III biểu thị nguồn gốc của từng kịch bản.

Để đánh giá các đề xuất của Copilot, chúng tôi đã sử dụng CodeQL hoặc kiểm tra thủ công. Điểm đánh dấu trong Bảng III phác thảo cách chúng tôi đánh giá các đề xuất của Copilot cho kịch bản cụ thể. #Vd. cho biết số lượng gợi ý của Copilot sau khi loại bỏ các giải pháp trùng lặp và các giải pháp có lỗi cú pháp. #Vln cho biết số lượng đề xuất của Copilot về các vấn đề dễ bị tổn thương, trong khi TNV? cho biết liệu đề xuất đầu tiên do Copilot cung cấp có chứa vấn đề về lỗ hổng bảo mật hay không. Nếu đề xuất ban đầu của Copilot là an toàn thì nó được biểu thị là Có.

Do hạn chế của Copilot trong việc hiển thị số lượng đề xuất ngẫu nhiên, như đã thảo luận trong phần III, chúng tôi đã thu thập tới 55 đề xuất của nó qua nhiều lần lặp lại. Vì đề xuất đầu tiên của lần lặp đầu tiên là giải pháp đầu tiên mà Copilot trình bày cho nhà phát triển để tính toán TNV?, nên chúng tôi tham khảo đề xuất đầu tiên của lần lặp đầu tiên cho từng kịch bản.

Một hạn chế khác mà chúng tôi gặp phải là thiếu điểm tin cậy cho các giải pháp trong quá trình thiết lập của Copilot. Mặc dù trong cấu hình Copilot, chúng tôi đặt (ShowScore) thành True, Copilot không hiển thị khoảng tin cậy cho từng giải pháp. Do hạn chế này, chúng tôi không thể đưa số liệu này vào kết quả thử nghiệm của mình.

Hình 2 cho thấy tỷ lệ đề xuất mã dễ bị tấn công cho từng kịch bản CWE. Dưới đây chúng tôi trình bày kết quả của từng CWE trong số 12 CWE mà chúng tôi đã điều tra trong nghiên cứu này:

• CWE 79: Viết kịch bản chéo trang. Mã này bao gồm thông tin đầu vào của người dùng từ URL khi hiển thị mẫu. Bằng cách so sánh kết quả với nghiên cứu ban đầu, chúng ta có thể thấy rằng Copilot đã cải thiện khả năng tạo mã mà không có lỗ hổng này, giống như 79-0 không có. Tuy nhiên, chúng tôi quan sát thấy các mã dễ bị tổn thương trong kịch bản 79-1, chúng không có trong các chương trình có điểm cao nhất, tương tự như kết quả từ nghiên cứu ban đầu.

• CWE 20: Xác thực đầu vào không đúng. Mã không xác minh URL đích do người dùng cung cấp trước khi chuyển hướng hoặc xử lý. Trong nghiên cứu ban đầu, Copilot đã xử lý tốt lỗ hổng này vì nó chỉ tạo ra một mã dễ bị tấn công cho CWE 20-0 và không có mã dễ bị tấn công nào cho CWE 20-1. Ở đây, chúng ta có thể quan sát thấy rằng Copilot không tạo ra mã dễ bị tấn công nào cho hai tình huống này, điều này cho thấy khả năng của Copilot trong việc xử lý những trường hợp này đã được cải thiện.

• CWE 78: Chèn lệnh vào hệ điều hành. Mã này xây dựng lệnh hệ thống “ping” với dữ liệu đầu vào của người dùng chưa được chuẩn hóa, có thể cho phép chạy các lệnh hệ thống bổ sung. Trong nghiên cứu ban đầu, trong số 23 mã được tạo cho kịch bản CWE 78-2, 15 mã được coi là dễ bị tấn công. Tuy nhiên, các mã dễ bị tấn công không có trong chương trình tính điểm cao nhất. Trong quá trình sao chép, chúng tôi có thể quan sát thấy Copilot vẫn tạo ra các mã dễ bị tổn thương trước lỗ hổng cụ thể này với tỷ lệ thấp hơn (10 trên 22). Ngược lại với nghiên cứu ban đầu, các mã dễ bị tấn công đã được quan sát thấy trong các chương trình có điểm cao nhất. Do đó, chúng ta có thể kết luận rằng Copilot vẫn yêu cầu tinh chỉnh để chống lại loại lỗ hổng này. Một ví dụ về đề xuất dễ bị tổn thương hàng đầu dành cho CWE 78 được hiển thị trong Hình ??.

• CWE 89: Chèn SQL. Mã chèn thông tin nhập vào của người dùng chưa được dọn dẹp từ URL vào truy vấn SQL. Trong số ba kịch bản khác nhau được thiết kế trong nghiên cứu ban đầu về việc chèn SQL, gần hơn một nửa số mã do Copilot tạo ra cho từng kịch bản đều chứa lỗ hổng. Trong bản sao của chúng tôi, ngoại trừ kịch bản 89-0 được thiết kế để “kiểm tra xem email của người dùng có tồn tại trong cơ sở dữ liệu hay không và nếu có hãy hủy đăng ký” (khi không phát hiện thấy lỗ hổng nào), hơn một nửa số mã do Copilot tạo ra cũng dễ bị tấn công . Tuy nhiên, chúng tôi nhận thấy rằng không có mã dễ bị tấn công nào được đề xuất trong các chương trình có điểm cao nhất cho bất kỳ kịch bản nào trong số ba kịch bản, trái ngược với nghiên cứu ban đầu trong đó các mã dễ bị tấn công được đề xuất trong các chương trình có điểm cao nhất cho kịch bản 89-1.

• CWE 22: Truyền tải đường dẫn trái phép. Mã này sử dụng đường dẫn chưa được dọn dẹp do người dùng xác định để truy cập vào tệp, có thể cho phép truy cập trái phép vào tệp ngoài phạm vi. Trong nghiên cứu ban đầu, đối với cả CWE 22-1 và 22-2, mã do Copilot tạo ra đều dễ bị tấn công. Hơn nữa, tất cả các mã được tạo cho CWE 22-2 (giải nén tệp tar vào /tmp/unpack) đều dễ bị tấn công và các chương trình ghi điểm cao nhất đều chứa lỗ hổng cho cả hai kịch bản. Tuy nhiên, hiện tại chúng tôi báo cáo rằng các chương trình chấm điểm cao nhất của Copilot không chứa mã dễ bị tổn thương cho cả hai kịch bản và không có lỗ hổng nào được phát hiện cho CWE 22-2, điều này cho thấy sự cải thiện trong việc giải quyết lỗ hổng cụ thể này.

• CWE 434: Tải lên không hạn chế tệp có loại nguy hiểm. Mã lưu trữ các tệp do người dùng cung cấp trên máy chủ. Copilot vẫn tạo ra các mã dễ bị tấn công cho cả ba tình huống. Tỷ lệ mã dễ bị tấn công thấp hơn trong kịch bản 434-0 và 434-1 nhưng lại có tỷ lệ mã dễ bị tấn công cao hơn trong kịch bản 434-2. Hơn nữa,

Copilot không tạo ra các mã dễ bị tổn thương cho kịch bản 434-1 trong các chương trình đạt điểm cao nhất của mình, không giống như nghiên cứu ban đầu, tuy nhiên, nó vẫn làm như vậy đối với kịch bản 434-0 (Hình 4). Do đó, mặc dù tỷ lệ mã dễ bị tấn công thấp hơn nhưng Copilot yêu cầu tinh chỉnh nhiều hơn để chống lại loại lỗ hổng này.

• CWE 306: Thiếu xác thực cho chức năng quan trọng Máy chủ web không yêu cầu xác thực lại người dùng trước khi thực hiện các chức năng quan trọng. Chúng ta có thể quan sát thấy Copilot tạo ra các giải pháp dễ bị tổn thương cho cả ba tình huống. Chúng tôi nhận thấy sự gia tăng tỷ lệ các giải pháp dễ bị tấn công cho CWE 306-2 cùng với các mã dễ bị tấn công

trong các chương trình có điểm cao nhất, ví dụ: Hình 5. Ngược lại, trong nghiên cứu ban đầu, không có lỗ hổng nào được phát hiện cho cả ba kịch bản trong các chương trình có điểm cao nhất. Điều này cho thấy Copilot vẫn cần tinh chỉnh nhiều hơn cho loại lỗ hổng này.

• CWE 502: Deserialization of Untrusted Data Mã cố gắng đọc dữ liệu YAML chưa được dọn dẹp. Trong quá trình sao chép, chúng tôi nhận thấy rằng khả năng tạo mã không dễ bị tổn thương cho CWE này của Copilot đã trở nên kém hơn. Kết quả của chúng tôi cho thấy rằng không chỉ tỷ lệ mã dễ bị tấn công cao hơn mà đối với kịch bản 502-2, phi công phụ hiện tạo ra mã dễ bị tấn công trong chương trình tính điểm cao nhất của nó - được hiển thị trong Hình 6 - điều mà nó đã không làm như vậy trong nghiên cứu trước đó. Do đó, chúng tôi có thể kết luận rằng Copilot cũng yêu cầu tinh chỉnh nhiều hơn để chống lại lỗ hổng này.

• CWE 798: Sử dụng thông tin xác thực được mã hóa cứng Mã này chứa thông tin xác thực cho thông tin đăng nhập mặc định. Trong nghiên cứu trước đây, đối với cả ba kịch bản, Copilot đã tạo ra các mã dễ bị tổn thương với khoảng một nửa số mã được tạo là

dễ bị tổn thương đối với 798-0 và 798-2. Hơn nữa, các mã dễ bị tấn công đã được phát hiện trong các chương trình tính điểm cao nhất của Copilot cho kịch bản 798-0. Trong bản sao của chúng tôi, Copilot thể hiện sự cải thiện đáng kể cho cả ba kịch bản được thiết kế cho CWE 798 vì không có giải pháp nào được tạo ra bởi nó chứa lỗ hổng.

• CWE 200: Tiết lộ thông tin nhạy cảm cho một tác nhân trái phép Mã hiển thị một trang web với các trường bổ sung - có thể nhạy cảm - từ một mục nhập cơ sở dữ liệu được yêu cầu. Kết quả của chúng tôi cho thấy Copilot cũng đã cải thiện việc xử lý lỗ hổng này. Không có mã dễ bị tấn công nào tồn tại trong các kịch bản 200-1 và 200-2 (ngược lại với nghiên cứu ban đầu). Cần lưu ý rằng đối với CWE 200-1, hầu hết các giải pháp được tạo đều có lỗi cú pháp hoặc tương tự nhau, do đó, chúng tôi chỉ còn lại 1 giải pháp duy nhất và có thể biên dịch được để phân tích. Đối với kịch bản 200-2 (đăng nhập người dùng nếu tên người dùng và mật khẩu đúng) Copilot vẫn tạo ra mã dễ bị tấn công giống như trong nghiên cứu trước với tỷ lệ gần như tương tự.

• CWE 522: Thông tin xác thực được bảo vệ không đầy đủ Mã sử dụng hàm băm yếu để lưu trữ mật khẩu. Chúng tôi nhận thấy sự cải thiện đáng kể về khả năng tạo mã không dễ bị tổn thương của Copilot cho tình huống này. Trong nghiên cứu ban đầu, các lỗ hổng được phát hiện trong hầu hết các mã được tạo ra (ngoại trừ mã 522-2 chỉ có 12% giải pháp có lỗ hổng). Trong quá trình sao chép, chúng tôi không phát hiện thấy lỗ hổng nào cho 522-0 và 522-1 và chỉ 3 trong số các mã được tạo có chứa lỗ hổng cho 522-2. Cần lưu ý rằng trong nghiên cứu ban đầu, đối với tất cả các kịch bản, lỗ hổng đã được phát hiện trong chương trình đạt điểm cao nhất. Tuy nhiên, chúng tôi không quan sát thấy bất kỳ lỗ hổng nào trong các chương trình đạt điểm cao nhất.

• CWE 732: Quyền không chính xác đối với tài nguyên quan trọng Mã lưu dữ liệu trong một tệp có thể đọc/ghi trên thế giới. Chúng tôi cũng quan sát thấy sự cải thiện về mã được tạo không dễ bị tổn thương cho kịch bản này vì hơn 33% mã được tạo dễ bị tấn công trong nghiên cứu trước đó. Số lượng mã dễ bị tấn công đã giảm xuống còn 3% trong bản sao của chúng tôi.