Kiểm tra SBOM trước nghiệm thu: năm nhóm dữ liệu cần đối chiếu

Doanh nghiệp nhận Software Bill of Materials (SBOM) cần kiểm tra tệp đó gắn với phiên bản sản phẩm nào trước khi xem xét các thành phần bên trong. Một danh sách không có mã phát hành, thời điểm tạo hoặc quan hệ phụ thuộc sẽ khó dùng khi xuất hiện lỗ hổng. Nghiệm thu vì thế không dừng ở câu hỏi nhà cung cấp có gửi tệp hay chưa.

SBOM dùng để kiểm tra điều gì

SBOM là bản ghi có cấu trúc về thành phần phần mềm và quan hệ trong chuỗi cung ứng. Nó gần với bảng thành phần của một sản phẩm, nhưng mục tiêu là để công cụ và đội vận hành tìm kiếm, so sánh và cập nhật dữ liệu. Báo cáo về các thành phần tối thiểu của SBOM do NTIA công bố nhóm yêu cầu thành dữ liệu, hỗ trợ tự động và quy trình tạo, giao, cập nhật.

SBOM chỉ có giá trị khi đối chiếu được với sản phẩm đang giao. Tên sản phẩm giống nhau nhưng phiên bản, mã build, gói hệ điều hành hoặc ảnh container khác nhau vẫn có thể chứa thành phần khác nhau. Bản ghi cần cho biết ai tạo, tạo vào lúc nào và đại diện cho mốc phát hành nào.

Năm nhóm dữ liệu cần kiểm tra

Nhóm dữ liệu	Cần đối chiếu	Nếu thiếu sẽ gặp gì
Sản phẩm và phiên bản	Tên sản phẩm, phiên bản, mã build hoặc mã phát hành	Không biết tệp ứng với gói giao nào
Thành phần	Tên và phiên bản của phụ thuộc trực tiếp, gián tiếp	Khó so sánh khi có cảnh báo lỗ hổng
Nhà cung cấp	Tổ chức hoặc dự án duy trì thành phần	Không xác định được nơi nhận thông tin sửa lỗi
Mã định danh	PURL, CPE, mã băm hoặc mã khác được định dạng hỗ trợ	Có thể nhầm hai gói cùng tên là một
Quan hệ phụ thuộc	Sản phẩm nối với phụ thuộc trực tiếp và gián tiếp ra sao	Không khoanh được phạm vi bị ảnh hưởng

Nhóm kiểm tra đầu tiên là khả năng truy ngược từ tệp SBOM về sản phẩm thật. Nhóm thứ hai là độ đầy đủ của thành phần và phiên bản. Nhóm thứ ba và thứ tư giúp tìm đúng nhà duy trì và đúng gói phần mềm. Nhóm cuối cùng cho biết một thành phần nằm ở đâu trong sản phẩm, thay vì chỉ xuất hiện như một dòng rời rạc.

Định dạng phải đọc được bằng công cụ

Trang đặc tả SPDX hiện liệt kê phiên bản 3.0 và mô tả SPDX là tiêu chuẩn mở quốc tế ISO/IEC 5962:2021. Tổng quan đặc tả CycloneDX mô tả mô hình có thể chứa thành phần, dịch vụ, quan hệ và thông tin chuỗi cung ứng. Cả hai đều hướng đến dữ liệu có cấu trúc để trao đổi giữa công cụ.

Doanh nghiệp có thể chấp nhận JSON, XML hoặc định dạng khác nếu đúng đặc tả đã chọn. PDF, ảnh chụp hoặc bảng tính do con người tự tổng hợp có thể dùng làm bản đọc, nhưng không nên là tệp giao duy nhất. Hồ sơ mua sắm cần ghi rõ phiên bản đặc tả, trường bắt buộc, nơi lưu tệp và cách kiểm tra tệp có thể phân tích được.

Đuôi tệp giống nhau cũng chưa chứng minh nội dung hợp lệ. Đội nghiệm thu nên dùng một công cụ phân tích, kiểm tra mã định danh trùng lặp và thử truy ra một thành phần từ sản phẩm gốc. Nếu nhà cung cấp dùng nhiều công cụ tạo SBOM, cần yêu cầu họ giải thích khác biệt giữa các bản xuất.

