Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Bảo mật & Quyền riêng tư
#CBOM#CycloneDX#암호 민첩성#양자내성암호#암호 인벤토리
Cập nhật lần cuối · 2026-11-03

Bảng kê vật tư mật mã (CBOM, Cryptographic Bill of Materials)

1. Tổng quan

Định nghĩa: Bảng kê vật tư mật mã (CBOM, Cryptographic Bill of Materials) là một bản kiểm kê tài sản mật mã ở dạng máy đọc được, ghi lại các thuật toán mật mã, khóa, chứng thư, giao thức và thư viện mật mã cấu thành hệ thống, cùng với phiên bản, tham số, cường độ an toàn, vị trí sử dụng và quan hệ phụ thuộc giữa chúng.

Bảng kê vật tư phần mềm (SBOM) truyền thống tập trung vào việc nhận diện các gói, thư viện và container cấu thành ứng dụng, nâng cao khả năng nhìn thấy chuỗi cung ứng. Tuy nhiên, SBOM cho biết "dùng thư viện nào" nhưng không giải thích đến mức "thư viện đó thực sự dùng thuật toán mật mã nào, với độ dài khóa bao nhiêu, ở đâu." Ví dụ, dù dùng cùng một phiên bản OpenSSL, một dịch vụ có thể thực hiện bắt tay TLS bằng RSA-2048 trong khi một dịch vụ khác lại kiểm tra toàn vẹn bằng MD5 được mã hóa cứng, mà chỉ với SBOM thì không thể phân biệt được sự khác biệt này.

Đằng sau sự xuất hiện của CBOM là sự phát triển của máy tính lượng tử và áp lực chuyển đổi kéo theo. Khi một máy tính lượng tử chịu lỗi đủ lớn xuất hiện, thuật toán Shor có thể vô hiệu hóa mật mã khóa công khai như RSA và ECC, biến mối đe dọa "Harvest Now, Decrypt Later" — đánh cắp và lưu trữ bản mã hôm nay để giải mã trong tương lai — thành hiện thực. Để ứng phó, NIST đã chốt các tiêu chuẩn mật mã kháng lượng tử (PQC) vào năm 2024 với FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) và FIPS 205 (SLH-DSA), còn các lộ trình chuyển đổi (như NIST IR 8547) đề xuất đẩy dần các thuật toán dễ bị tổn thương trước lượng tử sang trạng thái không khuyến nghị (deprecated) khoảng năm 2030 và cấm dùng (disallowed) khoảng năm 2035 (lịch trình chi tiết và việc là bản dự thảo hay bản cuối cần được kiểm chứng theo tài liệu gốc).

Vấn đề là hầu hết tổ chức thậm chí không nắm chính xác "mình dùng mật mã nào, ở đâu, với tham số gì." Không có bản kiểm kê thì không thể ước lượng phạm vi đối tượng cần chuyển đổi, không thể xác định thứ tự ưu tiên chuyển đổi, và cũng không thể chứng minh việc chuyển đổi đã hoàn tất. CBOM chính là bản kiểm kê được chuẩn hóa lấp vào khoảng trống "khả năng nhìn thấy mật mã" này, là điều kiện tiên quyết và điểm khởi đầu cho tính linh hoạt mật mã (Crypto-Agility) và chuyển đổi PQC.

Bài luận này trình bày nguyên lý cấu thành và mô hình dữ liệu của CBOM, vòng đời tạo lập và vận hành, mối quan hệ cùng khác biệt với SBOM, sự liên kết với tính linh hoạt mật mã và chuyển đổi PQC, cùng chiến lược áp dụng và các cân nhắc dưới góc nhìn Kỹ sư chuyên nghiệp.

2. Nguyên lý cấu thành và mô hình dữ liệu của CBOM

2.1 Vì sao là "quan hệ và bối cảnh" chứ không phải "danh mục thành phần"

