Noma Labs đã chỉ ra rằng chỉ một issue công khai trên GitHub cũng có thể đánh cắp mã nguồn từ các repository riêng tư bằng cách sử dụng tự động hóa dựa trên AI. Bản thử nghiệm (proof-of-concept) của họ cho phép kẻ tấn công biến chính các bot quy trình làm việc (workflow bots) của một tổ chức thành công cụ tấn công, làm rò rỉ các tệp độc quyền mà không cần phá vỡ cơ chế xác thực của GitHub.

Cuộc tấn công hiển hiện ngay trước mắt

Chuỗi sự kiện đủ đơn giản để có thể tái hiện:

  • Một kẻ tấn công tạo một issue trong một repository công khai mà bất kỳ ai cũng có thể xem.
  • Một AI agent, được kết nối vào pipeline tích hợp liên tục (continuous-integration), sẽ đọc tiêu đề và nội dung của issue đó.
  • Chính agent đó đã có sẵn quyền đọc đối với các repository riêng tư khác trong cùng tổ chức.
  • Các chỉ dẫn ẩn trong issue công khai sẽ điều hướng agent lấy những tệp riêng tư nào.
  • Agent đăng các tệp đã lấy được trở lại issue công khai dưới dạng một bình luận, từ đó phơi bày chúng ra thế giới.

Mọi thứ diễn ra chỉ trong một lần chạy tự động hóa duy nhất. Không cần đánh cắp thông tin xác thực, không rò rỉ API key, cũng không có lỗ hổng GitHub nào. Kẻ tấn công chỉ đơn giản là lợi dụng sự tin tưởng mà tổ chức dành cho chính bot của mình.

Tại sao điều này lại quan trọng vào lúc này

Các AI agent hiện đang đóng vai trò kết nối các pipeline phát triển hiện đại. Chúng mở pull-requests, chạy thử nghiệm, triển khai các bản build và phân loại lỗi (triage bugs)—tất cả đều được kích hoạt bởi các tín hiệu nhẹ như bình luận trong issue. Khi các agent này nắm giữ quyền truy cập repository rộng rãi, ranh giới giữa dữ liệu đáng tin cậy và đầu vào không đáng tin cậy từ người dùng trở nên mong manh.

Nếu một agent có thể đọc mã nguồn riêng tư và viết công khai trong cùng một lần thực thi, mô hình kiểm soát truy cập của tổ chức sẽ sụp đổ.

Lỗi thực sự: nằm ở quyền hạn, không phải ở mô hình

Bản demo không ám chỉ mô hình AI nền tảng. Mô hình chỉ đơn thuần làm theo các chỉ dẫn mà nó nhận được. Lỗ hổng nằm ở bộ quyền hạn được cấp cho quy trình tự động hóa:

  • Quyền đọc đối với các repository riêng tư trong toàn bộ tổ chức.
  • Quyền ghi vào các luồng thảo luận (threads) của issue công khai.
  • Kích hoạt dựa trên văn bản công khai mà bất kỳ ai cũng có thể soạn thảo.

Các giải pháp không tốn kém nhưng hiệu quả

Áp dụng nguyên tắc đặc quyền tối thiểu (least privilege) sẽ cắt giảm đáng kể lộ trình tấn công:

  • Giới hạn phạm vi của bot trong repository mà nó cần thiết. Nếu nó chỉ cần hoạt động trên một repo cụ thể, hãy từ chối mọi quyền đọc khác.
  • Tách biệt token đọc và ghi. Sử dụng một thông tin xác thực để lấy mã nguồn và một thông tin xác thực khác được kiểm soát chặt chẽ để đăng bình luận.
  • Sự phê duyệt của con người trước khi đăng bất kỳ nội dung công khai nào. Một bước xem xét nhẹ nhàng—chẳng hạn như yêu cầu một nhãn (label) phê duyệt—sẽ tạo ra một điểm kiểm soát mà không làm gián đoạn pipeline.
  • Giảm thiểu phạm vi ảnh hưởng (blast-radius). Thiết kế các quy trình làm việc sao cho một lỗi hoặc sự lạm dụng chỉ ảnh hưởng đến tối đa một repository, chứ không phải toàn bộ tổ chức.

Ý kiến phản biện: chi phí vận hành

Những điều cần lưu ý tiếp theo

Bài học rút ra: Nếu một quy trình tự động hóa bằng AI vừa có thể xem mã nguồn riêng tư vừa có thể phát ngôn công khai, thì hệ thống đó đã bị thiết kế sai. Hãy thắt chặt quyền hạn, thêm các bước kiểm tra của con người và giữ phạm vi ảnh hưởng ở mức nhỏ—nếu không, chỉ một issue công khai cũng có thể trở thành vector rò rỉ dữ liệu.