Thảm họa từ những thứ “vô hình” trong container
2 giờ sáng. Chuông điện thoại reo dồn dập. Team Security gửi thông báo khẩn: “Phát hiện lỗ hổng Log4j đang chạy trên Production”. Mình bật dậy, mồ hôi hột chảy dài. Cái khó lúc này không phải là cách fix. Vấn đề là làm sao tìm ra chính xác microservice nào đang “ôm” cái thư viện độc hại đó giữa hàng trăm container đang chạy?
Server của mình từng bị brute-force SSH nên mình luôn setup bảo mật rất kỹ từ đầu. Nhưng lần này lại khác. Lỗ hổng không nằm ở cấu hình server mà nằm sâu trong đống dependency (thư viện phụ thuộc) mà dev cài vào. Nhìn vào Dockerfile, mọi thứ có vẻ sạch sẽ. Thế nhưng, ẩn sau các layer image là cả một “mớ bòng bong” package mà bạn gần như không thể kiểm soát thủ công.
Đây chính là lúc SBOM (Software Bill of Materials) lên ngôi. Hãy coi nó là một bản danh mục chi tiết mọi thành phần cấu tạo nên phần mềm. Để quản lý SBOM chuyên nghiệp như một SRE thực thụ, bạn nhất định phải biết bộ đôi: Syft và Grype.
SBOM, Syft và Grype: Hiểu đúng để dùng trúng
Hãy tưởng tượng SBOM giống như bảng thành phần trên gói mì tôm. Nó cho bạn biết chính xác có bao nhiêu muối, bột ngọt hay chất bảo quản. Trong kỹ thuật, SBOM liệt kê tên library, version, license và cả các dependency bắc cầu (transitive dependencies) — thứ mà bạn không trực tiếp cài nhưng vẫn xuất hiện trong code.
- Syft: Công cụ này đóng vai trò “máy scan”. Nó quét container image hoặc source code để trích xuất ra SBOM. Tốc độ của Syft cực nhanh, thường chỉ mất 5-10 giây cho một image nặng vài trăm MB.
- Grype: Nếu Syft là máy scan, Grype chính là “chuyên gia giám định”. Nó lấy danh sách từ SBOM để đối chiếu với các database lỗ hổng bảo mật toàn cầu (CVE).
Cặp bài trùng này tạo nên lá chắn vững chắc cho chuỗi cung ứng phần mềm (Software Supply Chain). Bạn biết mình đang có gì và biết cái mình có có đang “nhiễm độc” hay không.
Triển khai thực tế: Kiểm soát dependency trong 5 phút
1. Cài đặt công cụ
Cả hai đều do Anchore phát triển nên việc cài đặt trên Linux cực kỳ nhanh gọn qua script chính thức:
# Cài đặt Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# Cài đặt Grype
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Gõ syft --version để kiểm tra. Nếu hiện version là bạn đã sẵn sàng lên nòng.
2. Xuất SBOM đầu tiên
Thử soi nội tạng một container image bất kỳ, ví dụ nginx:latest:
syft nginx:latest
Bạn sẽ thấy hàng chục, thậm chí hàng trăm package hiện ra. Để lưu trữ lâu dài hoặc dùng cho các công cụ khác, mình khuyên bạn nên xuất ra định dạng chuẩn như JSON hoặc CycloneDX:
syft webapp:v1.0 -o json > webapp-sbom.json
File JSON này chính là “giấy khai sinh” của container. Khi có một lỗ hổng mới (như Log4j hay Heartbleed), bạn chỉ cần grep trong file này là biết mình có dính đòn hay không. Không cần SSH vào server, không cần chạy lại container.
3. Truy tìm lỗ hổng với Grype
Bây giờ, hãy để Grype làm việc. Nó sẽ tự động tải database lỗ hổng mới nhất về máy rồi mới tiến hành quét.
grype webapp:v1.0
Kết quả sẽ phân loại theo mức độ: Low, Medium, High, Critical. Nếu thấy dòng nào hiện Critical kèm mã CVE, đó là báo động đỏ yêu cầu bạn phải update ngay.
Một mẹo nhỏ cho anh em: Thay vì quét image (tốn băng thông), hãy quét trực tiếp file SBOM đã tạo ở bước trên:
grype sbom:./webapp-sbom.json
4. Quy trình xử lý khi phát hiện “biến”
Đừng hoảng khi thấy danh sách lỗ hổng dài dằng dặc. Hãy tập trung vào cột “Fixed In”. Đây là phiên bản an toàn bạn cần nâng cấp lên. Quy trình của mình thường là: Xác định package lỗi -> Cập nhật package.json hoặc Dockerfile -> Build lại image -> Quét lại lần cuối.
Tự động hóa: Đừng đợi nước đến chân mới nhảy
Sai lầm chí mạng là chỉ scan khi nhớ ra. Hãy biến bảo mật thành một phần của pipeline (Shift-left Security). Mỗi khi dev push code, hệ thống phải tự động tạo SBOM và quét lỗi ngay lập tức.
Dưới đây là cách mình cấu hình GitHub Actions để chặn đứng các image có lỗi nghiêm trọng:
- name: Scan image
uses: anchore/scan-action@v3
with:
image: "webapp:latest"
fail-build: true
severity-cutoff: critical
Với fail-build: true, nếu phát hiện lỗi Critical, pipeline sẽ dừng lại ngay lập tức. Code lỗi không bao giờ được phép bén mảng lên Production. Nhờ vậy, mình có thể kê cao gối ngủ mà không lo chuông điện thoại reo lúc nửa đêm.
Lời kết
Bảo mật không phải là đích đến mà là một hành trình kiểm soát liên tục. Nắm giữ Syft và Grype trong tay, bạn sẽ có cái nhìn thấu thị vào bên trong hệ thống. SBOM không đơn thuần là yêu cầu tuân thủ bảo mật khô khan, nó là công cụ phản ứng nhanh trước mọi cuộc tấn công vào chuỗi cung ứng. Hãy tập thói quen tạo SBOM ngay hôm nay. Chúc anh em quản lý hệ thống an toàn và luôn ngủ ngon giấc!