Tài sản mật mã khác với gói phần mềm thông thường ở chỗ chỉ liệt kê thôi thì không thể đánh giá rủi ro. Cùng là AES nhưng chế độ CBC 128-bit và chế độ GCM 256-bit có thuộc tính an toàn rất khác nhau, và cùng là RSA nhưng 2048-bit để ký và 1024-bit để trao đổi khóa có mức độ phơi nhiễm trước mối đe dọa lượng tử và cổ điển hoàn toàn khác nhau. Do đó đơn vị nhận diện của CBOM không phải là "tên thuật toán" mà phải là một tài sản mật mã gom lại thuật toán, chế độ, độ dài khóa, cường độ an toàn, mục đích và vị trí triển khai.

Hơn nữa, rủi ro mật mã được khuếch đại không phải ở từng tài sản riêng lẻ mà ở quan hệ phụ thuộc giữa các tài sản. Chẳng hạn, khóa riêng của máy chủ (vật liệu mật mã liên quan) gắn với chứng thư X.509 (certificate) chứa nó, chứng thư đó được dùng trong giao thức TLS 1.2 (protocol), và giao thức đó phụ thuộc vào trao đổi khóa RSA và chữ ký SHA-256 (algorithm). Khi một nút bị đánh giá là dễ bị tổn thương trước lượng tử, phải lần ngược lên các tài sản và dịch vụ cấp cao phụ thuộc vào nó để ước lượng phạm vi ảnh hưởng, và CBOM thể hiện đồ thị phụ thuộc này, mở rộng phạm vi phân tích từ "có gì" sang "cái gì phụ thuộc vào cái gì và ảnh hưởng lan tới đâu."

2.2 Sơ đồ khái niệm cấu thành tổng thể của CBOM

flowchart LR
  subgraph SRC["Nguồn thu thập"]
    CODE["Mã nguồn(phân tích tĩnh)"]
    BIN["Nhị phân·thư viện"]
    CFG["Cấu hình·kho chứng thư"]
    NET["Mạng·quét TLS"]
  end
  subgraph CBOM["CBOM(CycloneDX 1.6)"]
    ALG["algorithm(thuật toán·chế độ·cường độ)"]
    CERT["certificate(X.509 v.v.)"]
    PROT["protocol(TLS·SSH·IPsec)"]
    MAT["related-crypto-material(khóa·token)"]
  end
  subgraph USE["Khai thác"]
    RISK["Phân tích rủi ro lượng tử·tuân thủ"]
    PLAN["Ưu tiên chuyển đổi PQC"]
    PROOF["Chứng cứ hoàn tất·kiểm toán"]
  end
  CODE --> ALG
  BIN --> ALG
  CFG --> CERT
  CFG --> MAT
  NET --> PROT
  ALG --> RISK
  CERT --> RISK
  PROT --> RISK
  MAT --> RISK
  RISK --> PLAN --> PROOF

Như hình trên, CBOM nằm ở trung tâm của một đường ống trích xuất tài sản mật mã từ nhiều nguồn thu thập, chuẩn hóa chúng theo một lược đồ tiêu chuẩn, rồi đưa vào phân tích rủi ro, lập kế hoạch chuyển đổi và chứng cứ kiểm toán. Điểm quan trọng là nguồn thu thập không chỉ có một. Chỉ phân tích tĩnh mã nguồn thì không thể biết bộ TLS nào thực sự được thương lượng trong môi trường vận hành, và chỉ quét mạng thì không thể tìm ra các đường mật mã tiềm ẩn chưa dùng trong mã, nên một CBOM đáng tin cậy được tạo ra bằng cách hợp nhất và khử trùng lặp nhiều nguồn.

2.3 CycloneDX 1.6 và mô hình dữ liệu CBOM