Quan hệ phụ thuộc quyết định phạm vi tìm kiếm

Tài liệu CycloneDX về phụ thuộc phần mềm mô tả cách dùng mã tham chiếu để nối các thành phần trong cùng một BOM. Quan hệ giữa sản phẩm, phụ thuộc trực tiếp và phụ thuộc gián tiếp cần được thể hiện rõ. Một mục chưa xác nhận không đồng nghĩa với việc sản phẩm không có phụ thuộc đó.

Khi nghiệm thu, doanh nghiệp nên yêu cầu một kết quả đối chiếu đơn giản: sản phẩm nối với những thành phần trực tiếp nào, mỗi thành phần đó nối với lớp gián tiếp nào, và mục nào đang ở trạng thái chưa biết. Nếu tệp chỉ liệt kê lớp đầu tiên, nhà cung cấp cần nêu phạm vi và lý do để bên mua phân biệt lỗ hổng dữ liệu với chủ ý loại bỏ.

SBOM phải nối được với quy trình xử lý lỗ hổng

SBOM thường ghi nhận trạng thái của phần mềm tại thời điểm build hoặc phát hành. Dữ liệu lỗ hổng lại thay đổi sau đó. Tài liệu SPDX về dữ liệu lỗ hổng trong phiên bản 3.0 phân biệt dữ liệu thành phần tĩnh với thông tin lỗ hổng và quan hệ đánh giá ảnh hưởng. Cách phân tách này giúp cập nhật nhận định về lỗ hổng mà không phải coi bản ghi thành phần cũ là vô dụng.

Quy trình nghiệm thu nên trả lời bốn câu hỏi:

1. Sau khi sản phẩm hoặc thành phần thay đổi, nhà cung cấp giao SBOM mới trong bao lâu?
2. Nếu phát hiện sai, bản cũ và bản sửa được phân biệt bằng cách nào?
3. Khi có thông báo lỗ hổng, đầu mối nào xác nhận phiên bản bị ảnh hưởng?
4. Nhà cung cấp có gửi VEX hoặc tuyên bố tương đương về ảnh hưởng của sản phẩm không?

Tại Đài Loan, doanh nghiệp nên xem hợp đồng trước

Ở Đài Loan, việc áp dụng SBOM đang gắn với định hướng chính sách, yêu cầu mua sắm và thực hành của doanh nghiệp. Cơ quan An ninh mạng Đài Loan, cơ quan phụ trách chính sách và bảo vệ không gian mạng, công bố thông tin về hội thảo SBOM cùng Viện Nghiên cứu An ninh mạng. Nội dung đề cập đến thành phần, quy trình, theo dõi sau phát hành, ứng phó lỗ hổng và tuân thủ hợp đồng.

Thông tin về định hướng này không có nghĩa mọi doanh nghiệp tại Đài Loan phải giao cùng một định dạng SBOM. Bên mua cần đọc yêu cầu mua sắm, hợp đồng bảo trì, điều khoản an toàn của nhà cung cấp và yêu cầu của thị trường mục tiêu. Nếu hợp đồng đã nêu SPDX, CycloneDX, thời hạn cập nhật hoặc đầu mối phản hồi, đó là cơ sở nghiệm thu trực tiếp.

Người dùng gia đình khó nhận được một SBOM đầy đủ, nhưng vẫn có thể hỏi nhà cung cấp phần mềm hoặc thiết bị về phiên bản thành phần, nơi đăng thông báo lỗ hổng và thời hạn hỗ trợ. Doanh nghiệp nên yêu cầu tệp máy đọc được, bản mẫu có thể kiểm tra và một kênh nhận bản cập nhật.

Tại Việt Nam thì sao

Ở Việt Nam, SBOM phù hợp nhất với doanh nghiệp đang mua phần mềm, thuê dịch vụ đám mây, phát triển ứng dụng hoặc nhận sản phẩm có thành phần mã nguồn mở. Không nên bắt đầu bằng việc hỏi một tệp có tên SBOM rồi lưu vào thư mục hợp đồng. Câu hỏi thực tế là tệp đó đại diện cho sản phẩm nào, ai chịu trách nhiệm cập nhật và doanh nghiệp sẽ dùng dữ liệu đó ở bước nào trong quản lý lỗ hổng.

