# Khi khách hỏi "bản giao có gì", SBOM phải trả lời thay bạn

> Bản kê chỉ có ý nghĩa khi nó kê cả những thư viện bạn chưa từng tự chọn.

Bản gốc: https://fdetimes.net/vi/bach-khoa/sbom-va-giay-phep-ma-nguon-mo-khach-hoi-trong-ban-giao-co-gi/

Thử hình dung tuần cuối trước go-live. Bạn đã dựng xong pipeline, agent chạy ổn trên dữ liệu thật của khách, rồi bộ phận an ninh bên họ gửi sang một email chỉ có một câu: "Trong bản bạn giao có những gì?"

Bạn có thể bị cám dỗ trả lời bằng cách dán file `requirements.txt` hoặc `package.json` vào thân email. Cách đó nhanh và trông có vẻ đầy đủ. Nhưng tài liệu của DevGuard lưu ý rằng các gói bắc cầu (transitive) không xuất hiện trong những file khai báo cấp cao nhất như thế; cây dependency vẫn bị che khuất nếu bạn không chủ động mở ra xem.

Kỹ năng ở đây không nằm ở việc chạy một lệnh sinh file. Bạn phải hiểu khách thực sự đang hỏi gì, giao một bản kê mà công cụ của họ đọc được, và biết bản kê của mình mù ở đâu trước khi khách tìm ra.

## Câu hỏi đó thực ra hỏi về quan hệ

Báo cáo năm 2021 của NTIA định nghĩa SBOM là bản ghi chính thức chứa thông tin chi tiết và quan hệ chuỗi cung ứng của các thành phần dùng để xây dựng phần mềm.

Chữ "quan hệ" nằm ngay trong định nghĩa, không phải phần phụ. Trường dependency relationship trong các yếu tố tối thiểu của NTIA mô tả cách một thành phần thượng nguồn được đưa vào phần mềm.

Về độ sâu, theo phần tóm tắt của FOSSA, một SBOM đạt chuẩn NTIA phải gồm mọi thành phần cấp cao nhất và toàn bộ dependency bắc cầu, hoặc cung cấp đủ thông tin để lần ra chúng. Một manifest dán vào email chỉ đáp ứng được nửa đầu.

Nửa sau mới là chỗ chứa rủi ro. DevGuard, một nhà cung cấp công cụ bảo mật, cho rằng tuyệt đại đa số gói có lỗ hổng trong một ứng dụng điển hình là gói bắc cầu. Đó là nhận định của nhà cung cấp chứ không phải nghiên cứu độc lập, nhưng ai từng in cây dependency ra đều thấy số gói mình tự chọn chỉ là phần nổi.

**Điểm mấu chốt:** Thứ khách lo nhất thường nằm ở thư viện bạn chưa từng tự chọn.

## Bản kê cũng phải nói nó từ đâu ra

Bộ yếu tố tối thiểu năm 2025 của CISA xây trên nền NTIA 2021 và nhấn mạnh định dạng máy xử lý được, để tích hợp vào công cụ ở quy mô lớn. Theo tóm tắt của Sonatype, bản 2025 bổ sung bốn trường: Component Hash, License Information, Tool Name và Generation Context. Mỗi trường khớp với một câu khách hay hỏi kèm theo.

| Trường CISA bổ sung năm 2025 | Câu khách đang thực sự hỏi |
|---|---|
| Component Hash | File này có đúng là file các bạn đã kiểm không? |
| License Information | Bên khách có được phép dùng, sửa, phân phối lại không? |
| Tool Name | Bản kê này do công cụ nào sinh ra, có tin được không? |
| Generation Context | Bản kê được sinh ra trong bối cảnh nào, từ mã nguồn hay từ bản build? |

Hệ quả thực tế: đừng gửi một văn bản chỉ để người đọc. Hãy hỏi đội an ninh của khách họ nạp SBOM vào công cụ nào, theo định dạng nào, rồi giao đúng thứ đó. Một câu hỏi trong buổi kickoff tiết kiệm cho bạn một vòng chuyển đổi định dạng vào phút chót.

