GitHub Action bị tấn công phơi bày rủi ro trong chuỗi cung ứng CI/CD

Một GitHub Action phổ biến bị tấn công, phơi bày lỗ hổng bảo mật nghiêm trọng trong chuỗi cung ứng mã nguồn mở

Một trong những GitHub Action được sử dụng rộng rãi, xuất hiện trong hàng nghìn repository, đã bất ngờ trở thành công cụ tấn công và làm lộ rõ một lỗ hổng nghiêm trọng trong quy trình xuất bản và tiêu thụ các Action mã nguồn mở. Sự cố này không chỉ khiến cộng đồng phát triển phần mềm bàng hoàng, mà còn đặt ra câu hỏi lớn về bảo mật trong quy trình tích hợp và triển khai liên tục (CI/CD) trên nền tảng GitHub Actions.

Vào tháng 3/2025, một người bảo trì mới của tj-actions/changed-files — một Action nổi tiếng giúp kiểm tra sự thay đổi tệp tin trong các pull request — đã bí mật phát hành phiên bản v44 chứa đoạn mã shell bị làm rối, có khả năng thực thi lệnh từ xa. Dù thời gian phát tán của phiên bản độc hại này khá ngắn, nhưng nó đã đủ để qua mặt nhiều quy trình kiểm tra và làm lộ rõ điểm yếu trong cách các nhà phát triển đặt niềm tin vào các Action được cung cấp sẵn trên GitHub.

Vấn đề này được phát hiện khi người dùng nhận thấy phiên bản mới chứa đoạn mã curl | bash — một mô-típ vốn từ lâu được cảnh báo là có nguy cơ cao cho phép thực thi mã từ xa. Nhóm bảo mật của StepSecurity đã nhanh chóng phân tích và xác nhận payload này có thể thu thập dữ liệu nhạy cảm từ các runner của GitHub. Ngay sau đó, phiên bản độc hại đã bị gỡ bỏ, repository được khôi phục, và hàng loạt dự án bị ảnh hưởng phải tạm ngưng CI để tiến hành kiểm tra và rà soát bảo mật.

Điều khiến sự cố này trở nên nghiêm trọng không chỉ nằm ở việc hơn 20.000 repository từng sử dụng Action này, mà còn vì nó cho thấy một lỗ hổng mang tính hệ thống: cộng đồng lập trình viên đang quá tin tưởng vào các Action như thể chúng là những thành phần an toàn sẵn có, trong khi thực tế chúng không hề có những biện pháp kiểm soát nghiêm ngặt như gói npm, container hay thư viện phần mềm, đặc biệt trong các khâu xác thực danh tính, kiểm tra chữ ký số và kiểm soát quyền sở hữu.

Ngay sau sự cố, các chuyên gia bảo mật và cộng đồng mã nguồn mở đã đồng loạt chia sẻ các biện pháp giảm thiểu rủi ro. StepSecurity khuyến cáo các dự án nên pin các Action vào SHA cụ thể thay vì chỉ sử dụng theo tag phiên bản, nhằm đảm bảo tính tái lập và tránh rủi ro bị thay đổi nội dung Action từ phía tác giả. Ngoài ra, họ cũng đề xuất củng cố các runner của GitHub bằng cách giới hạn quyền truy cập mạng, thu hẹp phạm vi của biến môi trường, và giảm thiểu quyền cấp phát không cần thiết.

Vụ việc này cũng tái khẳng định mối lo ngại về chuỗi cung ứng bảo mật trong CI/CD pipelines, một chủ đề đang thu hút sự quan tâm ngày càng lớn của giới công nghệ. Mặc dù các nhóm kỹ sư đã quen với việc quét kiểm tra lỗ hổng trong mã nguồn, rà soát thư viện phụ thuộc hoặc áp dụng phân tích tĩnh, thì các công cụ trong quy trình CI/CD như GitHub Actions lại thường bị bỏ ngỏ. Trong bối cảnh GitHub Actions có thể được cấp quyền cao, từ việc ký release, đẩy image Docker cho đến triển khai vào môi trường sản xuất, việc một Action bị xâm nhập có thể phá vỡ toàn bộ pipeline, gây hậu quả nghiêm trọng cho tổ chức.

Tuy chưa có con số cụ thể về số lượng Action không được pin SHA trong thực tế, nhưng StepSecurity nhấn mạnh rằng hành vi sử dụng Action mà không kiểm soát phiên bản là rủi ro rất cao và cần đặc biệt cẩn trọng.

Sự việc lần này cũng phản ánh một vấn đề đã từng xảy ra trong các hệ sinh thái lân cận, như gói npm độc hại hay Docker Image bị trojan hóa. Dù ngành công nghiệp đã có những bước tiến nhờ các sáng kiến như SLSA, Sigstore và SBOM, GitHub Actions vẫn còn thiếu những công cụ tiêu chuẩn cho việc xác thực nguồn gốc, sandboxing hoặc kiểm soát độ tin cậy đối với các Action có thể tái sử dụng.

Trước bối cảnh này, nhiều nhóm kỹ sư tại các doanh nghiệp lớn như Salesforce đã bắt đầu xây dựng quy trình đánh giá nội bộ cho Action của bên thứ ba, xác lập tiêu chuẩn về niềm tin và yêu cầu đánh giá trước khi tích hợp vào hệ thống CI/CD. Đây được coi là một hướng đi mới, cho thấy cộng đồng đang dần nhận thức rõ tầm quan trọng của việc quản lý bảo mật CI/CD giống như cách họ từng làm đối với thư viện phần mềm và gói phụ thuộc trong ứng dụng.