CBOM không phải là một định dạng độc quyền mà dựa trên năng lực biểu diễn tài sản mật mã được bổ sung trong OWASP CycloneDX 1.6. Nó được thiết kế dưới sự dẫn dắt của IBM Research, được giới thiệu trong bản phát hành CycloneDX 1.6 năm 2024 cùng với Attestations (chứng cứ), và đặc tả CycloneDX đã được chuẩn hóa thành ECMA-424, đạt vị thế của một tiêu chuẩn quốc tế. Điểm cốt lõi là nó tái sử dụng "cùng định dạng và cùng hệ sinh thái công cụ" với SBOM hiện có, nên tổ chức có thể đặt tài sản mật mã lên trên đường ống tạo lập, kiểm chứng và phân phối SBOM mà họ đã vận hành.

CycloneDX phân loại tài sản mật mã qua cryptoProperties.assetType của một component, và các kiểu tiêu biểu như sau.

assetType Ý nghĩa Ví dụ ghi nhận Trọng tâm phân tích rủi ro
algorithm Thuật toán·nguyên thủy mật mã RSA-2048, AES-256-GCM, SHA-1 Tính dễ tổn thương trước lượng tử, cường độ an toàn (112/128bit), thuộc diện phế bỏ hay không
certificate Chứng thư khóa công khai Chứng thư máy chủ X.509 Thuật toán ký, thời hạn hiệu lực, độ tin cậy chuỗi
protocol Giao thức an toàn TLS 1.2/1.3, SSH, IPsec Khả năng thương lượng phiên bản·bộ mã dễ tổn thương
related-crypto-material Khóa, token và vật liệu bổ trợ Khóa riêng, khóa bí mật, token Vị trí lưu trữ, vòng đời, kiểm soát truy cập

Mỗi tài sản được kết hợp với biến thể thuật toán (primitive), bộ tham số, mức NIST, trạng thái chứng nhận, thư viện triển khai cùng với chứng cứ (evidence) chỉ tới "nó được dùng ở tệp nào, dòng nào trong mã." Nhờ liên kết chứng cứ này, CBOM trở thành một bản kiểm kê kiểm chứng được dựa trên mã và cấu hình thực tế chứ không chỉ là một tuyên bố, cho phép xác định ngay điểm cần sửa trong công việc chuyển đổi.

3. Vòng đời tạo lập và vận hành CBOM

3.1 Phát hiện (Discovery)·chuẩn hóa·hợp nhất

Bước đầu tiên của việc tạo lập CBOM là tự động phát hiện việc dùng mật mã. Ở mức mã nguồn, trình phân tích tĩnh trích xuất lời gọi API mật mã, hằng số thuật toán và độ dài khóa (các công cụ kiểu Sonar/CBOMkit của IBM là tiêu biểu); ở mức nhị phân, nhận diện các thư viện mật mã được liên kết và các ký hiệu; ở mức vận hành, trình quét TLS/SSH thu thập các giao thức, bộ mã và chứng thư thực sự được thương lượng. Vì các nguồn khác nhau báo cáo trùng lặp cùng một tài sản, chúng được chuẩn hóa và khử trùng lặp bằng khóa là thuật toán, tham số và vị trí, rồi hợp nhất thành một đồ thị nhất quán duy nhất.

Khó khăn thực tiễn ở đây là xử lý ra sao "đường có vẻ tồn tại về mặt tĩnh nhưng không được thực thi" và "đường chỉ lộ ra khi động." Một lời gọi MD5 trong mã có thể là mã chết, trong khi ngược lại một thuật toán được chọn lúc chạy qua cấu hình bên ngoài lại không bị phân tích tĩnh bắt được. Do đó các tổ chức trưởng thành kết hợp kết quả tĩnh với "bằng chứng sử dụng (tần suất gọi, mẫu lưu lượng)" để trọng số hóa tính hiệu lực của một tài sản.

3.2 Phân tích·ưu tiên·chuyển đổi·chứng cứ