## Đi từng dòng qua một bản giao

Giả sử bạn giao một container chứa dịch vụ RAG nội bộ. Dịch vụ khai báo trực tiếp một thư viện parse PDF, và thư viện này lại kéo theo một thư viện xử lý ảnh mà bạn chưa từng nhắc tên. Các tên gói dưới đây là giả định:

```text
rag-service 1.0.0
└── example-pdf-parser 2.4.1      (trực tiếp)
    └── example-image-lib 0.9.2   (bắc cầu)  ← có lỗ hổng đã công bố
```

Nếu bản kê chỉ là danh sách phẳng, cả hai gói đều có mặt nhưng không ai biết gói nào kéo gói nào. SafeDep nhận định SBOM phẳng che mất việc nâng cấp dependency trực tiếp nào sẽ gỡ được gói bắc cầu có lỗ hổng, nên thời gian xử lý sự cố bị kéo dài.

Khi có quan hệ, câu trả lời hiện ra ngay: nâng `example-pdf-parser` lên bản không còn kéo theo `example-image-lib` 0.9.2.

Lỗ hổng chưa phải là tất cả. SafeDep cũng cho rằng vùng khuất này là nơi malware, thư viện lỗi thời và vấn đề giấy phép hay ẩn náu. Thử hình dung `example-image-lib` mang giấy phép copyleft trong khi hợp đồng ghi khách sẽ đóng gói lại bản giao cho đơn vị con: manifest sẽ không bao giờ cho bạn thấy xung đột đó.

Việc của bạn lúc ấy không phải là tự đưa ra phán quyết pháp lý. Hãy đánh dấu thành phần, tìm đường thay thế nếu có, và báo người phụ trách pháp chế phía bạn trước khi file đến tay khách. Bạn tự tìm ra thì nó chỉ là một dòng ghi chú kỹ thuật; để khách tìm ra trước, họ sẽ nghi ngờ cả bản giao.

## CRA đặt sàn, không đặt trần

Với khách bán sản phẩm vào EU, Cyber Resilience Act là lý do câu hỏi này sẽ đến. Theo FOSSA, Phụ lục I của CRA yêu cầu SBOM phủ ít nhất các dependency cấp cao nhất. Chữ "ít nhất" là mức sàn pháp lý, không phải một bản kiểm kê đầy đủ.

Hướng dẫn TR-03183-2 của BSI, cơ quan an ninh mạng Đức, đi xa hơn, dù không có tính ràng buộc và không phải luật EU: phải giải dependency đệ quy trên mỗi nhánh, ít nhất đến thành phần đầu tiên nằm ngoài phạm vi bàn giao.

Với FDE, đây là thước đo thực dụng hơn, vì nó hỏi bản giao chứa gì chứ không chỉ hỏi bạn đã chọn gì.

Vì thế, kể cả khi khách chỉ đòi mức CRA, bạn vẫn nên sinh cây đầy đủ. Nếu một lỗ hổng ở tầng thứ ba được công bố sau go-live, người phải tìm đường gỡ nó vẫn là bạn.

## Năm bước trước khi gửi file

1. Ngay từ kickoff, hỏi khách công cụ và định dạng họ dùng để nạp SBOM.
2. Sinh SBOM lúc build từ đúng artifact sẽ giao, không phải từ máy dev, và ghi lại tên công cụ cùng bối cảnh sinh file.
3. Kiểm độ sâu: bản kê có đủ dependency bắc cầu và quan hệ giữa chúng, mỗi thành phần có version, hash và giấy phép.
4.

Đọc riêng các gói bắc cầu để tìm lỗ hổng, bản lỗi thời và giấy phép xung đột với cách khách định dùng.
5. Viết một đoạn ghi chú phạm vi nói rõ bản kê đi sâu đến đâu, phần nào chưa phủ, sinh lúc nào; mỗi lần vá thì làm lại từ bước 2.

## Những lỗi khiến bản kê phản tác dụng

Lỗi phổ biến nhất là giao một SBOM rồi coi như xong. Sonatype cảnh báo SBOM kém chất lượng là bản thiếu, sai hoặc lỗi thời. Mỗi lần bạn vá dependency tại site khách mà không sinh lại, bản kê cũ rơi vào cả ba và tạo ra cảm giác an toàn giả.

Lỗi kế tiếp là chỉ kê dependency trực tiếp vì CRA nói "ít nhất cấp cao nhất". Đó là mức tối thiểu để không vi phạm, trong khi rủi ro thật của khách nằm ở các gói bắc cầu và ở quan hệ giữa chúng. Một bản kê chỉ có tầng trên cùng đúng luật nhưng không trả lời được câu khách thực sự hỏi.

Lỗi thứ ba là có đủ gói nhưng bỏ quan hệ, tức là một SBOM phẳng. Khi sự cố xảy ra, đội của khách phải tự dựng lại cây để biết cần nâng cấp gì, đúng lúc họ ít thời gian nhất.

Một điểm nhỏ nên làm đúng từ đầu: ghi giấy phép bằng mã định danh chuẩn thay vì chuỗi tự do kiểu "Apache license v2". Chuỗi tự do khiến công cụ của khách khó đọc và đẩy việc kiểm lại về cho con người, đi ngược tinh thần máy xử lý được mà CISA nhấn mạnh.

## Kỹ năng đáng ghi vào CV

Khi đọc tin tuyển FDE, hãy để ý: mô tả công việc càng nhắc nhiều đến kiểm duyệt an ninh, quy trình mua sắm của khách hay triển khai on-prem, bạn càng nên chuẩn bị cho câu hỏi "bản giao có gì". Đó là suy luận từ bản chất công việc, không phải quy luật, nên hãy hỏi thẳng nhà tuyển dụng trong buổi phỏng vấn.

Trong CV, đừng viết chung chung "quan tâm đến bảo mật". Hãy ghi một dòng cụ thể: đã sinh và duy trì SBOM có đủ dependency bắc cầu và quan hệ cho một bản giao, phát hiện một xung đột giấy phép trước khi khách review.

Một dự án cá nhân có SBOM đủ cả cây dependency, kèm ghi chú phạm vi, là bằng chứng dễ kiểm hơn mọi lời tự giới thiệu.

Lần tới khi email một câu ấy đến, bạn sẽ không dán `requirements.txt`. Bạn gửi một file công cụ của khách nạp được ngay, kèm một dòng ghi rõ bản kê đi sâu đến đâu và phần nào nó chưa phủ.

**Thử ngay tuần này:**

- Sinh SBOM cho dự án gần nhất bạn giao, rồi đếm xem có bao nhiêu gói bắc cầu không có trong file manifest
- Chọn một gói bắc cầu trong cây và lần ngược lên: nếu nó có lỗ hổng, bạn sẽ nâng cấp dependency trực tiếp nào để gỡ nó
- Viết sẵn một đoạn ghi chú phạm vi mẫu: SBOM sinh bằng công cụ nào, lúc nào, đi sâu đến đâu và chưa phủ phần nào

## Nguồn

- [The Minimum Elements For a Software Bill of Materials (SBOM)](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom)

- [The Minimum Required Elements of an SBOM | FOSSA Blog](https://fossa.com/blog/minimum-required-elements-software-bill-of-materials/)

- [SBOM requirements under the CRA (FOSSA)](https://fossa.com/blog/sbom-requirements-cra-cyber-resilience-act)

- [What Is a Transitive Dependency — and Why It Creates Hidden Vulnerabilities](https://docs.devguard.org/explanations/transitive-dependencies/)

- [SBOM Completeness with Direct & Transitive Dependencies](https://safedep.io/sbom-direct-transitive-deps)

- [What Federal Agencies Need to Know About CISA's 2025 SBOM Minimum Elements](https://www.sonatype.com/blog/what-federal-agencies-need-to-know-about-cisas-2025-sbom-minimum-elements)

- [2025 Minimum Elements for a Software Bill of Materials (SBOM)](https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom)