SBOM: trả lời được "chúng ta có dùng cái đó không?"

Tháng 12/2021, Log4Shell được công bố. Điều phân biệt các nhóm không phải kỹ năng bảo mật mà là một câu hỏi rất đơn giản: "chúng ta có dùng log4j ở đâu không?"

Nhóm trả lời được trong mười phút thì vá xong trong một ngày. Nhóm không trả lời được thì mất hai tuần đi tìm — grep từng repo, hỏi từng nhóm, mở từng image. Và trong hai tuần đó họ không biết mình có đang bị khai thác hay không.

SBOM (Software Bill of Materials) là danh sách mọi thành phần trong một artifact cụ thể, kèm phiên bản và nguồn gốc. Nó tồn tại để trả lời đúng câu hỏi đó.

Điều làm SBOM khác một file lockfile, và đây là chỗ hay bị nhầm:

Trả lời câu hỏi | "Chúng ta khai dùng gì" | "Artifact này chứa gì" | Bao gồm | Package của một hệ sinh thái | Cả package OS, thư viện native, base image | Gắn với | Một commit trong source | Một artifact đã build | Tồn tại ở | Repo | Cạnh artifact trong registry |

Hàng cuối là hàng quan trọng nhất và hay bị làm sai: SBOM phải đi cùng artifact, không nằm trong repo. Một SBOM trong repo trả lời "commit này khai dùng gì"; một SBOM cạnh image trong registry trả lời "cái đang chạy ở production chứa gì" — và đó là câu hỏi bạn cần lúc 2 giờ sáng.

Hai định dạng, và với hầu hết trường hợp thì chọn cái nào không quan trọng bằng việc có một cái:

• CycloneDX — gọn hơn, thiên về bảo mật, hỗ trợ VEX tốt. Đây là lựa chọn mặc định hợp lý.
• SPDX — chuẩn ISO, mạnh về giấy phép, hay được yêu cầu trong hợp đồng chính phủ.

Và một thứ đi kèm mà ít ai làm: VEX (Vulnerability Exploitability eXchange) — một tài liệu nói "chúng ta có CVE này nhưng nó không tiếp cận được, và đây là lý do". Nó là cách bạn ghi lại kết luận của bài dependency-risk sao cho lần quét sau không hỏi lại.