Doanh nghiệp có biết phần mềm của mình được tạo nên từ những gì?
SBOM (Software Bill of Materials) là danh mục có cấu trúc về các thành phần tạo nên một sản phẩm phần mềm. Danh mục có thể ghi nhận thư viện trực tiếp và gián tiếp, phiên bản, nhà cung cấp và mối quan hệ phụ thuộc. SBOM giúp đội ngũ hiểu phần mềm đang sử dụng những thành phần nào; bản thân nó không chứng minh phần mềm an toàn, không thay thế quét lỗ hổng và cũng không tự xử lý sự cố.
Một ứng dụng có thể kết hợp mã do đội ngũ tự viết, thư viện mã nguồn mở, gói thương mại, công cụ xây dựng và các thành phần được kế thừa từ hệ thống khác. Nếu một thư viện xuất hiện vấn đề bảo mật, câu hỏi đầu tiên thường là: sản phẩm nào đang dùng thành phần đó, ở phiên bản nào và qua đường phụ thuộc nào?
Không có danh mục đáng tin cậy, câu trả lời có thể đòi hỏi nhiều nhóm cùng dò mã, hỏi nhà cung cấp và đối chiếu các tệp khóa phiên bản. SBOM tạo một điểm bắt đầu có thể tìm kiếm và cập nhật cho công việc đó.
SBOM ghi nhận điều gì?
Có thể hình dung SBOM như danh sách thành phần của một sản phẩm phần mềm, kèm thông tin giúp nhận diện và hiểu quan hệ giữa chúng. Một bản SBOM có thể bao gồm:
- Tên thành phần và phiên bản: giúp phân biệt các thư viện hoặc gói có tên tương tự.
- Nhà cung cấp hoặc tác giả: hỗ trợ xác định nguồn gốc khi thông tin có sẵn.
- Mã định danh: chẳng hạn Package URL (PURL) hoặc các định danh phù hợp với thành phần.
- Quan hệ phụ thuộc: cho biết một gói được ứng dụng sử dụng trực tiếp hay được kéo vào thông qua gói khác.
- Thông tin giấy phép: hỗ trợ rà soát nghĩa vụ sử dụng phần mềm; cần kiểm chứng theo nguồn và chính sách của tổ chức.
- Dấu vết và thời điểm tạo: giúp biết SBOM thuộc bản phát hành nào, được tạo bằng công cụ nào và dữ liệu được ghi nhận khi nào.
Mức độ đầy đủ phụ thuộc vào quy trình build, công cụ và nguồn dữ liệu. Thành phần được tải động, mã nhúng, gói nội bộ hoặc phần mềm bên thứ ba có thể cần cách ghi nhận riêng. Vì vậy, không nên giả định mọi SBOM đều mô tả hoàn toàn mọi thứ có thể chạy trong môi trường thực tế.
SBOM hữu ích khi nào?
Khi có thông báo về một thư viện bị ảnh hưởng, đội bảo mật có thể tìm các sản phẩm chứa gói và phiên bản liên quan. Đội phát triển xác định nhánh phụ thuộc, đánh giá khả năng cập nhật và kiểm thử. Người phụ trách sản phẩm hoặc vận hành có thể biết phạm vi cần theo dõi và phối hợp với nhà cung cấp.
SBOM cũng hỗ trợ rà soát phần mềm nguồn mở, quản lý thành phần hết vòng đời và trao đổi thông tin giữa nhà cung cấp với khách hàng. Tuy nhiên, danh mục chỉ hữu ích nếu gắn với đúng sản phẩm, phiên bản và cách phát hành.
SBOM khác gì với quét lỗ hổng?
SBOM trả lời chủ yếu câu hỏi “có những thành phần nào?”. Công cụ quản lý lỗ hổng đối chiếu thành phần và phiên bản với dữ liệu về lỗ hổng đã biết. Quy trình xử lý còn phải xác nhận thành phần có thực sự được sử dụng, có bị cấu hình ảnh hưởng hay không, mức độ phơi nhiễm và cách khắc phục phù hợp.
Do đó, cần phân biệt các hoạt động:
| Hoạt động | Câu hỏi chính |
|---|---|
| Tạo SBOM | Sản phẩm gồm những thành phần nào và chúng liên hệ ra sao? |
| Phân tích lỗ hổng | Có cảnh báo nào liên quan đến thành phần hoặc phiên bản này? |
| Đánh giá mức độ ảnh hưởng | Thành phần có hiện diện trong bản triển khai và điều kiện sử dụng có liên quan không? |
| Khắc phục và xác minh | Có thể nâng cấp, thay thế, giảm thiểu hay chấp nhận rủi ro có thời hạn? |
Một cảnh báo không tự động đồng nghĩa với việc sản phẩm có thể bị khai thác; ngược lại, không có cảnh báo trong công cụ cũng không chứng minh sản phẩm không có rủi ro. Dữ liệu lỗ hổng có thể chưa đầy đủ, thông tin thành phần có thể sai hoặc cũ, và kết quả còn tùy cách triển khai. Với một số trường hợp, VEX (Vulnerability Exploitability eXchange) có thể bổ sung nhận định về khả năng bị ảnh hưởng; VEX không thay thế SBOM hay quy trình đánh giá của tổ chức.
SBOM cũng không phải chứng nhận tuân thủ hoặc bảo đảm rằng mã nguồn không chứa mã độc. Đây là dữ liệu đầu vào cho quản trị rủi ro, cần được kết hợp với kiểm thử, kiểm soát thay đổi, giám sát và quy trình phản ứng sự cố.
Định dạng SBOM phổ biến: SPDX và CycloneDX
SPDX và CycloneDX là hai định dạng SBOM được sử dụng rộng rãi. Chúng có mô hình dữ liệu, khả năng và hệ sinh thái công cụ khác nhau. Việc lựa chọn nên dựa trên yêu cầu trao đổi dữ liệu, công cụ đang dùng, loại sản phẩm và yêu cầu của khách hàng hoặc cơ quan quản lý.
Trước khi chuẩn hóa định dạng, hãy kiểm tra công cụ có tạo được dữ liệu phù hợp, đội tiếp nhận có đọc và xử lý được hay không, và thông tin phụ thuộc có được biểu diễn đủ cho mục đích sử dụng. Một tệp JSON hợp lệ về cú pháp chưa chắc đã đầy đủ hoặc chính xác về nội dung.
Các tài liệu chính thức để tìm hiểu thêm:
Đừng chọn định dạng chỉ vì một công cụ đang hỗ trợ sẵn. Nếu khách hàng hoặc đối tác cần nhận SBOM theo định dạng cụ thể, hãy xác nhận yêu cầu, phiên bản đặc tả, cách chuyển giao và nội dung tối thiểu trước khi đưa vào hợp đồng hoặc quy trình phát hành.
Cách xây dựng và duy trì SBOM trong quy trình phát triển
1. Xác định phạm vi và người chịu trách nhiệm
Làm rõ sản phẩm, phiên bản và giai đoạn cần tạo SBOM: lúc build, phát hành hay cả hai. Quy định nhóm chịu trách nhiệm về độ chính xác, nơi lưu trữ, thời hạn cập nhật và cách cung cấp cho người có thẩm quyền.
Nếu phần mềm gồm nhiều dịch vụ hoặc kho mã, cần xác định SBOM ở cấp thành phần, dịch vụ hay toàn sản phẩm. Phạm vi không rõ dễ dẫn đến danh mục trùng lặp hoặc bỏ sót.
2. Tự động tạo từ quy trình build
Ưu tiên tạo SBOM từ các tệp khóa phụ thuộc, hệ thống build hoặc artifact đã tạo, thay vì duy trì danh sách thủ công. Gắn kết quả với một bản build hoặc bản phát hành cụ thể để có thể truy ngược. Kiểm tra đầu ra định kỳ, nhất là khi thay đổi ngôn ngữ, công cụ build hoặc cách đóng gói.
Tự động hóa giúp giảm thao tác lặp lại nhưng không tự bảo đảm dữ liệu chính xác. Cần xác minh công cụ phát hiện những loại thành phần nào, xử lý gói nội bộ ra sao và có bỏ qua thành phần nào không.
3. Kiểm tra chất lượng trước khi sử dụng
Đánh giá các trường hợp như thiếu phiên bản, tên không chuẩn hóa, quan hệ phụ thuộc không rõ hoặc thành phần không nhận diện được. So sánh mẫu SBOM với tệp khai báo phụ thuộc, artifact và tài liệu của nhà cung cấp.
Đặt tiêu chí chất lượng có thể đo lường, ví dụ tỷ lệ thành phần có định danh và phiên bản, khả năng đối chiếu với bản phát hành, thời gian cập nhật sau thay đổi. Chọn ngưỡng theo rủi ro và đặc thù sản phẩm thay vì coi một con số chung là chuẩn cho mọi tổ chức.
4. Kết nối với quy trình xử lý cảnh báo
Khi có cảnh báo mới, quy trình cần chỉ ra ai xác minh sản phẩm bị ảnh hưởng, thời hạn đánh giá, cách thông báo chủ sở hữu và cách theo dõi khắc phục. Việc ưu tiên nên xem xét mức độ nghiêm trọng, khả năng tiếp cận, cách triển khai, mức độ phơi nhiễm và tác động kinh doanh.
Nếu chưa thể nâng cấp ngay, cần ghi rõ biện pháp giảm thiểu, người chấp nhận rủi ro và ngày xem xét lại. Không nên để cảnh báo ở trạng thái mở vô thời hạn mà không có quyết định.
5. Bảo vệ và chia sẻ đúng phạm vi
SBOM có thể tiết lộ cấu trúc kỹ thuật và các thành phần sản phẩm. Hãy xem xét quyền truy cập, nơi lưu trữ, thời điểm chia sẻ và thông tin nào cần cung cấp cho từng đối tượng. Có quy trình riêng cho khách hàng, đối tác và nhóm nội bộ; không mặc định mọi bản SBOM đều phải công khai.
6. Bao gồm phần mềm của nhà cung cấp
Với sản phẩm mua ngoài hoặc dịch vụ bên thứ ba, hỏi nhà cung cấp về phạm vi SBOM, định dạng, thời điểm cập nhật và cách thông báo thay đổi hoặc sự cố. SBOM do nhà cung cấp cung cấp cần được đánh giá theo yêu cầu hợp đồng và mức độ quan trọng của sản phẩm; không nên xem việc nhận được một tệp là đã hoàn tất thẩm định.
Checklist lựa chọn công cụ hoặc dịch vụ SBOM
Trước khi lựa chọn, đội ngũ có thể đặt các câu hỏi sau:
- Công cụ có hỗ trợ ngôn ngữ, hệ sinh thái gói và cách build đang sử dụng không?
- SBOM được tạo từ mã nguồn, manifest, artifact hay kết hợp nhiều nguồn?
- Có thể liên kết chính xác SBOM với sản phẩm, phiên bản và bản phát hành không?
- Dữ liệu thành phần trực tiếp, gián tiếp, nội bộ và bên thứ ba được thể hiện thế nào?
- Công cụ có hỗ trợ định dạng, phiên bản đặc tả và tích hợp mà đối tác yêu cầu không?
- Có cách kiểm tra chất lượng, cập nhật dữ liệu và xử lý thành phần không nhận diện được không?
- Quy trình cảnh báo, phân công xử lý, chấp nhận rủi ro và xác minh khắc phục được kết nối ra sao?
- SBOM được lưu trữ, kiểm soát truy cập và chia sẻ như thế nào?
Một thử nghiệm giới hạn nên dùng sản phẩm đại diện, bao gồm cả phụ thuộc gián tiếp và thành phần nội bộ. Đánh giá không chỉ ở việc tạo được tệp, mà còn ở khả năng tìm thành phần, xác định phạm vi ảnh hưởng và đưa kết quả vào quy trình hiện tại.
Câu hỏi thường gặp
SBOM có bắt buộc với mọi doanh nghiệp không?
Không có câu trả lời chung cho mọi sản phẩm và thị trường. Yêu cầu có thể đến từ hợp đồng, khách hàng, lĩnh vực hoạt động hoặc quy định áp dụng. Doanh nghiệp nên xác định nghĩa vụ cụ thể theo sản phẩm, thị trường và vai trò của mình, đồng thời trao đổi với bộ phận pháp chế khi cần.
Có thể tạo SBOM một lần rồi dùng mãi không?
Không nên. Phụ thuộc phần mềm thay đổi theo thời gian và mỗi bản phát hành có thể khác nhau. SBOM cần gắn với phiên bản cụ thể và được tạo lại hoặc cập nhật khi sản phẩm thay đổi theo chính sách đã xác định.
Dùng SBOM có loại bỏ được lỗ hổng không?
Không. SBOM giúp nhận diện thành phần và hỗ trợ xác định phạm vi ảnh hưởng. Việc giảm rủi ro vẫn cần quản lý lỗ hổng, cập nhật, kiểm thử, kiểm soát cấu hình và xử lý phù hợp với mức độ ưu tiên.
SBOM chỉ dành cho phần mềm mã nguồn mở?
Không. SBOM có thể ghi nhận thành phần mã nguồn mở, thương mại, nội bộ và các thành phần khác tùy khả năng công cụ và phạm vi đã chọn. Với phần mềm bên thứ ba, chất lượng dữ liệu phụ thuộc thông tin nhà cung cấp và cách tổ chức kiểm chứng.
Có thể dùng bảng tính thay cho SBOM?
Bảng tính có thể hỗ trợ kiểm kê ban đầu ở phạm vi nhỏ, nhưng khó giữ quan hệ phụ thuộc, tự cập nhật theo từng bản phát hành và xử lý thay đổi thường xuyên. Khi quy mô hoặc yêu cầu truy vết tăng, nên đánh giá định dạng có cấu trúc và tự động hóa phù hợp.
Kết luận
SBOM giúp tổ chức có cái nhìn rõ hơn về thành phần phần mềm và rút ngắn bước xác định phạm vi khi cần đánh giá rủi ro. Giá trị thực tế đến từ dữ liệu chính xác, được gắn với bản phát hành, cập nhật có kiểm soát và kết nối với người chịu trách nhiệm xử lý.
Bắt đầu từ một sản phẩm đại diện, thống nhất mục đích sử dụng và thử quy trình từ lúc tạo danh mục đến lúc xử lý một cảnh báo. Sau đó mới mở rộng sang các nhóm sản phẩm, công cụ và nhà cung cấp khác.
Nguồn tham khảo
Nội dung cung cấp thông tin tổng quát, không thay thế đánh giá kỹ thuật, tư vấn pháp lý hoặc yêu cầu cụ thể trong hợp đồng và quy định áp dụng.