Google cảnh báo CI/CD bị nhắm: cache poisoning, OIDC token và action tag mutable

Bài viết này do AI tạo ra, có thể mắc sai sót.

Google Cloud Threat Intelligence cảnh báo chuỗi cung ứng phần mềm đang bị nhắm trực tiếp vào công cụ được tin cậy trong vòng đời phát triển: scanner bảo mật, thư viện tiện ích, AI developer tool, IDE và pipeline CI/CD. Trọng tâm phòng thủ không phải một công cụ đơn lẻ mà là giảm đặc quyền, kiểm soát artefact và duy trì bằng chứng cho từng lần build.

Tóm tắt nhanh

Pipeline là mục tiêu giá trị cao: attacker tìm cách tận dụng quyền cao của công cụ build và phát hành.
Máy lập trình viên vẫn là điểm vào: social engineering, extension độc hại và dependency typosquat nhắm khóa, API token, session credential.
Kỹ thuật đã vượt static secret: cache poisoning GitHub Actions, trích OIDC token và action tag mutable có thể làm sai chuỗi phát hành.
Chữ ký không đủ: package bị xâm phạm vẫn có thể mang provenance hợp lệ nếu pipeline nguồn đã bị chiếm.

Vì sao CI/CD bị nhắm?

Pipeline thường có quyền đọc source riêng, gọi cloud API, ký artefact và phát hành package. Một lần chiếm được runner, credential hoặc workflow có thể biến commit hợp lệ thành bản phát hành độc hại. Vì vậy mức đặc quyền của từng job phải bị giới hạn theo nhiệm vụ, không chia sẻ token dài hạn giữa các môi trường.

Ba đường tấn công cần ưu tiên

Google nêu việc nhắm scanner, thư viện và AI tool; xâm phạm IDE qua phishing, extension hoặc dependency giả; và thao túng pipeline bằng cache poisoning, OIDC token extraction hay mutable action tag. Điểm chung là attacker không nhất thiết phá mã nguồn chính: họ đổi môi trường tạo hoặc đường phân phối artefact.

Checklist hardening thực dụng

Pin action theo commit SHA thay vì tag mutable; kiểm soát action bên thứ ba.
Dùng OIDC với policy chặt, audience/subject rõ ràng; tránh secret cloud sống lâu.
Tách quyền build, deploy và release; runner production không dùng chung với PR không tin cậy.
Khoá cache theo scope, không restore cache từ fork hoặc nhánh không được tin cậy.
Bật MFA, bảo vệ branch, review workflow và log audit cho thay đổi CI.
Ký, tạo SBOM/provenance, rồi xác minh ở bước deploy thay vì chỉ tạo chúng.

Phân tích

Bài học khó là “provenance hợp lệ” không đồng nghĩa artefact an toàn nếu runner, action hoặc credential tạo provenance đã bị chiếm. Đội DevSecOps nên coi workflow như production code: code review, test thay đổi, quyền tối thiểu và alert cho hành vi phát hành bất thường.

Ưu tiên ngay là rà job có quyền cloud hoặc publish, kiểm tra action chưa pin SHA, scope cache và token có thể đọc secret. Các việc này giảm blast radius nhanh hơn việc chỉ bổ sung thêm scanner.