CBOM đã thu thập được kết hợp với các quy tắc rủi ro và quy đổi thành điểm rủi ro theo từng tài sản. Các quy tắc tiêu biểu là: (1) có phải khóa công khai dễ tổn thương trước lượng tử (RSA·ECC·DH) không, (2) có phải di sản dễ tổn thương cả về mặt cổ điển (MD5·SHA-1·DES·RC4·TLS 1.0) không, và (3) cường độ an toàn có ở mức 112-bit khiến lịch phế bỏ sớm hơn không. Điểm rủi ro này được nhân với độ nhạy cảm dữ liệu, bề mặt phơi nhiễm và vòng đời (có phải dữ liệu cần bảo vệ dài hạn không) để tính ra thứ tự ưu tiên chuyển đổi. Tài sản càng đòi hỏi tính bảo mật dài hạn thì mối đe dọa "Harvest Now, Decrypt Later" càng lớn, nên việc chuyển đổi PQC được đẩy lên sớm.

sequenceDiagram
  participant Dev as Phát triển·vận hành
  participant Scan as Công cụ phát hiện
  participant CB as Kho CBOM
  participant Risk as Bộ máy rủi ro·chính sách
  participant PM as Quản lý chuyển đổi
  Dev->>Scan: Yêu cầu quét mã·nhị phân·TLS
  Scan->>CB: Nộp tài sản mật mã·chứng cứ (CycloneDX)
  CB->>CB: Chuẩn hóa·khử trùng lặp·dựng đồ thị phụ thuộc
  CB->>Risk: Chuyển tài sản·quan hệ phụ thuộc
  Risk->>Risk: Đánh giá rủi ro lượng tử·di sản·cường độ
  Risk->>PM: Tính ưu tiên·phạm vi ảnh hưởng
  PM->>Dev: Chỉ định backlog chuyển đổi·điểm cần sửa
  Dev->>CB: Quét lại sau chuyển đổi (phản ánh ML-KEM·ML-DSA)
  CB->>Risk: Kiểm chứng lại việc chuyển đổi đã hoàn tất chưa

Khi chuyển đổi xong, cùng đường ống đó quét lại để chứng minh bằng CBOM rằng các tài sản dễ tổn thương trước lượng tử đã được loại bỏ và thay bằng thuật toán PQC. Kết hợp với CycloneDX Attestations, có thể để lại bản ghi được ký về "ai đã thỏa mãn kiểm soát nào, khi nào và trên cơ sở gì," cho phép báo cáo tiến độ chuyển đổi tới cơ quan quản lý và khách hàng ở dạng máy đọc được.

4. So sánh với SBOM·QBOM, và mối quan hệ với tính linh hoạt mật mã

CBOM không phải là khái niệm cạnh tranh với SBOM mà là đối tác bổ sung, chuyên biệt hóa. Nếu SBOM xử lý "được làm từ cái gì (thành phần)," thì CBOM xử lý việc các thành phần đó "dùng mật mã nào và dùng ra sao (hành vi và tài sản mật mã)." Vì cả hai chia sẻ cùng định dạng CycloneDX, chúng có thể được chứa chung trong một tài liệu BOM.

Phương diện SBOM CBOM Ghi chú (góc nhìn QBOM)
Quan tâm bậc một Gói·thư viện·phụ thuộc Thuật toán·khóa·chứng thư·giao thức mật mã QBOM diễn giải·mở rộng CBOM theo góc rủi ro lượng tử
Câu hỏi cốt lõi Cái gì đã đi vào Dùng mật mã nào ở đâu Cái gì dễ tổn thương lượng tử và phải đổi trước khi nào
Công dụng chính Theo dõi thư viện·giấy phép dễ tổn thương Khả năng nhìn thấy mật mã·chuyển đổi PQC·tuân thủ Lập lịch·ưu tiên chuyển đổi
Tiêu chuẩn CycloneDX, SPDX CycloneDX 1.6 (ECMA-424) Vẫn đang hội tụ, lưu ý lẫn lộn thuật ngữ

