Liên hệ

SBOM là gì?

Phần mềm hiện đại được lắp ráp từ các gói nguồn mở để giúp các nhà phát triển đổi mới nhanh hơn và tập trung hơn và các khía cạnh độc đáo của dự án. Do đó, có thể nói rằng quy trình phát triển phần mềm ngày nay cũng gần giống với quy trình sản xuất truyền thống: các thành phần nguồn mở đóng vai trò là các bộ phận và nguyên liệu thô sẽ được lắp ráp thành sản phẩm mới.

Hoá đơn Nguyên vật liệu (Bill of Materials – BOM) trong sản xuất truyền thống là danh sách tất cả các nguyên vật liệu thô, các bộ phận được sản xuất và số lượng tạo nên sản phẩm hoàn chỉnh cuối cùng. Hoá đơn này rất hữu ích trong việc quản lý trạng thái tuân thủ các điều khoản, quy định, quản lý rủi ro và an toàn sản phẩm, vì có thể giúp bạn xác định nhanh chóng các thành phần sai sót hoặc khiếm khuyết trong tất cả các giai đoạn sản xuất và phân phối.

Hoá đơn Nguyên vật liệu Phần mềm (Software Bill of Materials – SBOM) là danh sách tất cả các gói (package) và thư viện (library) trong ứng dụng. SBOM tương đương với hoá đơn nguyên vật liệu sản xuất dưới dạng kỹ thuật số. Giống như một danh mục vật liệu bao gồm tất cả các cụm lắp ráp phụ, SBOM cũng bao gồm các phần phụ thuộc chuyển tiếp hoặc các phần phụ thuộc của các thành phần bạn sử dụng. Và cũng giống như BOM truyền thống, SBOM giúp bạn dễ dàng đánh giá liệu có bất kỳ gói rủi ro nào được đưa vào ứng dụng hay không.

Hoá đơn Nguyên vật liệu Phần mềm là bước đầu tiên trong việc kiểm soát các thành phần phụ thuộc của dự án và quản lý rủi ro từ các thành phần nguồn mở. Trong những năm gần đây, số lượng các cuộc tấn công mạng nhắm vào các thành phần nguồn mở đã tăng vọt, trong đó các cuộc tấn công vào chuỗi cung ứng phần mềm đã tăng đến 300%, chỉ tính riêng năm 2021. SBOM cung cấp cho bạn thông tin chi tiết về các thành phần phụ thuộc và có thể hữu ích trong việc tìm kiếm các lỗ hổng, vấn đề về giấy phép và các thành phần rủi ro khác. Một số tổ chức yêu cầu SBOM khi họ mua phần mềm, như một cách để quản lý bảo mật của chính họ. Cục Quản lý Thông tin và Cục Viễn thông Quốc gia Hoa Kỳ đã hợp tác xuất bản các hướng dẫn về SBOM, đặt nền tảng cho việc yêu cầu SBOM trong việc mua bán phần mềm trong tương lai. Các tiêu chuẩn này phác thảo các yêu cầu tối thiểu đối với SBOM, bao gồm:

– Data Fields: Các trường dữ liệu bắt buộc, cung cấp thông tin tổng quan để nhận dạng thành phần, bao gồm tên nhà cung cấp, tên thành phần, phiên bản, mối quan hệ phụ thuộc, tác giả của SBOM và thời gian dữ liệu được thêm vào SBOM.

– Hỗ trợ tự động hoá: SBOM phải bao gồm hỗ trợ tự động tạo và phân tích cú pháp. Một mục tiêu với hỗ trợ tự động hoá chính là khả năng tương tác giữa các tổ chức. Một SBOM từ một tổ chức cần có cú pháp dễ phân tích mà không cần áp dụng các công cụ mới. Hiện nay, SPDX, CycloneDX và Software Identification Tags là các định dạng đáp ứng hỗ trợ tự động hoá.

– Các thực hành và quy trình: Các tổ chức cần phác thảo các yêu cầu đối với việc sử dụng SBOM, đưa ra hướng dẫn về tần suất hay truyền truy cập hoá đơn, đồng thời ghi lại những nguy cơ đã biết.

