Khi một lỗ hổng nghiêm trọng trong một thư viện phổ biến được công bố, câu hỏi đầu tiên của mọi đội vận hành là ba câu gộp làm một: chúng ta có dùng nó không, ở đâu, phiên bản nào? Đội trả lời được trong vài phút thì vá xong trước khi kẻ tấn công kịp quét tới. Đội không trả lời được sẽ mất vài ngày mò mẫm — và vài ngày đó là khoảng thời gian hệ thống phơi lưng.
Sự cố Log4Shell cuối năm 2021 là bài học đắt: một lỗ hổng trong một thư viện ghi log Java có mặt ở khắp nơi, và vô số tổ chức đơn giản là không biết mình có dùng nó hay không, vì nó nằm sâu vài tầng bên dưới, kéo theo bởi một thứ khác mà họ chủ động cài. Không biết mình có gì là điểm yếu lớn nhất.
SBOM là gì
SBOM — danh mục thành phần phần mềm — là một bản kê máy đọc được liệt kê mọi thành phần trong một bản dựng: tên, phiên bản, giấy phép, nguồn gốc, và quan hệ phụ thuộc giữa chúng. Nó giống bảng thành phần in trên vỏ hộp thực phẩm, nhưng cho phần mềm. Hai định dạng phổ biến là SPDX và CycloneDX, cả hai đều mở và có công cụ đọc sẵn.
Điểm mấu chốt dễ làm sai: SBOM phải được sinh ra tự động trong lúc dựng, như một sản phẩm phụ của quy trình build. Một danh mục viết tay sẽ lỗi thời ngay tuần sau, khi ai đó nâng một thư viện — và một SBOM lỗi thời còn nguy hiểm hơn không có, vì nó tạo cảm giác an toàn giả.
Chữ ký giải một bài toán khác
SBOM cho biết bên trong có gì. Chữ ký số cho biết thứ bạn nhận đúng là thứ bên phát hành tạo ra và chưa bị ai sửa dọc đường. Hai thứ bổ sung nhau chứ không thay thế: một SBOM chính xác về một gói đã bị chèn mã độc trên đường vận chuyển thì vô nghĩa; một chữ ký hợp lệ trên một gói mà bạn không biết bên trong có gì cũng vậy.
Cách ký hiện đại đã bỏ được gánh nặng lớn nhất của kiểu cũ — bảo quản khoá riêng an toàn trong nhiều năm. Thay vào đó, nó gắn danh tính người phát hành với một khoá dùng một lần rồi vứt, và ghi lại toàn bộ vào một nhật ký công khai không sửa được, nên ai cũng kiểm chứng được về sau mà không bên nào phải giữ bí mật lâu dài.
Vì sao chuỗi phụ thuộc mới là chỗ đáng lo
Thứ bạn chủ động cài chỉ là phần nổi. Mỗi thư viện lại kéo theo hàng chục thư viện khác, và chúng lại kéo theo nữa — một dự án tưởng chừng dùng mười gói thực chất đang chạy hàng trăm. Kẻ tấn công hiểu điều này: chèn mã độc vào một gói nhỏ nằm sâu ba tầng bên dưới còn hiệu quả hơn tấn công thẳng, vì không ai nhìn tới đó. SBOM có giá trị chính vì nó soi được vào phần chìm này.
Bắt đầu ở mức tối thiểu
- Sinh SBOM tự động trong quy trình dựng và lưu kèm mỗi bản phát hành.
- Ký ảnh container và tệp cài đặt.
- Dựng sẵn khả năng tra cứu ngược: "thành phần X phiên bản Y đang chạy ở những đâu" phải trả lời được bằng một truy vấn, không phải bằng một cuộc điều tra.
Toàn bộ công sức này không mang lại lợi ích nào nhìn thấy trong ngày thường — đó là lý do nó hay bị hoãn. Nhưng vào cái ngày một lỗ hổng lớn nổ ra, nó là khác biệt giữa vá xong trong một buổi chiều và mất cả tuần không ngủ.
Thảo luận