SBOM (Software Bill of Materials)
1. Tổng quan
A. Định nghĩa
Bản đặc tả liệt kê ở dạng máy đọc được toàn bộ thành phần, thư viện và phụ thuộc cấu thành phần mềm cùng với thông tin phiên bản, giấy phép và nhà cung cấp của chúng. Mượn khái niệm từ bản kê vật tư (BOM) của ngành chế tạo, đây là sản phẩm cốt lõi của an ninh chuỗi cung ứng phần mềm (SSC, Software Supply Chain).
Tôn chỉ căn bản của SBOM nằm ở mệnh đề "không thấy được thì không quản lý được (You can't secure what you can't see)". Trong ứng dụng hiện đại, 70–90% mã không phải do lập trình viên tự viết mà được lấp đầy bằng thành phần mã nguồn mở và bên thứ ba, song hầu hết tổ chức thậm chí không có cả một danh mục về những gì và bao nhiêu nằm bên trong. SBOM làm rõ tường minh "bảng thành phần của phần mềm" (thường được ví như bảng thành phần dinh dưỡng thực phẩm), nâng các rủi ro lỗ hổng và giấy phép—vốn nằm trong điểm mù quản lý—lên thành đối tượng có thể quản lý.
Điểm cốt lõi là SBOM không đơn thuần là tài liệu mà là cấu trúc dữ liệu có thể tự động hóa. Nếu chỉ dừng ở một danh mục cho người đọc, việc đối chiếu hàng trăm thành phần với cơ sở dữ liệu lỗ hổng cập nhật hằng ngày là bất khả thi. Do đó, SBOM chỉ đạt được tính thực hiệu khi được viết ở định dạng chuẩn mà công cụ có thể phân tích, đối chiếu và kiểm chứng.
B. Bối cảnh ra đời và sự cần thiết
Khi phụ thuộc mã nguồn mở bùng nổ, một ứng dụng đơn lẻ phụ thuộc trực tiếp và gián tiếp vào hàng trăm đến hàng nghìn thành phần, và các sự cố lớn liên tiếp xảy ra khi một lỗi ẩn sâu bên trong lan ra toàn bộ chuỗi cung ứng. Tiêu biểu là sự cố SolarWinds (2020), làm nhiễm chính hệ thống build để phát tán mã độc trên các bản cập nhật được ký hợp lệ, và Log4Shell (Log4j, 2021, CVE-2021-44228), một lỗ hổng thực thi mã từ xa trong thư viện ghi log Java được dùng rộng rãi.
Đặc biệt trong sự kiện Log4Shell, vô số tổ chức trễ nải phản ứng ban đầu hàng ngày vì "thậm chí không thể xác định hệ thống của mình có dùng Log4j hay không, và nếu có thì phiên bản nào ở đâu". Nếu đã có SBOM, họ đã có thể tức thời nhận diện phạm vi ảnh hưởng chỉ với một truy vấn và vá theo thứ tự ưu tiên. Sự cố này khắc sâu giá trị của SBOM vào toàn ngành. Trong bối cảnh đó, Hoa Kỳ đã bắt buộc nộp SBOM đối với phần mềm cung cấp cho chính phủ liên bang thông qua sắc lệnh hành pháp EO 14028 (2021), sau đó lan nhanh vào quy định của các nước và tiêu chuẩn ngành.
2. Thành phần SBOM, định dạng chuẩn và các tầng tạo lập
A. Thành phần và định dạng chuẩn
Để SBOM có tính thực hiệu, nó phải được công cụ chứ không phải con người diễn giải tự động, nên việc viết nó ở định dạng chuẩn máy đọc được là quan trọng. Chỉ khi định dạng được chuẩn hóa mới có thể trao đổi SBOM giữa các tổ chức và công cụ khác nhau, đối chiếu tự động với cơ sở dữ liệu lỗ hổng, và kiểm chứng ngược lên chuỗi cung ứng.
| Phân loại | Nội dung |
|---|---|
| Thành phần | Tên·phiên bản thành phần, nhà cung cấp, quan hệ phụ thuộc, giấy phép, hash (kiểm chứng toàn vẹn) |
| Định dạng chuẩn | SPDX (Linux Foundation, chuẩn ISO), CycloneDX (OWASP, chuyên về bảo mật), SWID |
NTIA thuộc Bộ Thương mại Hoa Kỳ đã quy định các yếu tố tối thiểu (minimum elements) mà SBOM phải có: tên nhà cung cấp, tên thành phần, phiên bản, định danh duy nhất, quan hệ phụ thuộc, tác giả SBOM và dấu thời gian. Các yếu tố tối thiểu này tạo nền chung để đối chiếu và hợp nhất các SBOM khác nhau. Làm định danh duy nhất của thành phần, người ta dùng PURL (Package URL) hoặc CPE (Common Platform Enumeration), vì chỉ khi ký hiệu được chuẩn hóa mới có thể phán đoán mà không dương tính giả "thành phần này có giống đối tượng của CVE đó không?".
Tính chất theo định dạng cũng khác nhau. SPDX mạnh về quản lý giấy phép·tuân thủ và được chấp nhận làm chuẩn quốc tế (ISO/IEC 5962:2021), còn CycloneDX do OWASP dẫn dắt tập trung vào sử dụng cho bảo mật lỗ hổng·chuỗi cung ứng, với biểu diễn phong phú về VEX, dịch vụ và đồ thị phụ thuộc. Lý do đưa hash (checksum) vào là để kiểm chứng thành phần được đặc tả có giống hệt từng bit với sản phẩm phân phối thực tế hay không (có bị giả mạo·nhiễm bẩn không). Không có hash thì không thể lọc ra cuộc tấn công chuỗi cung ứng kiểu "danh mục thì đúng nhưng vật thực đã bị tráo".
B. Các tầng theo thời điểm tạo lập
Độ chính xác và tính đầy đủ của SBOM thay đổi tùy vào lúc nó được tạo ra. Hiểu điều này làm rõ vì sao tạo lập tự động tại thời điểm build được khuyến nghị.
| Loại SBOM | Thời điểm tạo lập | Đặc điểm |
|---|---|---|
| Source SBOM | Tại thời điểm khai báo mã·phụ thuộc | Dựa trên phụ thuộc đã khai báo, có thể khác vật thực bao gồm |
| Build SBOM | Tại thời điểm build/biên dịch | Dựa trên sản phẩm thực tế, chính xác·mới nhất (khuyến nghị) |
| Deployed/Runtime SBOM | Tại thời điểm triển khai·vận hành | Phản ánh cả môi trường·cấu hình thực thi |
Phụ thuộc đã khai báo ở giai đoạn mã nguồn và các thành phần thực tế bao gồm trong sản phẩm build thường lệch nhau (do phân giải phụ thuộc bắc cầu, bao gồm có điều kiện, đóng gói, v.v.). Vì thế, quan điểm được thừa nhận là một SBOM đáng tin phải là Build SBOM trích xuất từ sản phẩm mà đường ống build thực sự tạo ra.
3. Đối tượng quản lý: rủi ro mã nguồn mở
Các rủi ro mà SBOM muốn trực quan hóa gồm bốn loại lớn, trong đó phụ thuộc bắc cầu (transitive) là hóc búa nhất. Vì đây là cấu trúc đa tầng trong đó thư viện tôi lấy trực tiếp lại gọi một thư viện khác, và thư viện đó lại gọi cái thứ ba, nên thành phần thực sự thành vấn đề lại ẩn ở nơi sâu không thấy được. Trên thực tế, dù phụ thuộc trực tiếp mà ứng dụng khai báo tường minh có thể chỉ hàng chục, thì phụ thuộc bắc cầu bị kéo theo từ đó thường lên tới hàng trăm đến hàng nghìn.
| Lỗ hổng | Nội dung |
|---|---|
| Lỗ hổng đã biết (CVE) | Lỗi công khai như Log4j ẩn trong phụ thuộc bắc cầu |
| Rủi ro phụ thuộc | Khó nắm được dùng gì do phụ thuộc bắc cầu đa tầng |
| Vi phạm giấy phép | Rủi ro pháp lý khi không tuân thủ giấy phép copyleft như GPL |
| Ngừng bảo trì·độc hại | Gói EOL (hết vòng đời), tiêm độc hại (Typosquatting) |
Lý do vi phạm giấy phép quan trọng không kém bảo mật là vì đưa vào một giấy phép copyleft mạnh như GPL mà không hay biết dẫn thẳng đến rủi ro pháp lý và kinh doanh—chẳng hạn phát sinh nghĩa vụ công khai mã nguồn của chính mình hoặc bị hạn chế phân phối. Có không ít trường hợp thực tế trong đó vi phạm giấy phép mã nguồn mở đã làm ngừng xuất xưởng sản phẩm hoặc leo thang thành kiện tụng.
Loại cuối cùng, ngừng bảo trì·tiêm độc hại, cũng là mối đe dọa gia tăng gần đây. Typosquatting, đăng ký một gói giả chỉ khác một chữ cái so với tên gói phổ biến để rình lỗi gõ nhầm; chiếm quyền phụ thuộc (dependency hijacking), đoạt quyền bảo trì của gói hợp lệ để phát tán phiên bản độc hại; và các lỗ hổng chưa vá của gói EOL bị bỏ mặc lâu ngày—tất cả đều khó nhận biết được sự tồn tại nếu không có SBOM.
Bốn rủi ro này đan xen và khuếch đại lẫn nhau. Ví dụ, nếu một CVE mới được công bố cho một phụ thuộc bắc cầu đã ngừng bảo trì do EOL, sẽ không có bản vá nên phải thay bằng thành phần thay thế hoặc lách qua; song vì là phụ thuộc bắc cầu, không có SBOM thì khó truy vết ngay cả việc phải chỉnh phụ thuộc trực tiếp nào. Như vậy rủi ro phải được phán đoán không riêng lẻ mà trong bối cảnh toàn bộ đồ thị phụ thuộc, và SBOM đóng vai trò chính tấm bản đồ cung cấp đồ thị đó.
4. Phương án quản lý dựa trên SBOM
SBOM phải không phải là tài liệu tĩnh làm một lần rồi thôi, mà là quy trình liên tục xoay vòng qua tạo lập → chia sẻ → ánh xạ → ứng phó → tái tạo lập. Vì CVE mới được công bố hàng chục đến hàng trăm mỗi ngày, một thành phần an toàn đến hôm qua có thể trở nên có lỗ hổng vào hôm nay.
flowchart LR
G["Tạo SBOM(SPDX·CycloneDX)"] --> S["Chia sẻ·công bố"]
S --> M["Ánh xạ lỗ hổng(đối chiếu CVE·NVD)"]
M --> R["Ứng phó·vá·giám sát"]
R -. Quản lý liên tục .-> G
Mỗi giai đoạn của vòng xoay trên được cụ thể hóa trải khắp đường ống CI/CD và giai đoạn vận hành như sau. Sơ đồ dưới đây thể hiện SBOM được tích hợp tự động thế nào trên trục phát triển-build-vận hành.
flowchart TB
DEV["Phát triển(khai báo phụ thuộc)"] --> BUILD["Build(tự tạo SBOM)"]
BUILD --> SCA["Quét SCA(cấu thành·lỗ hổng·giấy phép)"]
SCA --> VEX["Phán định khả năng khai thác qua VEX"]
VEX --> GATE{"Qua cổng phát hành?"}
GATE -->|No| DEV
GATE -->|Yes| OPS["Giám sát triển khai·vận hành"]
OPS -. Theo dõi CVE mới .-> SCA
| Giai đoạn | Phương án |
|---|---|
| Tạo lập | Tự tạo SBOM tại thời điểm build CI/CD (đảm bảo độ chính xác·tính mới nhất) |
| Phân tích (SCA) | Quét thành phần·lỗ hổng·giấy phép bằng công cụ SCA |
| Ánh xạ | Đối chiếu với cơ sở dữ liệu CVE/NVD để nhận diện thành phần có lỗ hổng |
| Ứng phó·giám sát | Vá·nâng cấp, liên tục theo dõi công bố CVE mới |
Điểm cốt lõi là tích hợp việc tạo SBOM vào đường ống build một cách tự động, chứ không bằng tay người. Bản đặc tả viết tay nhanh chóng lệch với mã thực tế và trở nên không đáng tin, nên phải trích xuất SBOM một cách máy móc từ sản phẩm thực tế mỗi lần build chạy. Các công cụ tiêu biểu gồm bộ tạo SBOM Syft, các trình quét lỗ hổng Grype·Trivy, và các nền tảng SCA thương mại (ví dụ Snyk, Sonatype), được nối vào CI để tự động hóa tạo lập-quét-chặn.
Một điểm thực tiễn quan trọng khác là bảo đảm độ tin cậy của chính SBOM. Nếu SBOM bị làm giả·sửa đổi, nó lại có thể mang đến cảm giác an toàn sai lệch, nên cũng phải có quy trình gắn chữ ký số vào SBOM đã tạo (ví dụ Sigstore/Cosign) và kiểm chứng tính toàn vẹn của nó thì chuỗi tin cậy của chuỗi cung ứng mới hoàn chỉnh.
5. Chuyên sâu: Kết hợp VEX và xu hướng quy định trong·ngoài nước
Việc chỉ danh mục lỗ hổng thôi dễ đánh giá quá cao rủi ro thực tế là cạm bẫy lớn nhất của việc vận hành SBOM. Dù một CVE tồn tại trong một thành phần nào đó, nếu đường mã có lỗ hổng đó không thực sự được gọi·thực thi trong sản phẩm của ta, thì rủi ro khai thác có thể không có hoặc rất thấp. Cái bắc cầu qua khoảng cách này là VEX (Vulnerability Exploitability eXchange). VEX là tài liệu trong đó nhà cung cấp tuyên bố tường minh cho mỗi lỗ hổng một trạng thái khả năng khai thác như "không ảnh hưởng (not_affected)·đang điều tra·có ảnh hưởng·đã xử lý", mang tính quyết định trong việc định thứ tự ưu tiên ứng phó và giảm những cuộc vá vội không cần thiết. Nếu SBOM là "cái gì nằm bên trong" thì VEX là "trong số đó cái nào thực sự nguy hiểm", và hai bên phải thành cặp thì tính thực hiệu mới hoàn chỉnh.
Xu hướng quy định cũng đang được siết chặt nhanh chóng. Hoa Kỳ, tiếp nối EO 14028, đang mở rộng yêu cầu SBOM sang thiết bị y tế (FDA) và toàn bộ mua sắm liên bang, còn Liên minh châu Âu đang tiến, thông qua CRA (Cyber Resilience Act), tới việc áp nghĩa vụ trang bị SBOM và xử lý lỗ hổng lên các sản phẩm số đưa ra thị trường. Ở Hàn Quốc cũng vậy, với trung tâm là Bộ Khoa học và ICT và KISA, các hướng dẫn an ninh chuỗi cung ứng SW đang được chuẩn bị và dòng chảy áp dụng SBOM đang được bàn luận·lan rộng, khởi đầu từ khu vực công và tài chính. Tuy nhiên, vì phạm vi và thời điểm bắt buộc chi tiết có thể thay đổi theo chính sách, tổ chức nên chủ động thiết lập hệ thống quản lý SBOM hơn là chạy theo quy định.
Hướng ra đề dự kiến theo góc nhìn Kỹ sư chuyên nghiệp có thể được sắp xếp thành (1) so sánh định nghĩa·yếu tố tối thiểu·định dạng chuẩn của SBOM (SPDX vs CycloneDX), (2) sự cần thiết quản lý rủi ro phụ thuộc bắc cầu·giấy phép, (3) quy trình liên tục tạo SBOM-SCA-ánh xạ CVE-VEX-giám sát, và (4) phương án tích hợp DevSecOps và bảo đảm tính toàn vẹn dựa trên chữ ký.
6. Điều cần cân nhắc và hàm ý
Thứ nhất, bảo đảm tự động hóa và tính mới nhất. SBOM phải được tích hợp vào đường ống build và tự tạo trên mỗi lần build; bản đặc tả làm thủ công nhanh chóng cũ đi và mất niềm tin. Ngoài việc tạo lập, việc tái ánh xạ liên tục theo sát các công bố CVE mới phải cùng vận hành thì SBOM mới trở thành tài sản sống.
Thứ hai, định thứ tự ưu tiên thông qua kết hợp VEX. Thứ tự ứng phó phải được định theo khả năng khai thác chứ không theo số lượng lỗ hổng thuần túy, để nhân lực hữu hạn tập trung được vào rủi ro thực tế. Chỉ liệt kê CVE mà không có VEX tạo ra nghịch lý rằng "mệt mỏi vì vá" làm trễ nải việc ứng phó với lỗ hổng thực sự nguy hiểm.
Thứ ba, bảo đảm tính toàn vẹn·chuỗi tin cậy của SBOM. Niềm tin của chuỗi cung ứng chỉ thành lập khi có quy trình ký·kiểm chứng chính SBOM, phát hiện giả mạo sản phẩm qua hash thành phần, và xác nhận tính xác thực của SBOM nhận từ nhà cung cấp. Một SBOM không đáng tin mang lại cảm giác an toàn sai lệch còn tệ hơn là không có.
Thứ tư, quản lý thường trực giấy phép·tuân thủ. Không chỉ lỗ hổng bảo mật mà cả việc có hay không giấy phép copyleft·xung đột phải được kiểm tra liên tục để kiểm soát chủ động rủi ro pháp lý và kinh doanh, và điều này đòi hỏi quản lý chính xác siêu dữ liệu giấy phép dựa trên SPDX.
Thứ năm, nội hóa DevSecOps cấp tổ chức và ứng phó quy định. SBOM·SCA·VEX phải được tích hợp thường trực vào đường ống, và các thay đổi quy định như EU CRA và chính sách an ninh chuỗi cung ứng SW của Hàn Quốc phải được phản ánh chủ động để nâng mức trưởng thành an ninh chuỗi cung ứng trên toàn tổ chức. Cần một góc nhìn rằng SBOM không phải là mục đích tự thân mà là hạ tầng nền tảng nâng đỡ tính trực quan·niềm tin·năng lực ứng phó của toàn bộ chuỗi cung ứng.
Tài liệu tham khảo
- CISA, "Software Bill of Materials (SBOM)": https://www.cisa.gov/sbom
- NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)", 2021
- OWASP CycloneDX: https://cyclonedx.org/ · SPDX: https://spdx.dev/
Tóm tắt một câu: SBOM liệt kê các thành phần phần mềm theo chuẩn SPDX·CycloneDX để trực quan hóa rủi ro lỗ hổng·giấy phép mã nguồn mở, và quản lý an ninh chuỗi cung ứng qua quy trình liên tục tự tạo lúc build → quét SCA → ánh xạ CVE → ưu tiên hóa bằng VEX → ký·giám sát—một hạ tầng nền tảng.