Lý do căn bản khiến so sánh này tạo ra khác biệt là vì "cơ sở phán định sự đồng nhất" khác nhau. Một gói có thể được phán định là đồng nhất khá rõ ràng bằng phiên bản và băm, nhưng một tài sản mật mã, dù cùng tên, vẫn mang rủi ro khác nhau nếu chế độ, cường độ, mục đích hay triển khai khác nhau, nên CBOM đòi hỏi bắt buộc các thuộc tính và chứng cứ phong phú hơn. Trong thực tiễn thuật ngữ QBOM (Quantum-safe/Cryptography BOM) cũng được dùng, và tốt nhất nên hiểu đây là cách gọi chuyên biệt hóa của CBOM từ góc nhìn chuyển đổi an toàn lượng tử (tránh khẳng định vì tiêu chuẩn và thuật ngữ còn đang hội tụ).

Mối quan hệ với tính linh hoạt mật mã cũng quan trọng. Tính linh hoạt mật mã là "năng lực thiết kế hệ thống sao cho một thuật toán có thể được thay thế bằng chính sách và cấu hình thay vì bị mã hóa cứng khắp nơi trong mã." Không có CBOM thì không biết phải đổi ở đâu nên tiền đề của tính linh hoạt sụp đổ; và không có tính linh hoạt thì khó thực sự thay thế các tài sản mà CBOM đã nhận diện. Nói cách khác, CBOM là "khả năng nhìn thấy," tính linh hoạt mật mã là "năng lực thay thế," và chỉ khi hai yếu tố kết hợp thì chuyển đổi PQC mới trở thành một quy trình lặp lại được và đo lường được.

5. (Chuyên sâu) Xu hướng pháp lý·chính sách và chiến lược áp dụng thực tiễn

Sự trỗi dậy của CBOM không chỉ gắn với xu hướng công nghệ mà còn ăn khớp với áp lực chính sách. Tại Hoa Kỳ, đang hình thành xu thế yêu cầu các cơ quan liên bang và nhà thầu đạt các mốc chuyển đổi kháng lượng tử (ví dụ các hệ thống giá trị cao·tác động cao vào khoảng năm 2030), và các thảo luận như sửa đổi FAR dự kiến sẽ lan rộng việc tuân thủ NIST PQC ra toàn chuỗi cung ứng (lịch trình và phạm vi áp dụng cụ thể cần được kiểm chứng theo tài liệu gốc). NIST IR 8547 đưa ra lộ trình chuyển đổi đẩy các thuật toán dễ tổn thương trước lượng tử như RSA·ECC sang không khuyến nghị năm 2030 và cấm dùng năm 2035, và vì thời điểm áp dụng với cường độ 112-bit và 128-bit có thể khác nhau nên phải gắn thẻ cường độ an toàn trong CBOM.

Cốt lõi của áp dụng thực tiễn là cách tiếp cận theo giai đoạn. Giai đoạn 1 là phát hiện, kiểm kê việc dùng mật mã toàn doanh nghiệp bằng CBOM để biến "không biết" thành "biết." Như trường hợp một tổ chức tài chính quét cấu hình TLS của hàng nghìn dịch vụ và phát hiện hàng trăm TLS 1.0/1.1 và nhiều RSA-1024, chỉ riêng việc phát hiện đã làm lộ ra di sản có thể xử lý ngay. Giai đoạn 2 là ưu tiên hóa, đặt lên trên dữ liệu bảo mật dài hạn, bề mặt phơi nhiễm ra ngoài và các hệ thống thuộc diện quản lý. Giai đoạn 3 là chuyển đổi lai, áp dụng trao đổi khóa lai dùng đồng thời thuật toán truyền thống và PQC cho những vùng khó chuyển đổi PQC độc lập ngay, bảo đảm đồng thời tính tương thích và an toàn. Giai đoạn 4 là kiểm chứng liên tục, nội tại hóa việc tạo CBOM vào CI/CD để tạo "cổng chính sách" làm hỏng bản dựng khi mã mới đưa vào một thuật toán bị cấm.

