GitHub Actions: Mắt xích yếu nhất trong chuỗi cung ứng phần mềm mã nguồn mở

GitHub Actions: Mắt xích yếu nhất trong chuỗi cung ứng phần mềm mã nguồn mở

Nếu bạn truy ngược lại hầu hết các sự cố bảo mật trong chuỗi cung ứng mã nguồn mở trong 18 tháng qua, bạn sẽ thấy rằng tất cả đều dẫn đến một tệp YAML trong .github/workflows. Từ việc Ultralytics vô tình phát tán phần mềm đào tiền ảo (crypto miner) lên PyPI, các gói nx biến hàng ngàn máy của nhà phát triển thành công cụ thu thập thông tin xác thực, cho đến vụ rò rỉ bí mật từ 23.000 kho lưu trữ qua tj-actions, hay Trivy bị xâm phạm hai lần trong ba tuần. Mặc dù mỗi vụ việc có nạn nhân và hình thức tấn công khác nhau, nhưng điểm chung là chúng đều khai thác các tính năng của GitHub Actions hoạt động đúng như tài liệu hướng dẫn.

Vấn đề cốt lõi: Tính tiện lợi gặp rủi ro

Vấn đề không nằm ở một lỗi lập trình cụ thể, mà nằm ở thiết kế sản phẩm. GitHub Actions là tập hợp các tính năng rất tiện lợi khi đứng riêng lẻ, nhưng lại cực kỳ dễ dàng lắp ghép thành một hệ thống nguy hiểm. Hầu hết các quy trình công việc (workflow) xây dựng và xuất bản phần mềm mã nguồn mở thế giới đều chạy trên một nền tảng có các cấu hình mặc định được chọn cho công cụ CI của doanh nghiệp tư nhân, và chưa bao giờ được thiết kế lại thực sự cho các nhánh fork (sao chép) ẩn danh hay các yêu cầu kéo (pull request) vội vã.

Chuỗi các sự cố bảo mật nghiêm trọng

Dưới đây là các sự cố điển hình minh họa cho những lỗ hổng này:

• Spotbugs (Tháng 11/2024): Sử dụng trigger pull_request_target để kiểm tra mã từ một fork không đáng tin cậy. Trigger này chạy trong ngữ cảnh của kho lưu trữ cơ sở với quyền truy cập bí mật đầy đủ, cho phép kẻ tấn công thực thi mã và đánh cắp PAT (Personal Access Token) của người duy trì.
• Ultralytics (Tháng 12/2024): Tấn công cũng qua pull_request_target nhưng ở giai đoạn hai. Kẻ tấn công đã đầu độc mục nhập bộ nhớ đệm (cache) của GitHub Actions. Khi quy trình phát hành hợp pháp khôi phục cache này, nó đã thực thi mã độc trong quá trình xây dựng wheel, dẫn đến việc hai phiên bản của ultralytics trên PyPI chứa phần mềm đào tiền ảo.
• Tj-actions (Tháng 3/2025): Sử dụng PAT bị đánh cắp từ vụ Spotbugs để đẩy một commit độc hại và di chuyển thẻ (tag) v1 trỏ đến nó. Do hàng nghìn kho lưu trữ tham chiếu action này bằng thẻ di động (mutable tag) thay vì băm SHA cố định, tất cả chúng đều đã chạy một bộ quét bộ nhớ để đổ bí mật vào nhật ký xây dựng công khai.
• S1ngularity / nx (Tháng 8/2025): Một workflow đã nội suy tiêu đề của pull request vào một bước lệnh shell. Cú pháp template $ mở rộng trước khi shell thấy script, nên một PR có tiêu đề chứa lệnh thay thế sẽ trở thành mã thực thi. Kết quả là hàng ngàn kho lưu trữ riêng tư bị lộ.
• Elementary-data (Tháng 4/2026): Chỉ cần một bình luận trên một pull request cũ đã kích hoạt một workflow lắng nghe sự kiện issue_comment. Workflow này đã thực thi mã từ nội dung bình luận và đẩy một gói độc hại lên PyPI chỉ trong 10 phút mà không cần người duy trì phê duyệt.

Các yếu tố nguy hiểm thường gặp

Khi đặt các sự cố cạnh nhau, cùng một số tính năng của GitHub Actions liên tục xuất hiện:

1. Trigger nguy hiểm: pull_request_target và issue_comment chạy các workflow không đáng tin cậy với toàn quyền bí mật.
2. Mở rộng template: Cú pháp $ thực hiện thay thế văn bản vào các script shell không có dấu ngoặc kép an toàn.
3. Quyền mặc định: GITHUB_TOKEN mặc định có quyền ghi (write) trên bất kỳ kho lưu trữ nào được tạo trước tháng 2/2023.
4. Thẻ git có thể thay đổi: Các phiên bản action là các tham chiếu git có thể bị force-push bởi bất kỳ ai có quyền ghi, và được tiêu thụ theo mặc định thông qua một thẻ di động thay vì băm nội dung.
5. Bộ nhớ đệm: Cache chéo qua ranh giới tin cậy một cách âm thầm.

Niềm tin vào "Trusted Publishing" và OIDC

Lý do khiến vấn đề này trở nên đáng lo ngại hơn cả là các sổ đăng ký gói (PyPI, npm, RubyGems, crates.io) đều đã đặt cược vào GitHub Actions thông qua tính năng xuất bản đáng tin cậy dựa trên OIDC. Mục tiêu là loại bỏ các token API tồn tại lâu, nhưng điều này đồng nghĩa với việc đảm bảo tính toàn vẹn của các sổ đăng ký giờ đây phụ thuộc hoàn toàn vào quy trình GitHub Actions.

Chúng ta đã dành một thập kỷ để củng cố các trình quản lý gói với lockfile, 2FA, chữ ký và nhật ký kiểm toán, nhưng việc kết nối tất cả với OIDC đã chuyển sự tin cậy từ hàng nghìn thông tin xác thực của người duy trì sang một nền tảng CI không có bất kỳ thuộc tính bảo mật nào trong số đó.

Khuyến nghị và giải pháp

GitHub đã công bố lộ trình bảo mật với các bản sửa lỗi thực tế như tệp khóa workflow (lockfile), kiểm soát chính sách và tường lửa egress. Tuy nhiên, mọi thứ đều ở chế độ "tùy chọn" (opt-in) và "xem trước công khai" trong vài tháng tới. Việc thay đổi các cấu hình mặc định sẽ phá vỡ các workflow hiện tại, nhưng các workflow hiện tại chính là thứ liên tục gây ra sự cố.

Cho đến khi GitHub sẵn sàng thực hiện những thay đổi mang tính phá vỡ để bảo mật tốt hơn, các nhà phát triển cần tự bảo vệ mình:

• Sử dụng công cụ quét: Thêm zizmorcore/zizmor-action vào kho lưu trữ để phát hiện các cấu hình nguy hiểm.
• Ghim băm SHA: Luôn sử dụng băm SHA cố định cho các action bên thứ ba thay vì thẻ di động (ví dụ: @v1).
• Hạn chế quyền: Đặt permissions: {} ở đầu mỗi tệp workflow để giới hạn quyền của token.
• Cảnh giác: Hãy giả định rằng bất kỳ thứ gì người dùng chưa xác thực có thể đưa vào tiêu đề PR, tên nhánh hoặc bình luận vấn đề cuối cùng sẽ trở thành một script shell.

Nếu không thực hiện các biện pháp này, sớm hay muộn, kho lưu trữ của bạn sẽ trở thành mắt xích yếu nhất trong chuỗi cung ứng.