Vào ngày 29 tháng 7 năm 2026, CISA đã công bố Các Yếu tố Tối thiểu năm 2026 cho một Software Bill of Materials (SBOM), thay thế cho tiêu chuẩn cơ bản của NTIA đã được áp dụng từ năm 2021, được soạn thảo chung với NSA, FBI và 15 cơ quan an ninh mạng quốc tế.
“Các yếu tố tối thiểu năm 2026 cho Danh sách thành phần phần mềm ( Software )Bill of Materials (SBOM) ” là bản cập nhật tiêu chuẩn của CISA về dữ liệu mà một SBOM phải chứa, và thay đổi quan trọng nhất mang tính cấu trúc chứ không phải về số lượng: các yếu tố năm 2026 không cấm việc tạo SBOM từ danh sách nguồn (source manifests), nhưng yêu cầu người tạo phải khai báo cách thức tạo SBOM, tính băm (hash) cho thành phần thực thi và gắn nhãn cho từng trường mà họ không thể điền thông tin. Một SBOM chỉ dựa trên bản kê khai giờ đây sẽ tự tiết lộ những khoảng trống của chính nó dưới dạng có thể đọc được bằng máy.
MetaDefender Software Supply Chain là nền tảng bảo mật chuỗi cung ứng phần mềm củ OPSWAT, được thiết kế để phân tích các thành phần phần mềm, tệp nhị phân và các lớp hình ảnh container — chính là loại dữ liệu mà các yêu cầu mới về hàm băm, bối cảnh tạo ra và phạm vi bao phủ hiện đang đòi hỏi.
Tổng quan
- 17 trường dữ liệu — 9 trường siêu dữ liệu SBOM, 8 trường dữ liệu thành phần
- 6 phương pháp và quy trình
- 10 lĩnh vực mới, 8 bản cập nhật lớn, 1 lĩnh vực bị loại bỏ (Kiểm soát truy cập, được sáp nhập vào Phân phối và Giao hàng)
- Áp dụng cho tất cả các phần mềm, “bao gồm phần mềm mã nguồn mở, phần mềm trí tuệ nhân tạo và SaaS”
- Đây không phải là những yêu cầu mới — mà là sự hoàn thiện cách thức các tổ chức lập và yêu cầu SBOM
Những thay đổi trong SBOM năm 2026 mà các SBOM chỉ dựa trên nguồn gặp khó khăn nhất trong việc đáp ứng
1. Giá trị băm của thành phần yêu cầu có tệp thực thi
Giá trị băm thành phần và Thuật toán băm thành phần quy định cụ thể đối tượng được băm là gì: “kết quả được tạo ra từ việc áp dụng thuật toán băm mật mã lên một thành phần thực thi.” Không phải mục trong tệp manifest, cũng không phải chuỗi phiên bản được khai báo.
- Trình phân tích cú pháp đọc các tệp package-lock.json, pom.xml hoặc requirements.txt không can thiệp vào thành phần thực thi, do đó cả hai trường băm đều trả về giá trị “không xác định”
- Trong trường hợp đã có hàm băm, thuật toán phải sử dụng Tên văn bản của hàm băm IANA và được phê duyệt bởi một cơ quan có thẩm quyền như NIST
- Hashes là yếu tố giúp người nhận xác nhận rằng thành phần được mô tả chính là thành phần đã được giao
2. Bối cảnh tạo SBOM khiến phương pháp này trở thành một phần của hồ sơ
Bối cảnh tạo SBOM là sự bổ sung ít được chú ý nhất, nhưng lại có ý nghĩa quan trọng nhất về mặt cấu trúc: “giai đoạn tương đối trong vòng đời phần mềm và dữ liệu có sẵn tại thời điểm tác giả SBOM tạo ra SBOM.” CISA định nghĩa ba giá trị — trước khi biên dịch, trong quá trình biên dịch và sau khi biên dịch — và liên kết mỗi giá trị với cách thức SBOM được tạo ra: một SBOM được trích xuất từ mã nguồn sẽ thuộc giai đoạn sớm nhất, trong khi các công cụ phân tích nhị phân sẽ xếp nó vào giai đoạn muộn nhất.
- Các nhóm mua sắm có thể chỉ định giai đoạn vòng đời nào mà họ sẽ chấp nhận, ưu tiên các SBOM được trích xuất từ thành phẩm đã biên dịch hơn là các SBOM ở cấp độ mã nguồn
- Các nền tảng quản lý lỗ hổng có thể đánh giá mức độ nghiêm trọng của các phát hiện dựa trên bối cảnh đã được khai báo
- SBOM có nguồn gốc từ mã nguồn vẫn được chấp nhận, nhưng không còn được coi là tương đương với SBOM được tạo ra từ tệp nhị phân hoàn chỉnh nữa
3. Phạm vi bao quát thay thế cho độ sâu, không có mức tối thiểu
Yêu cầu về mức độ chi tiết năm 2021 chỉ đề cập đến các phụ thuộc cấp cao nhất — một định nghĩa mà CISA hiện nay cho rằng “phản ánh khả năng của các công cụ SBOM vào thời điểm đó, chứ không phải mức độ chi tiết của thông tin cần thiết để đưa ra các quyết định an ninh có căn cứ.” Yêu cầu về phạm vi bao quát khắt khe hơn: “tất cả các thành phần cấu thành phần mềm mục tiêu, bao gồm cả các phụ thuộc gián tiếp. Không có mức độ chi tiết tối thiểu nào.”
Bài kiểm tra này mang tính chức năng. Người nhận “nên có thể kết luận rằng một lỗ hổng bảo mật vừa được báo cáo không ảnh hưởng đến họ nếu SBOM không liệt kê thành phần liên quan đến lỗ hổng đó.” Việc vắng mặt trở thành bằng chứng, điều này chỉ đúng khi phạm vi bao quát đủ đầy đủ. Chỉ riêng việc phân tích tệp manifest khó có thể đạt được tiêu chuẩn đó đối với:
- Mã được liên kết tĩnh và mã được cung cấp sẵn — không để lại mục nào trong tệp manifest
- Các dự án C và C++ — không có trình quản lý gói nào có khả năng theo dõi các tệp DLL và các đối tượng chia sẻ được đưa vào trong quá trình biên dịch
- Mã nguồn được sao chép — mà CISA mô tả là “thực chất là một phụ thuộc, nên được theo dõi tốt hơn dưới dạng một nhánh (fork) và một mối quan hệ phụ thuộc”
- Container lớp hình ảnh — các gói được cài đặt bằng lệnh layer thay vì được khai báo trong tệp manifest
Các thông tin chưa rõ nguồn gốc hiện nay phải được khai báo
- Các tác giả cần phân biệt thông tin mà họ không biết với thông tin bị cố ý giấu giếm
- Các tác giả nên thiết lập một quy trình để người nhận có thể yêu cầu giải thích về những nội dung liên quan đến an ninh đã bị che giấu
- "Các tổ chức có thể coi một SBOM là chưa đầy đủ nếu tác giả của SBOM không cung cấp dữ liệu về các thành phần thiết yếu"
- Quy định về việc chấp nhận sai sót đã được thay thế trên cơ sở rằng các bên nhận “có thể kỳ vọng dữ liệu SBOM là chính xác” — các sai sót do “việc lựa chọn các công cụ không phù hợp” hiện được coi là yếu tố hợp lệ trong quá trình đánh giá rủi ro của bên nhận
Những thay đổi bổ sung mà CISA đã thực hiện đối với các yếu tố SBOM năm 2026
Thay đổi | Đó là gì? | Tại sao điều này lại quan trọng |
Chữ ký của tác giả SBOM (mới) | Chữ ký số liên kết với tác giả của SBOM | Cho phép người nhận xác nhận rằng SBOM là chính xác và không bị thay đổi sau khi ký |
Giấy phép thành phần (mới) | Giấy phép mà từng thành phần được phân phối theo | Các vấn đề liên quan đến bản quyền và rủi ro tuân thủ; CISA đề cập đến các mã định danh giấy phép SPDX |
Dữ liệu có thể xử lý bằng máy (trước đây là Hỗ trợ tự động hóa) | Chỉ SPDX và CycloneDX | SWID đã bị loại bỏ do không được sử dụng rộng rãi; do đó, số định dạng được chấp nhận đã được thu hẹp xuống còn hai |
Nhà sản xuất linh kiện (trước đây là Tên nhà cung cấp) | Mỗi thành phần chỉ được đặt tên cho một tổ chức | Thêm một phương án dự phòng rõ ràng là “nguồn gốc không rõ” khi nguồn không rõ ràng |
Tần suất (đã cập nhật) | Một SBOM mới cho mỗi phiên bản, bản cập nhật và bản dựng có sử dụng các thành phần đã được thay đổi | Rhythm đó rất khó duy trì khi thực hiện thủ công, điều này thúc đẩy các đội hướng tới việc tạo ra nội dung tự động |
Khắc phục khoảng cách sau khi xây dựng
Bản cập nhật năm 2026 phản ánh đánh giá của CISA rằng các công cụ SBOM đã đủ trưởng thành để đặt ra những yêu cầu cao hơn, và thông tin mà cơ quan này hiện kỳ vọng nằm ở giai đoạn sau quá trình xây dựng.
MetaDefender™ Software Supply Chain tạo dữ liệu SBOM trực tiếp từ bản dựng:
- Quét các tệp tài liệu, tệp nhị phân và các lớp hình ảnh container, thay vì chỉ quét các tệp phụ thuộc
- Xác định các tệp nhị phân C, C++ và C# thông qua siêu dữ liệu Portable Executable và phương pháp nhận dạng dựa trên chữ ký
- Tạo SBOM trong CycloneDX và SPDX, đồng thời bổ sung thông tin vào các báo cáo hiện có để phát hiện các thành phần và lỗ hổng bảo mật (CVEs) bị bỏ sót trong các lần quét trước đó
- Tham chiếu chéo đến GHSA, CVE và EUVD, đồng thời đánh dấu các giấy phép không tuân thủ
- Tích hợp với các quy trình CI/CD và kho lưu trữ thành phẩm như JFrog Artifactory, để việc tạo SBOM có thể được thực hiện song song với mỗi lần xây dựng
Để tìm hiểu cách MetaDefender Software Supply Chain có thể hỗ trợ các yêu cầu về SBOM trong suốt vòng đời phát triển:
FAQ
Những thay đổi nào đã được thực hiện đối với các yếu tố tối thiểu của SBOM theo CISA 2026?
Bản cập nhật này bổ sung mười trường dữ liệu mới, thực hiện tám sửa đổi lớn và loại bỏ một thành phần. Thay đổi cấu trúc đáng chú ý nhất là việc thay thế trường “Depth” bằng trường “Coverage”, đồng thời các trường mới như “Component Hash Value”, “SBOM Generation Context” và “SBOM Author Signature” đã nâng cao kỳ vọng về cách thức tạo ra và xác minh dữ liệu SBOM.
Các yếu tố tối thiểu trong SBOM theo CISA 2026 có bắt buộc không?
Không. CISA không quy định thời hạn tuân thủ hay cơ chế thực thi nào, và nêu rõ rằng tài liệu này “không phải là lời khuyên nhằm mục đích tuân thủ, quản lý hay pháp lý”. Tính ràng buộc thực tế xuất phát từ các yêu cầu về mua sắm và từ các quy định tham chiếu đến các tiêu chuẩn cơ bản của SBOM, chẳng hạn như Đạo luật Khả năng chống chịu mạng của Liên minh châu Âu (EU Cyber Resilience Act).
Các yếu tố tối thiểu của SBOM theo tiêu chuẩn CISA 2026 có yêu cầu phân tích tệp nhị phân hay phân tích sau khi xây dựng không?
Không phải một cách rõ ràng. Tuy nhiên, trường “Giá trị băm thành phần” (Component Hash Value) yêu cầu quyền truy cập vào tệp thực thi, trường “Bối cảnh tạo SBOM” (SBOM Generation Context) yêu cầu tác giả khai báo giai đoạn vòng đời, và các trường chưa được điền phải được gắn nhãn là “không xác định”. Do đó, một SBOM chỉ chứa mã nguồn vẫn đáp ứng các yêu cầu về định dạng đồng thời ghi nhận các thông tin còn thiếu của chính nó.
Các yếu tố tối thiểu theo CISA 2026 có áp dụng cho phần mềm AI và SaaS không?
Đúng vậy. Phạm vi áp dụng bao gồm tất cả các phần mềm, bao gồm phần mềm mã nguồn mở, trí tuệ nhân tạo (AI) và phần mềm dưới dạng dịch vụ (SaaS). CISA lưu ý rằng các danh mục này có thể cần thêm các yếu tố cụ thể nhưng không định nghĩa chúng tại đây, mà thay vào đó đề cập đến hướng dẫn chung của G7 về SBOM cho trí tuệ nhân tạo được công bố vào tháng 5 năm 2026.
Các định dạng SBOM nào được chấp nhận trong các yếu tố tối thiểu của CISA 2026?
SPDX và CycloneDX được mô tả là hai định dạng được sử dụng rộng rãi để tạo và sử dụng SBOM. Các thẻ SWID đã bị loại bỏ vì “không phải là định dạng dữ liệu SBOM được sử dụng rộng rãi và có nhiều công cụ hỗ trợ”. Không nên sử dụng các phiên bản đã lỗi thời của bất kỳ định dạng nào cho phần mềm mới.