Vì sao bạn cần Software Bill of Materials?

Lợi ích cốt lõi của SBOM là cung cấp cho bạn một hồ sơ nhất quán, dễ đọc về các thành phần phụ thuộc của ứng dụng. Báo cáo này có thể được tạo một cách tự động trong bước xây dựng dự án của bạn để đảm bảo bạn luôn có được các thông tin mới nhất. SBOM cũng chuẩn hoá cách liệt kê các thành phần phụ thuộc, giúp việc xem xét chúng trở nên nhất quán và dễ dàng, trong bất cứ hệ sinh thái nào. Có nghĩa là, SBOM là một cách tuyệt vời để kiểm tra các lỗ hổng mới dành cho các nhà phát triển và chuyên gia bảo mật. Ví dụ, tính năng InnerSource Insight của Nexus Lifecycle vốn chỉ hỗ trợ Java và npm khi không có SBOM sẽ hoạt động tốt hơn với rất nhiều hệ sinh thái nếu có SBOM.

Chuẩn hoá dữ liệu phụ thuộc cũng hữu ích trong việc chia sẻ thông tin. Việc cung cấp SBOM ở định dạng tiêu chuẩn giúp khách hàng của bạn biết cách sử dụng thông tin đó.

Liệu tất cả hoá đơn nguyên vật liệu phần mềm có giống nhau?