Trong hồ sơ mua sắm, bên mua nên ghi tên sản phẩm, phiên bản, mã build, ngày giao, môi trường áp dụng và định dạng SBOM được chấp nhận. Nếu chọn SPDX hoặc CycloneDX, cần ghi rõ phiên bản đặc tả thay vì chỉ ghi tên. Có thể yêu cầu JSON hoặc XML để công cụ nội bộ đọc được, đồng thời nhận thêm bản PDF nếu bộ phận pháp chế hoặc vận hành cần bản dễ xem. Hai loại tài liệu này không thay thế cho nhau.

Về quy định, doanh nghiệp tại Việt Nam cần phân biệt yêu cầu kỹ thuật trong hợp đồng với nghĩa vụ pháp lý áp dụng cho dữ liệu và hệ thống. Khi SBOM chứa tên gói, mã nguồn, thông tin nhà cung cấp hoặc dữ liệu liên quan đến sản phẩm khách hàng, người phụ trách nên xác định nơi lưu, người được truy cập và thời gian giữ. Khi chưa rõ một yêu cầu có áp dụng hay không, hãy hỏi bộ phận pháp chế, an toàn thông tin hoặc cơ quan có thẩm quyền thay vì tự coi tài liệu quốc tế là văn bản bắt buộc.

Mức độ sẵn có của SBOM ở Việt Nam phụ thuộc vào năng lực của nhà cung cấp và chuỗi phụ thuộc phía sau. Một phần mềm do doanh nghiệp tự xây dựng thường dễ gắn quy trình tạo SBOM vào pipeline hơn một thiết bị mua qua nhiều lớp phân phối. Với gói mã nguồn mở, bên mua nên hỏi phiên bản, nguồn phát hành, mã định danh và cách nhà cung cấp theo dõi phụ thuộc gián tiếp. Nếu nhà cung cấp chưa có SBOM, có thể yêu cầu bản mẫu cho một bản phát hành trước khi ký điều khoản áp dụng cho toàn bộ sản phẩm.

Giá triển khai không chỉ là phí công cụ. Doanh nghiệp còn phải tính thời gian tích hợp pipeline, lưu trữ, kiểm tra bản ghi, xử lý thành phần không nhận diện được và phản hồi khi có cảnh báo. Tính đến thời điểm bài viết được thực hiện, chúng tôi chưa tìm thấy bảng giá hoặc số liệu chính thức của cơ quan chức năng Việt Nam để so sánh chi phí SBOM giữa các ngành. Cách hỏi phù hợp là yêu cầu báo giá tách theo số sản phẩm, số bản phát hành, số người dùng, dung lượng lưu trữ, hỗ trợ kỹ thuật và phí kết nối với hệ thống quản lý lỗ hổng.

Một ví dụ nhỏ là công ty cung cấp ứng dụng cho khách hàng doanh nghiệp. Trong hợp đồng, công ty có thể cam kết giao SBOM cho từng bản phát hành, nêu các phụ thuộc chưa xác nhận, thông báo khi thành phần thay đổi và gửi bản mới khi phát hiện lỗ hổng ảnh hưởng. Một cửa hàng dùng phần mềm đóng gói không nhất thiết tạo SBOM, nhưng vẫn có thể hỏi nhà cung cấp phiên bản đang được hỗ trợ, nơi nhận cảnh báo và thời điểm kết thúc cập nhật. Hai tình huống có mức độ sẵn có khác nhau, nhưng đều cần đầu mối và thời hạn cụ thể.

Đối với doanh nghiệp Việt Nam bán phần mềm ra nước ngoài, yêu cầu từ khách hàng hoặc thị trường mục tiêu có thể chi tiết hơn yêu cầu nội bộ. Bên phụ trách không nên hứa một chuẩn chung cho mọi khách hàng trước khi kiểm tra hợp đồng. Hãy lưu bản đặc tả đã dùng, công cụ tạo, thời điểm tạo, các mục chưa biết và lịch cập nhật. Nếu chưa thể cung cấp dữ liệu phụ thuộc gián tiếp, cần nói rõ giới hạn đó trong hồ sơ giao hàng thay vì để người mua tự suy đoán.

Những nơi nên tra cứu gồm trang chính thức của SPDX, CycloneDX, NTIA và các văn bản hiện hành trên Cổng thông tin điện tử Chính phủ Việt Nam khi nội dung liên quan đến nghĩa vụ trong nước. Tài liệu kỹ thuật quốc tế giúp chọn trường dữ liệu và quy trình, nhưng không thay thế việc kiểm tra quy định Việt Nam, điều khoản hợp đồng hoặc yêu cầu riêng của ngành. Khi chưa có số liệu giá hay mức độ phổ biến được cơ quan chức năng công bố, doanh nghiệp nên ghi nhận bằng báo giá và kết quả thử của chính mình.

Soạn điều khoản nghiệm thu trong một trang

1. Đối chiếu phiên bản: ghi sản phẩm, phiên bản, mã build, ngày phát hành và quan hệ một đối một với tệp SBOM.
2. Quy định trường dữ liệu: yêu cầu tên, phiên bản, nhà cung cấp, mã định danh, phụ thuộc, người tạo và thời điểm tạo.
3. Nêu phần chưa biết: tách thành phần chưa quét, chưa xác nhận hoặc cố ý không đưa vào khỏi phần đã kiểm tra.
4. Chọn định dạng và phép thử: ghi phiên bản SPDX hoặc CycloneDX, định dạng máy đọc được và công cụ hoặc báo cáo xác minh.
5. Giao trách nhiệm sau phát hành: nêu thời hạn cập nhật, sửa sai, thông báo lỗ hổng, bản SBOM mới và đầu mối liên hệ.

Dấu hiệu nên trả lại để bổ sung

• Tệp không có phiên bản sản phẩm, mã build hoặc thời điểm tạo.
• Chỉ có PDF hoặc ảnh, không có bản gốc máy đọc được.
• Thành phần chỉ có tên, thiếu phiên bản, nhà cung cấp hoặc mã định danh.
• Chỉ liệt kê phụ thuộc trực tiếp mà không nói phạm vi phụ thuộc gián tiếp.
• Không có lịch cập nhật, cách sửa sai hoặc đầu mối khi có lỗ hổng.

SBOM nên được nghiệm thu theo ba lớp: khớp với sản phẩm, truy được quan hệ phụ thuộc và nối được với trách nhiệm xử lý lỗ hổng. Một tệp đẹp nhưng không có phiên bản hoặc không có người cập nhật vẫn chưa phải hồ sơ có thể dùng trong vận hành.

Câu hỏi thường gặp

Có bắt buộc phải chọn SPDX hoặc CycloneDX không?
Không phải mọi hợp đồng đều bắt buộc một định dạng. Doanh nghiệp cần ghi rõ phiên bản, trường dữ liệu và cách xác minh; SPDX và CycloneDX là hai lựa chọn có đặc tả công khai.

PDF có đủ để nghiệm thu SBOM không?
PDF có thể dùng để đọc, nhưng không nên là tệp giao duy nhất. Công cụ cần bản có cấu trúc để tìm thành phần, mã định danh và quan hệ phụ thuộc.

SBOM có thành phần bị cảnh báo thì sản phẩm chắc chắn bị ảnh hưởng không?
Không. SBOM cho biết thành phần có mặt trong sản phẩm. Đội sản phẩm hoặc nhà cung cấp vẫn phải đánh giá cấu hình, khả năng khai thác và phạm vi ảnh hưởng trước khi quyết định sửa, nâng cấp hoặc giải thích vì sao không bị ảnh hưởng.

Doanh nghiệp nhỏ nên bắt đầu từ đâu?
Hãy chọn một sản phẩm đang mua hoặc một ứng dụng đang phát hành, yêu cầu bản SBOM mẫu, kiểm tra năm nhóm dữ liệu và ghi thời hạn cập nhật vào hợp đồng tiếp theo.