Trong quá trình này, CBOM vận hành như một ngôn ngữ chung nối các bộ phận phát triển, an toàn, pháp lý và kiểm toán. Giá trị thực tiễn lớn nhất là lập trình viên có thể trao đổi về điểm cần sửa, đội an toàn về thứ tự ưu tiên rủi ro, đội tuân thủ pháp lý về chứng cứ tuân thủ, và đội kiểm toán về cấu hình mật mã tại một thời điểm cụ thể, tất cả qua cùng một CBOM, mỗi bên theo góc nhìn của mình.

6. Cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

  • Chiến lược chuyển đổi: Việc áp dụng CBOM nên được tiếp cận không phải là "đổi hết sang PQC" mà là xây dựng một hệ thống quản trị "nhìn trước, định ưu tiên, rồi đổi theo cách lặp lại được." Chỉ khi nội tại hóa vòng đời phát hiện→phân tích→chuyển đổi→chứng cứ vào CI/CD thì nó mới định hình thành quản lý liên tục chứ không phải một cuộc khảo sát một lần.
  • Đánh đổi: Phân tích tĩnh toàn diện nhưng có dương tính giả (mã chết) và bỏ sót đường động; quét mạng hiệu quả nhưng bỏ sót lời gọi nội bộ và tài sản ngoại tuyến. Không nên dựa vào một nguồn duy nhất mà hợp nhất nhiều nguồn trong khi trọng số hóa tính hiệu lực của tài sản trên cơ sở bằng chứng để giảm nhiễu.
  • Liên kết với tính linh hoạt mật mã: Để thực sự thay thế các tài sản mà CBOM nhận diện, một thiết kế linh hoạt tách mật mã thành các tầng trừu tượng và cấu hình phải đi trước hoặc song hành. Khả năng nhìn thấy (CBOM) và năng lực thay thế (agility) là một cặp không thể tách rời.
  • Tiêu chuẩn·thuật ngữ chưa chín: Vì các thuật ngữ và lược đồ như CBOM·QBOM·cryptoProperties còn đang hội tụ, hãy lấy một tiêu chuẩn mở như ECMA-424 (CycloneDX) làm chuẩn để tránh bị khóa (lock-in) vào một định dạng của nhà cung cấp cụ thể, và đồng thời bảo đảm khả năng tương hợp với SPDX và các chuẩn khác.
  • Rủi ro của chính bản thân an toàn: CBOM cũng là một bản đồ tấn công chứa "ở đâu có mật mã yếu và khóa nào." Nếu không áp dụng kiểm soát truy cập, ký và bảo vệ toàn vẹn cho chính sản phẩm CBOM, bạn sẽ trao cho kẻ tấn công một danh sách mục tiêu tối ưu.
  • Triển vọng và công nghệ liên kết: Trong tương lai, CBOM nhiều khả năng sẽ hội tụ cùng SBOM·AI SBOM·VEX thành một hệ thống minh bạch chuỗi cung ứng tích hợp, và khi kết hợp với mật mã kháng lượng tử (PQC)·tính linh hoạt mật mã·quản lý khóa/chứng thư zero-trust, nó sẽ phát triển thành trụ cột của quản trị mật mã trong tổ chức.

Tài liệu tham khảo

Tóm tắt một câu: CBOM giúp nhìn thấy các tài sản mật mã — thuật toán, khóa, chứng thư, giao thức — cùng quan hệ phụ thuộc của chúng ở định dạng CycloneDX (ECMA-424), biến tính linh hoạt mật mã và chuyển đổi kháng lượng tử thành một quy trình lặp lại được, đo lường được và chứng minh được, đồng thời là điểm khởi đầu của quản trị mật mã.