GitHub Actions hỗ trợ lockfile chống tấn công chuỗi cung ứng

GitHub Actions vừa bổ sung tính năng lockfile cho workflow (workflow lockfile). Đây là thay đổi đáng chú ý với các nhóm phát triển phần mềm, bởi từ trước đến nay cách phòng thủ phổ biến là ghim (pin) mỗi action vào một mã SHA đầy đủ — vừa khó đọc, vừa khó bảo trì.

Lý do của cách làm cũ rất rõ ràng: action trên GitHub Actions được tải về từ Git, và các tag trong Git có thể bị di chuyển. Kẻ tấn công có thể trỏ một tag từng an toàn sang mã độc, tạo ra nguy cơ tấn công chuỗi cung ứng (supply-chain attack). Vì vậy lời khuyên trước đây là ghim vào SHA thay vì tag.

Thiết lập lockfile như thế nào

Bước đầu tiên là cài tiện ích mở rộng gh-actions-lock cho công cụ dòng lệnh gh:

$ gh extension install github/gh-actions-lock
✓ Installed extension github/gh-actions-lock

Sau đó, chạy trong kho mã nguồn (repository):

$ gh actions-lock
✓ All 1 workflows valid

Thay vì ghim SHA dài dòng, workflow giờ có thể dùng tag phiên bản dạng vX.Y.Z:

• actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 → actions/[email protected]
• j178/prek-action@44924fe9ef4a6f88253c4b6b1bf11c689d3ce53d # v3.1.0 → j178/[email protected]

Công cụ đồng thời sinh ra một file lockfile tại .github/workflows/actions.lock, ghi lại với mỗi tag là tham chiếu gốc (ref), mã commit tương ứng (sha1-...) cùng owner_id và repo_id. Lockfile do máy sinh, không chỉnh tay, mà chạy lại gh actions-lock để cập nhật. Phiên bản lockfile trong ví dụ là v0.0.3.

Renovate và Dependabot

Cả Renovate và Dependabot đều đã hỗ trợ lockfile. Các bản cập nhật định kỳ của chúng cũng cập nhật luôn lockfile — người dùng chỉ cần nhớ dùng cooldowns (khoảng chờ giữa các lần nâng cấp).

Kiểm tra lockfile trên CI

GitHub khuyến nghị xác thực lockfile trong CI (tích hợp liên tục) để bảo đảm file còn khớp và không bị hỏng. Có thể đặt bước kiểm tra vào một job riêng, chạy song song và độc lập:

permissions: {}
...
lockfile:
  runs-on: ubuntu-slim
  env:
    GH_TOKEN: ${{ github.token }}
  steps:
    - uses: actions/[email protected]
      with:
        persist-credentials: false
    - run: gh extension install github/gh-actions-lock --pin v0.4.1
    - run: gh actions-lock --verify

Job này thất bại khi .github/workflows/actions.lock lệch với các workflow, hoặc khi một ghim đã khóa không còn xác thực được với nguồn gốc. Lưu ý: runner nhẹ ubuntu-slim được dùng ở đây, và extension được ghim ở v0.4.1 — con số này cần cập nhật theo thời gian hoặc tự động hóa sau.

Đừng quên rằng sau khi sửa action trong workflow, cần chạy lại gh actions-lock để khóa lại. Nếu chỉ thêm vào file đã có thì không có gì thay đổi (ví dụ actions/checkout đã được khóa), nhưng nếu tạo file mới như verify-lockfile.yml thì phải khóa lại cho file đó — CI sẽ báo nếu thiếu.

zizmor — linter bảo mật

zizmor là công cụ lint bảo mật cho GitHub Actions và được khuyến nghị mạnh mẽ. Các phiên bản trước v1.32.0 khuyên ghim action bằng hash, còn v1.32.0 là bản đầu tiên hỗ trợ lockfile. Trong ví dụ, zizmor được thêm vào .pre-commit-config.yaml với rev: v1.32.0.

Góc nhìn

Với các kỹ sư DevOps và lập trình viên Việt Nam đang vận hành CI/CD trên GitHub Actions, lockfile giải quyết được một điểm đau cũ: vừa muốn bảo mật bằng cách ghim SHA, vừa muốn dễ đọc và dễ nâng cấp. Việc tag trong workflow trở nên có thể đọc được giúp review code dễ hơn, còn phần SHA vẫn được giữ trong lockfile để chặn tấn công chuỗi cung ứng.

Bài học thực tế là hãy đưa việc xác thực lockfile vào pipeline ngay từ đầu và bật các công cụ như zizmor, thay vì chỉ dựa vào thói quen ghim thủ công. Kèm theo đó, các công cụ cập nhật tự động như Renovate hay Dependabot sẽ giúp nhóm không bị kẹt ở phiên bản cũ — một rủi ro bảo mật không kém gì việc dùng tag có thể bị di chuyển.