Google cập nhật hướng dẫn giảm rủi ro chuỗi cung ứng phần mềm nguồn mở

GTIG cho biết các sự cố chuỗi cung ứng nguồn mở có tác động lớn mà họ theo dõi trong 2025 và đầu 2026 chủ yếu liên quan code repository, dependency và developer tool. Nhóm đánh giá với mức tin cậy cao rằng các campaign quy mô rất lớn đã gia tăng so với trước và có thể tiếp tục được bắt chước.

Đây là đánh giá threat intelligence của Google, không phải thống kê đầy đủ toàn thị trường. Bài gốc đưa ra nhiều lớp giảm thiểu: asset/dependency inventory, SBOM/ABOM, identity ngắn hạn, isolated runner, workflow governance, internal registry/quarantine, SCA, artifact integrity, egress monitoring và playbook ứng phó.

Hướng dẫn không chỉ yêu cầu “quét dependency”. Nó đặt trọng tâm vào attack chain: maintainer/account bị chiếm, token CI/CD quá quyền, workflow trigger nguy hiểm, install script, runner tồn tại lâu, egress rộng và artifact thiếu provenance có thể nối thành một đường khai thác.

GTIG đề cập cooldown/quarantine cho package mới, private index, short-lived identity qua OIDC/GitHub App, ephemeral runner, kiểm soát pull_request_target, hạn chế lifecycle script và SBOM liên tục. Các giá trị thời gian/cấu hình trong bài gốc là khuyến nghị theo bối cảnh; tổ chức phải kiểm tra package manager/version vì tool cũ có thể không thực thi control giống nhau.

Kiến trúc CI/CD cần vẽ trust boundary từ developer workstation, VCS, action/plugin, package registry, runner, secret store, artifact repository tới deployment. Với mỗi bước, ghi identity, network egress, artifact và log. “Private registry” không đủ nếu nó tự động mirror package mới không quarantine.

Kiểm thử nên dùng gói benign/canary trong sandbox: package mới có bị giữ; install script có bị chặn; runner có bị xóa; token có hết hạn và scope tối thiểu; artifact không ký có bị reject; egress tới domain ngoài allow-list có alert. Không đưa dependency độc hại thật vào production pipeline.

• DevSecOps/platform engineering quản lý pipeline và runner.
• Application team dùng npm, PyPI, container hoặc action/plugin bên thứ ba.
• IAM quản lý token, OIDC, signing key và workload identity.
• SOC theo dõi repository, build, registry và egress anomaly.
• Procurement/risk quản lý vendor, SLA thông báo và audit right.

Không thể kết luận một package hoặc pipeline cụ thể bị xâm nhập chỉ từ báo cáo xu hướng. Cũng không thể coi SBOM, SCA hoặc cooldown đơn lẻ là giải pháp hoàn chỉnh: package chưa có CVE, maintainer bị chiếm hoặc pipeline token bị lộ có thể vượt một lớp kiểm soát.

Các con số campaign/impact trong nguồn gắn với quan sát của GTIG; NetVali không xác minh độc lập. Khuyến nghị cấu hình phải được thử với exact npm/pnpm/pip/GitHub/GitLab/Jenkins version và workflow của tổ chức.

Ưu tiên đầu tiên: inventory pipeline/action/package; rotate/reduce long-lived token; chặn runner production truy cập bí mật không cần thiết; cố định dependency/lockfile; centralize registry; lưu provenance và log. Sau đó mới tối ưu automation.

• Kiểm soát: Dependency inventory · Bài kiểm chứng: Sinh SBOM và đối chiếu deployed artifact · Bằng chứng: SBOM + artifact digest
• Kiểm soát: Quarantine/cooldown · Bài kiểm chứng: Publish package canary mới · Bằng chứng: Policy decision/log
• Kiểm soát: Token/OIDC · Bài kiểm chứng: Thử token hết hạn/quá scope · Bằng chứng: Deny + audit event
• Kiểm soát: Ephemeral runner · Bài kiểm chứng: Kiểm tra state/secret sau job · Bằng chứng: Runner lifecycle log
• Kiểm soát: Install script · Bài kiểm chứng: Package benign có post-install · Bằng chứng: Block/allow-list result
• Kiểm soát: Artifact integrity · Bài kiểm chứng: Deploy artifact unsigned/changed · Bằng chứng: Admission reject
• Kiểm soát: Egress · Bài kiểm chứng: Canary kết nối domain ngoài allow-list · Bằng chứng: Firewall/proxy alert
• Kiểm soát: Incident response · Bài kiểm chứng: Tabletop maintainer takeover · Bằng chứng: Owner, RTO, revoke plan