Câu hỏi thật sự là: giữa commit và container đang chạy có khoảng trống tin cậy nào không. Nếu bất kỳ ai push được image lên registry, hoặc CI cho phép chạy script tuỳ ý với quyền ký, thì việc review code kỹ tới đâu cũng không bảo đảm được thứ chạy trên production.
SLSA là khung chuẩn hoá câu trả lời, dựa trên provenance — một tài liệu do hệ thống build ký, ghi lại: build từ commit nào, bằng workflow nào, với input gì, ra artifact có digest bao nhiêu.
Các mức (SLSA v1.0, track Build):
- L1: có provenance, sinh tự động, người dùng xem được. Đã chặn được nhóm sai sót vô ý.
- L2: provenance được ký bởi một dịch vụ build được host, có thể xác minh chữ ký.
- L3: build chạy trong môi trường cách ly, không giả mạo được — khoá ký nằm ngoài tầm với của tiến trình build, nên một bước build bị chiếm quyền không thể tự ký provenance giả.
Việc cụ thể trong một dự án bình thường:
- Chỉ build và deploy từ CI, cấm push image thủ công lên registry production.
- Sinh provenance và ký artifact (Sigstore/cosign, hoặc attestations của GitHub Actions) — nhớ rằng chỉ ký thôi chưa đủ, phải có bước xác minh lúc deploy, nếu không chữ ký chỉ là trang trí.
- Pin action/base image theo digest thay vì tag di động, và giới hạn quyền GITHUB_TOKEN xuống mức tối thiểu.
- Bảo vệ nhánh: bắt buộc review, cấm force-push vào nhánh phát hành.
- Sinh SBOM để khi có CVE mới còn tra được artifact nào chứa thư viện đó.
Mức đầu tư nên tương xứng: L1 gần như miễn phí và nên có ở mọi dự án; L3 phù hợp với thứ mà người khác cài đặt và tin tưởng.