Ý tưởng về một danh sách chuẩn hoá các thư viện và thành phần phần mềm không hề mới lạ. Theo thời gian, các nhóm phần mềm khác nhau đã tạo ra một số định dạng khác nhau cho hoá đơn nguyên vật liệu phần mềm, mỗi định dạng có mục đích và lợi thế riêng. Dưới đây là hai định dạng phổ biến nhất:

      • – CycloneDX – Đây là định dạng do Dự án Bảo mật Ứng dụng Web mở (Open Web Application Security Project – OWASP) tạo ra và được xây dựng với trọng tâm là vấn đề an ninh mạng. Đây là định dạng yêu thích của Sonatype và được hỗ trợ trong các sản phẩm của họ. Lợi ích lớn nhất của CycloneDX là khả năng đưa thông tin về lỗ hổng bảo mật vào SBOM hoặc liên kết với một VEX (Vulnerability Exploitability Exchange) riêng biệt, hỗ trợ người dùng nhận ra các false positive và các thông tin lỗ hổng phần mềm.

      • – SPDX (Software Package Data Exchange – Trao đổi Dữ liệu Gói phần mềm) – Định dạng này được Linux Foundation phát triển để giúp việc thu thập và chia sẻ gói dữ liệu trở nên dễ dàng hơn. SPDX ưu tiên việc tuân thủ giấy phép hơn là bảo mật.

    Cả CycloneDX và SPDX đều đáp ứng các yêu cầu tối thiểu của Cục Quản lý Thông tin và Viễn thông Quốc gia Hoa Kỳ đối với một hoá đơn nguyên vật liệu phần mềm. 

    SBOM dành cho người làm phần mềm

    Đối với các tổ chức xây dựng dự án, việc duy trì hoá đơn nguyên vật liệu phần mềm là một cách hữu ích để theo dõi các thành phần phụ thuộc của dự án. Việc theo dõi chính xác phiên bản của các gói trong ứng dụng giúp bạn dễ dàng tìm kiếm các thành phần dễ bị tấn công. Bằng cách sử dụng một tiêu chuẩn duy nhất để lưu trữ thông tin phụ thuộc, các nhà phát triển và nhóm bảo mật có thể áp dụng một quy trình được tiêu chuẩn hoá để tìm ra các thành phần dễ bị tấn công. Quy trình này cũng góp phần tăng tính nhất quán và giảm bớt gánh nặng cho bạn khi làm việc trên nhiều hệ sinh thái.

    SBOM cho người tiêu dùng

    Đối với những người sử dụng hoặc mua một ứng dụng, hoá đơn nguyên vật liệu phần mềm hữu ích trong hai trường hợp. Đầu tiên là khi đánh giá một sản phẩm trước khi mua và thứ hai là theo dõi rủi ro đến từ các ứng dụng bên thứ ba.

    Thẩm định

    Khi khách hàng cân nhắc một sản phẩm mới, việc có được hoá đơn nguyên vật liệu phần mềm giúp khách hàng chắc chắn rằng sản phẩm đó đáp ứng các yêu cầu về kiến trúc và an ninh nội bộ của họ. Thông tin chi tiết về sản phẩm giúp họ thêm tin tưởng vào tính bảo mật của ứng dụng. Đó là một cách tiếp cận minh bạch. Giả sử rằng tất cả các phần mềm đều sử dụng thành phần nguồn mở, thì phần mềm của bên thứ ba có SBOM sẽ chứa ít rủi ro hơn phần mềm không có, vì khách hàng có thể theo dõi các vectơ tấn công ứng dụng của họ. Lợi ích này cũng dẫn đến lợi ích thứ hai: giám sát rủi ro của bên thứ ba.

    Giám sát

    Khách hàng có thể sử dụng SBOM mà bạn cung cấp để giám sát an ninh của chính họ. Nhiều công cụ, bao gồm cả Nexus Lifecycle, có thể quét SBOM và tạo danh sách lỗ hổng bảo mật dựa trên ID các thành phần được liệt kê trong hoá đơn. Việc này hỗ trợ người dùng quản lý bảo mật của chính mình, ngay cả khi sử dụng phần mềm độc quyền của bên thứ ba.

    Tạo SBOM như thế nào?

    Việc tạo một hoá đơn nguyên vật liệu phần mềm bằng công cụ tự động là rất đơn giản. Nexus Lifecycle có thể tạo SBOM thông qua giao diện người dùng hoặc API, CycloneDX cũng cung cấp một số công cụ tạo SBOM theo yêu cầu hoặc trong quá trình dựng (build) ứng dụng. Hãy truy cập CycloneDX Tool Center để biết thêm chi tiết.

    • – Nexus Lifecycle hỗ trợ tạo SBOM cho bất kỳ ứng dụng nào đã được quét (scan), chỉ bằng một nút bấm. Quy trình tạo SBOM bằng giao diện của Lifecycle gồm các bước như sau:
    • – Quét một ứng dụng bằng Nexus Lifecycle
    • – Truy cập đường dẫn (nếu quét từ CLI) hoặc điều hướng đến báo cáo quét (scan report) bằng giao diện
    • – Chọn menu Options ở góc phải trên
    • – Nhấn View SBOM
    • – Nhấp chuột phải vào bất kỳ đâu trên trang web và chọn Save as để lưu tập tin hoá đơn

    Tôi nên chia sẻ SBOM khi nào?

    Hoá đơn nguyên vật liệu phần mềm chứa các thông tin về thành phần phần mềm của bạn, và có thể được sử dụng để xác định những lỗ hổng tiềm ẩn trong ứng dụng. Điều này có nghĩa là, bạn có thể quyết định thời điểm và cách thức bạn chia sẻ SBOM của mình. Đối với các dự án có mã nguồn độc quyền hoặc riêng tư, bạn nên cung cấp SBOM cho khách hàng hiện tại của mình và các khách hàng tiềm năng đáp ứng đủ điều kiện.

    Các dự án nguồn mở ít chịu rủi ro từ việc duy trì một hoá đơn nguyên vật liệu phần mềm công khai sẵn có. Thông tin về các thành phần phụ thuộc của dự án đã được công khai và SBOM công khai cũng hữu ích đối với các thành viên trong cộng đồng người dùng có quan tâm đến việc tuân thủ giấy phép và bảo mật.

    Cuối cùng, một thực hành hay nhất cho bạn tham khảo chính là tạo một trang tư vấn công khai để chỉ ra những false positive trong sản phẩm của bạn. Mặc dù thông tin này phải được đưa vào VEX cùng với SBOM, nhưng việc cung cấp công khai sẽ mang lại thêm sự minh bạch và giúp người dùng của bạn có một kênh khác để giám sát sự an toàn của họ, từ đó nâng cao độ tin cậy của họ đối với sản phẩm bạn cung cấp.

     

    Theo Sonatype

    Menu