Hóa đơn vật liệu phần mềm (SBOM) là gì?

Hóa đơn vật liệu phần mềm (SBOM) là danh sách chi tiết, toàn diện của tất cả các thành phần trong một ứng dụng phần mềm, bao gồm việc sử dụng phần mềm mã nguồn mở, phụ thuộc thành phần, giấy phép và các lỗ hổng đã biết. SBOM cung cấp một bản kiểm kê của từng thành phần riêng lẻ bao gồm ứng dụng, giống như danh sách các thành phần trong một công thức. SBOM bắt đầu đạt được sức hút vào năm 2018 như một nỗ lực hợp tác của cộng đồng bảo mật thông tin và phần lớn được thúc đẩy bởi Cơ quan Quản lý Thông tin và Viễn thông Quốc gia (NTIA) và chính phủ Hoa Kỳ trong những năm gần đây.

SBOM là tài liệu rất quan trọng cung cấp thông tin quan trọng cho các tổ chức muốn giảm thiểu và giảm thiểu rủi ro về hoạt động, pháp lý và chuỗi cung ứng phần mềm, nhưng nhiều tổ chức vẫn phải đối mặt với thách thức trong việc triển khai SBOM vào các quy trình hiện có của họ hoặc không nhận thức được lợi ích của chúng. Bài viết này sẽ xem xét cách SBOM có thể giúp các tổ chức được thông báo tốt hơn về phần mềm họ sử dụng và tại sao SBOM nên được áp dụng như một phương pháp hay nhất.

Tìm hiểu cách UpGuard giúp doanh nghiệp có được khả năng hiển thị tốt hơn về các lỗ hổng phần mềm của họ >

Tại sao SBOM lại quan trọng?

Bởi vì trung bình các doanh nghiệp sử dụng hơn 130 ứng dụng SaaS trong các hoạt động hàng ngày và các doanh nghiệp lớn hơn có thể sử dụng hơn 200 ứng dụng hàng ngày, SBOM thậm chí còn trở nên cần thiết hơn để giảm rủi ro bảo mật. Tổ chức càng sử dụng nhiều ứng dụng hàng ngày, tổ chức càng phải đối mặt với nhiều rủi ro. Nếu một ứng dụng hoặc thành phần bị vi phạm do lỗ hổng, nó có khả năng ảnh hưởng đến toàn bộ chuỗi cung ứng phần mềm.

SBOM giúp các tổ chức xác định các rủi ro hoạt động và bảo mật liên quan đến một số phần mềm nhất định, cũng như có được khả năng hiển thị sâu hơn về các thành phần phần mềm. Các tổ chức có thể quản lý tốt hơn các lỗ hổng, tuân thủ giấy phép và thực hiện các tác vụ quản lý phần mềm quan trọng khác bằng cách biết chính xác những gì bên trong sản phẩm phần mềm. SBOM đang trở thành một công cụ ngày càng quan trọng trong thế giới an ninh mạng, vòng đời phát triển phần mềm (SDLC) và quy trình DevSecOps.

Vào tháng 5 năm 2021, chính phủ liên bang Hoa Kỳ đã ban hành Lệnh hành pháp 14028, yêu cầu tất cả các cơ quan chính phủ Hoa Kỳ chỉ giao dịch với các nhà cung cấp phần mềm cung cấp SBOM. Luật mới này là một phần của nỗ lực an ninh mạng lớn hơn nhằm bảo mật cơ sở hạ tầng kỹ thuật số của quốc gia và thúc đẩy nhiều nhà cung cấp phần mềm hơn đảm bảo các sản phẩm được xây dựng an toàn. EO 14028 cũng khuyến khích các nhà cung cấp đáp ứng các tiêu chuẩn an ninh mạng liên bang, vì các hợp đồng của chính phủ có khả năng mang lại cơ hội sinh lợi.

Các ứng dụng và dịch vụ phần mềm hiện đại được xây dựng với các thành phần và phụ thuộc khác nhau từ nhiều nguồn. Các thành phần và phụ thuộc đó có thể bao gồm phần mềm mã nguồn mở, mã độc quyền, API tùy chỉnh, khung ngôn ngữ lập trình và thư viện phần mềm. Toàn bộ các nguồn tạo nên các ứng dụng phần mềm được coi là một phần của chuỗi cung ứng phần mềm.

Hóa đơn vật liệu phần mềm khác với siêu dữ liệu phần mềm ở chỗ siêu dữ liệu phần mềm có thể cung cấp thêm thông tin về việc sử dụng rộng hơn và mục đích của ứng dụng, trong khi SBOM tập trung vào các thành phần riêng lẻ trong ứng dụng và các phụ thuộc của chúng.

Các tổ chức cũng dựa vào SBOM của họ để giải quyết:

Tuân thủ pháp luật
Hiệu suất an ninh mạng
Quản lý rủi ro
Ứng phó sự cố
Hiệu quả hoạt động
Quản lý lỗ hổng bảo mật

SBOM bao gồm những gì?

Cơ quan Quản lý Thông tin và Viễn thông Quốc gia (NTIA) đã ban hành hướng dẫn chi tiết các yếu tố tối thiểu cho SBOM, bao gồm các lĩnh vực cơ bản sau:

Tên và phiên bản thành phần: Mỗi thành phần phần mềm phải được xác định và liệt kê, bao gồm tên, số phiên bản, thông tin giấy phép, tên nhà cung cấp, tác giả và dấu thời gian khi dữ liệu SBOM được tạo. Thông tin này cho phép các tổ chức đảm bảo họ đang sử dụng các phiên bản mới nhất và an toàn nhất của từng thành phần. Nếu một thành phần hoặc thành phần con được cập nhật, SBOM phải được cập nhật và phát hành lại.
Phần phụ thuộc phần mềm: SBOM phải bao gồm cây phụ thuộc giữa các thành phần phần mềm, bao gồm cả các phần phụ thuộc chuyển tiếp, để duy trì chức năng phần mềm và hỗ trợ các phương pháp quản lý phụ thuộc hiệu quả. Nếu một sự phụ thuộc thay đổi hoặc một thành phần trở nên lỗi thời, SBOM phải được cập nhật để phản ánh những thay đổi đó.
Tự động hóa: NTIA khuyến nghị mức tự động hóa tối thiểu để tạo SBOM và truyền dữ liệu để các hệ thống khác có thể hiểu và sử dụng dữ liệu SBOM được tạo ra. Bởi vì các ứng dụng phần mềm có thể cực kỳ phức tạp, NTIA đặc biệt khuyên không nên tạo SBOM bằng cách sử dụng các quy trình thủ công.
Quy trình: SBOM yêu cầu các quy trình thu thập dữ liệu liên tục xác định cách tạo SBOM, cách chúng được truy cập và ai có quyền truy cập chúng.
Giấy phép phần mềm mã nguồn mở: Nếu phần mềm sử dụng giấy phép phần mềm mã nguồn mở, điều quan trọng là phải ghi lại loại giấy phép của từng thành phần, cũng như các điều khoản và điều kiện, để ngăn chặn các vấn đề pháp lý. Các tổ chức có thể đảm bảo họ tuân thủ các điều khoản và điều kiện do người tạo thành phần đặt ra bằng cách theo dõi tất cả các giấy phép. Ngoài ra, dữ liệu cấp phép cho phép các tổ chức theo dõi các lỗ hổng hoặc khai thác mã nguồn mở và khắc phục chúng trước khi chúng có thể dẫn đến vi phạm mạng.
Các lỗ hổng đã biết: Liệt kê các lỗ hổng bảo mật đã biết cho từng thành phần giúp các tổ chức giảm thiểu rủi ro tiềm ẩn và cải thiện bảo mật tổng thể của phần mềm của họ. Thông tin này cho phép các nhóm CNTT ưu tiên các bản cập nhật và bản vá để duy trì một môi trường phần mềm an toàn.

Định dạng SBOM tiêu chuẩn

Có một số định dạng tiêu chuẩn để tạo và chia sẻ SBOM. Các định dạng được tiêu chuẩn hóa cung cấp tính nhất quán cho dữ liệu SBOM trong chuỗi cung ứng phần mềm, thúc đẩy tính minh bạch và hợp tác hoàn toàn giữa các bên liên quan khác nhau. Các định dạng SBOM được sử dụng phổ biến nhất hiện nay bao gồm:

CycloneDX, được phát triển bởi Dự án Bảo mật Ứng dụng Web Mở (OWASP)
Thẻ nhận dạng phần mềm (SWID), được phát triển bởi NIST

Trao đổi dữ liệu gói phần mềm (SPDX), được phát triển bởi ISO/IEC theo ISO/IEC 5962

Lợi ích của việc triển khai SBOM

Việc triển khai SBOM có thể là một quá trình khó khăn, nhưng có thể mang lại nhiều lợi ích có thể giúp các tổ chức duy trì bảo mật tốt hơn và giảm thiểu rủi ro lâu dài, bao gồm:

