Syft hay Trivy: SBOM có thể bỏ sót hơn 90%

Syft phù hợp khi cần tạo và lưu SBOM với nhiều dạng đầu ra; Trivy thuận tiện khi muốn tạo SBOM rồi quét lỗ hổng trong cùng bộ công cụ. Cả hai có thể xử lý thư mục mã nguồn và container, nhưng độ đầy đủ phụ thuộc vào tệp có trong đích quét và cách công cụ nhận diện gói.

Nghiên cứu DSN năm 2024 khảo sát 7.876 kho mã và thực hiện một phép thử riêng với requirements.txt: Syft 0.84.1 và Trivy 0.43.0 cùng đạt precision 0,25, recall 0,10; ở một số mẫu cú pháp, cả hai bỏ sót hoàn toàn phụ thuộc, nên tỷ lệ thiếu có thể vượt 90% với đầu vào cụ thể. Recall 0,10 là số đã làm tròn của phép thử đó, không phải tỷ lệ bỏ sót được đo cho mọi dự án hay container.

Đích quét quyết định SBOM mô tả thứ gì

Quét thư mục dự án giúp kiểm kê những gói mà công cụ suy ra từ tệp khai báo, tệp khóa và các thành phần hiện diện trong cây tệp. Quét container lại bắt đầu từ tạo tác đã đóng gói: nó có thể thấy gói hệ điều hành và thư viện trong image, nhưng không thể ghi nhận một phụ thuộc chỉ nằm trong kho mã và đã bị loại khỏi bước build. Hai SBOM khác nhau vì vậy có thể cùng đúng với hai đích quét khác nhau.

Nếu câu hỏi là môi trường triển khai có những thành phần nào, image là đầu vào sát mục tiêu hơn. Nếu cần xét cả công cụ kiểm thử, thư viện phục vụ build hoặc các phụ thuộc chưa đi vào image, hãy quét thư mục dự án. Số gói nhiều hơn tự nó không chứng minh SBOM chính xác hơn: tệp khai báo cũ, thư mục cài đặt còn sót hoặc nhiều dự án con trong cùng kho mã đều có thể làm danh mục khác với phần mềm thực sự được triển khai.

Cùng định dạng, khác đường đi đến quét lỗ hổng

Cả hai công cụ xuất CycloneDX và SPDX, nên yêu cầu trao đổi theo hai chuẩn này chưa đủ để quyết định chọn Syft hay Trivy. Tài liệu định dạng của Syft nêu thêm JSON riêng, giữ nhiều chi tiết về tệp, quan hệ và metadata hơn bản xuất chuẩn; một lần chạy cũng có thể ghi nhiều định dạng. Cách này hữu ích khi nhóm cần giữ bản giàu thông tin để truy vết, đồng thời chuyển bản CycloneDX hoặc SPDX cho hệ thống khác.

Hướng dẫn SBOM của Trivy mô tả lệnh xuất từ image, filesystem và lệnh trivy sbom để nhận SBOM làm đầu vào quét. Có một khác biệt quan trọng trong đầu ra CycloneDX: mặc định lệnh xuất tạo danh mục thành phần mà không kèm kết quả lỗ hổng; muốn đưa kết quả ấy vào tệp phải bật --scanners vuln. Vì thế, việc pipeline tạo thành công tệp CycloneDX chưa cho biết bước đánh giá lỗ hổng đã chạy.

Vì sao tệp khai báo có thể cho danh mục quá ngắn?

requirements.txt có thể chứa ràng buộc phiên bản thay vì phiên bản đã cài, còn phụ thuộc bắc cầu chỉ xuất hiện sau khi trình quản lý gói giải toàn bộ cây phụ thuộc. Khi bộ tạo SBOM đọc metadata mà không thực hiện bước giải tương đương, nó không có đủ dữ liệu để liệt kê mọi gói sẽ được cài. Cú pháp của tệp cũng quan trọng: dòng nối bằng dấu gạch chéo ngược, tệp được tham chiếu bằng -r hoặc gói cài từ đường dẫn và URL có thể được trình cài đặt hiểu khác bộ phân tích metadata.