Tăng cường tư thế bảo mật: SBOM cung cấp chiều sâu và khả năng hiển thị hơn về các thành phần phần mềm, giúp các tổ chức xác định, theo dõi và khắc phục các lỗ hổng đã biết.
Tuân thủ cấp phép: SBOM giúp các tổ chức đáp ứng các yêu cầu cấp phép bằng cách theo dõi tất cả các thành phần độc quyền và mã nguồn mở đang được sử dụng. Thông tin cấp phép này cũng giúp các tổ chức đáp ứng các yêu cầu pháp lý và tiêu chuẩn quy định.
Tính minh bạch của chuỗi cung ứng: Xây dựng tính minh bạch của phần mềm đặc biệt quan trọng đối với các tổ chức khi họ bắt đầu mở rộng quy mô. Hiểu được nguồn gốc của từng sản phẩm phần mềm cho phép các tổ chức đánh giá đúng mức độ tin cậy và bảo mật của từng thành phần.
Kiểm tra phần mềm hiệu quả: Kiểm toán phần mềm nên được thực hiện thường xuyên để đánh giá sự tuân thủ, hiệu quả, mức độ quan trọng và sự cần thiết của sản phẩm. SBOM giúp tạo điều kiện thuận lợi cho quá trình này bằng cách cung cấp danh sách đầy đủ từng thành phần được sử dụng, tiết kiệm thời gian và nguồn lực cần thiết để hoàn thành đánh giá.
Quản lý rủi ro và lỗ hổng bảo mật hiệu quả: Theo dõi từng thành phần được sử dụng trong các ứng dụng phần mềm cho phép doanh nghiệp xác định các rủi ro tiềm ẩn và giảm thiểu hoặc khắc phục chúng trước khi chúng có thể bị khai thác.

Những thách thức đối với việc thực hiện SBOM

Mặc dù SBOM có thể giúp hệ sinh thái CNTT của doanh nghiệp luôn có tổ chức, nhưng nhiều quy trình vẫn đang được chuẩn hóa và xác định. Bởi vì vẫn còn sự đa dạng trong việc tạo và sử dụng SBOM, các tổ chức có thể gặp phải một số thách thức ban đầu và kém hiệu quả, chẳng hạn như:

Quy trình triển khai và bảo trì phức tạp: Các doanh nghiệp lớn hơn sử dụng nhiều loại và số lượng sản phẩm phần mềm và cơ sở mã có thể phải đối mặt với những thách thức đáng kể trong việc mua SBOM cho từng ứng dụng. Đổi lại, các nhà cung cấp phần mềm cũng được giao nhiệm vụ bổ sung khi tạo SBOM, đặc biệt là khi phần mềm được cập nhật. Các sản phẩm phần mềm được cập nhật thường xuyên có nghĩa là SBOM cũng phải được cập nhật thường xuyên.
Thiếu tiêu chuẩn hóa: Vì SBOM vẫn còn là một thực tiễn tương đối mới, nên vẫn có các vấn đề về tiêu chuẩn hóa, có thể dẫn đến sự không nhất quán giữa các định dạng và các vấn đề về khả năng tương thích giữa các loại công cụ và nền tảng được sử dụng trong quá trình tạo dữ liệu.
Sử dụng nhiều nguồn lực: Khối lượng lớn công việc cần thiết để tạo và duy trì SBOM có nghĩa là các nhà cung cấp phải dành thời gian và nguồn lực đáng kể cho nhiệm vụ. Ngoài ra, nhân viên đặc biệt trong mỗi nhóm an ninh sẽ cần được đào tạo, đây có thể là một thách thức đối với các tổ chức nhỏ hơn có ưu tiên cao hơn. Các tổ chức sử dụng phần mềm cũng sẽ cần các nhóm hoặc cá nhân chuyên dụng để theo dõi các SBOM để đưa họ vào quy trình mua sắm và kiểm toán.
Bảo mật dữ liệu SBOM: Mỗi tài liệu SBOM chứa thông tin quan trọng về các thành phần phần mềm, điều này có thể dẫn đến các cơ hội vi phạm mới cho cả nhà cung cấp và tổ chức sử dụng ứng dụng. Dữ liệu SBOM phải được giữ bí mật và an toàn, với các quy trình bảo mật nội bộ mới xác định bảo mật dữ liệu của nó.
Thiếu khả năng tích hợp: Bởi vì SBOM vẫn chưa phải là một thực tiễn phổ biến, nên việc tích hợp các quy trình của nó với việc phát triển và triển khai phần mềm hiện có có thể không thực hiện được hoặc có thể cực kỳ khó khăn. Tuy nhiên, có thể đạt được nhiều khả năng tích hợp phần mềm hơn khi nhiều tổ chức áp dụng SBOM vào quy trình của họ.
Sự tham gia của nhà cung cấp: Với các tổ chức có khả năng làm việc với hàng trăm hoặc hàng nghìn nhà cung cấp cung cấp ứng dụng phần mềm, việc để các nhà cung cấp bên thứ ba áp dụng các quy trình mới và tạo ra các SBOM cập nhật, chính xác có thể khó khăn, đặc biệt nếu họ không thấy lợi ích hoặc cảm thấy rằng công việc bổ sung là không cần thiết. Ngoài ra, các nhà cung cấp phần mềm có thể không muốn cung cấp chi tiết thành phần nếu họ cảm thấy rằng họ đang tiết lộ thông tin bí mật, độc quyền.