Trong phép thử Python nêu ở đầu bài, tập đối chiếu là các cặp tên gói và phiên bản mà một lần chạy thử pip dự kiến cài. Precision thấp cho thấy một phần mục được ghi vào SBOM không khớp tập ấy; recall thấp cho thấy nhiều mục của tập cài đặt không có trong SBOM. Đây là hai sai lệch khác nhau. Chỉ đếm số dòng trong SBOM sẽ không cho biết công cụ đã nhận diện đúng phiên bản hay đã tìm được các gói bắc cầu hay chưa.

Tệp khóa thay đổi phép so sánh ra sao?

Tệp khóa thường ghi phiên bản đã được giải cùng nhiều phụ thuộc bắc cầu, trong khi tệp khai báo có thể chỉ nêu yêu cầu trực tiếp. Với một dự án JavaScript, bảng khả năng JavaScript của Syft phân biệt package.json, vốn cung cấp phụ thuộc trực tiếp, với package-lock.json, yarn.lock và pnpm-lock.yaml, vốn có thể cung cấp phụ thuộc bắc cầu. Bảng này cũng nêu cấu hình javascript.include-dev-dependencies để kiểm soát việc đưa phụ thuộc phát triển vào danh mục.

Do đó, so Syft và Trivy trên cùng thư mục chỉ có ý nghĩa khi biết thư mục ấy chứa loại lockfile nào và tệp có còn khớp với khai báo hiện tại hay không. Một SBOM đọc lockfile đã cũ có thể rất dài nhưng vẫn mô tả sai bản build mới. Ngược lại, nếu dự án chỉ có tệp khai báo, việc không thấy một phiên bản phụ thuộc bắc cầu chưa đủ để kết luận bộ phân tích đã xử lý sai: phiên bản ấy có thể chưa được cố định trong dữ liệu đầu vào.

Phụ thuộc phát triển: chênh lệch do chính sách hay bỏ sót?

Với Node.js, tài liệu của Trivy liệt kê lockfile của npm, Yarn, pnpm và Bun để nhận diện phụ thuộc bắc cầu; mặc định công cụ loại phụ thuộc phát triển và có tùy chọn --include-dev-deps để đưa chúng vào. Với Yarn, Trivy còn đọc package.json cạnh lockfile để xác định quan hệ và nhóm phụ thuộc. Điều đó giải thích vì sao hai SBOM từ cùng kho mã có thể lệch dù đều đọc được tệp khóa.

Phạm vi cần kiểm kê phụ thuộc vào câu hỏi bảo mật. Phụ thuộc phát triển đáng quan tâm khi đánh giá môi trường build, kiểm thử hoặc chuỗi cung ứng của kho mã. Với image triển khai, một gói chỉ dùng để build rồi bị loại khỏi image không phải thành phần của image đó. Trước khi coi phần chênh lệch là lỗi nhận diện, cần xác định SBOM có bao gồm phụ thuộc phát triển hay không và liệu đích quét là kho mã hay tạo tác triển khai.

Đối chiếu bằng cùng một mẫu công khai

Có thể dùng image Alpine trong ví dụ của tài liệu Trivy để đối chiếu cách hai công cụ xuất SBOM. Hai lệnh tương ứng là:

Syft: syft alpine:3.15 -o cyclonedx-json=syft.cdx.json
Trivy: trivy image --format cyclonedx --output trivy.cdx.json alpine:3.15

Đây là cú pháp để tái hiện trên cùng đích quét, không phải kết quả thử nghiệm của bài viết. Nếu muốn đánh giá thư mục mã nguồn, đổi cả hai đầu vào sang cùng một thư mục và dùng trivy fs ở phía Trivy; không đối chiếu số gói của thư mục với số gói của image. Với image, nên cố định cùng một bản bằng digest khi thực hiện phép so thực tế, vì nội dung gắn với tag có thể thay đổi.

Quyết định chọn công cụ nằm ở công việc tiếp theo: Syft thuận cho việc giữ JSON giàu chi tiết và xuất thêm bản chuẩn; Trivy thuận cho quy trình tạo SBOM rồi quét lỗ hổng bằng lệnh của chính nó. Ở cả hai trường hợp, hãy đối chiếu những cặp tên gói–phiên bản quan trọng với lockfile hoặc môi trường đã cài, đồng thời ghi rõ phạm vi phụ thuộc phát triển. Đó là cách phân biệt một gói thực sự bị bỏ sót với một gói nằm ngoài đích quét đã chọn.

Đọc thêm: