SBOM và Kỷ luật Kỹ thuật: Cách Tránh Các Rủi Ro Bảo Mật Chuỗi Cung Ứng Như Vụ Trivy

SBOM và Kỷ luật Kỹ thuật: Cách Tránh Các Rủi Ro Bảo Mật Chuỗi Cung Ứng Như Vụ Trivy

Trong bối cảnh các cuộc tấn công vào chuỗi cung ứng phần mềm ngày càng gia tăng, việc đảm bảo an ninh phần mềm trở nên cấp thiết hơn bao giờ hết. Viktor Peterson, thành viên của lực lượng đặc nhiệm CISA làm việc về các bản thiết kế SBOM (Software Bill of Materials - Danh mục Thành phần Phần mềm) và đồng sáng lập sbomify, đã có những chia sẻ sâu sắc về bối cảnh thay đổi của bảo mật chuỗi cung ứng.

Đặc biệt, khi Đạo luật Khả năng Chịu đựng Mạng (Cyber Resilience Act - CRA) của Liên minh Châu Âu (EU) bắt đầu có hiệu lực, ngành công nghiệp đang đứng trước một "khoảnh khắc GDPR" thứ hai. Peterson lập luận rằng SBOM không chỉ là công cụ để tuân thủ pháp lý mà còn mang lại giá trị vận hành to lớn nếu được áp dụng đúng cách, đồng thời cảnh báo về những rủi ro khi chính các công cụ bảo mật như Trivy bị xâm phạm.

Kỹ sư phần mềm đang làm việc với hệ thống

Đạo luật CRA và "Khoảnh khắc GDPR" của ngành phần mềm

SBOM đã tồn tại từ lâu, nhưng động lực thúc đẩy chúng thay đổi mạnh mẽ trong những năm gần đây bắt đầu từ Lệnh hành chính của Mỹ yêu cầu các nhà cung cấp phần mềm cho chính phủ phải cung cấp SBOM. Tuy nhiên, Peterson cho rằng "cây gậy" lớn hơn nhiều là Đạo luật CRA của Châu Âu.

CRA ảnh hưởng đến bất kỳ ai bán sản phẩm vào thị trường Châu Âu, về cơ bản bao gồm mọi thứ kết nối với internet. CRA yêu cầu các nhà sản xuất phải tạo ra SBOM. Peterson ví von đây như một khoảnh khắc GDPR, nhưng với hình phạt nghiêm khắc hơn: thay vì chỉ bị phạt tiền, sản phẩm có thể bị cấm bán tại thị trường Châu Âu. Đây là mối đe dọa lớn enough buộc các công ty phải coi trọng an ninh phần mềm nghiêm túc hơn, thay vì coi chi phí bảo mật là chi phí kinh doanh như trước đây.

SBOM: Không chỉ là Tuân thủ, mà là Giá trị Vận hành

Nhiều công ty vẫn xem việc tạo SBOM như một nhiệm vụ "đánh dấu vào các ô kiểm tra" (tick-box exercise) chỉ để phục vụ mục đích tuân thủ. Peterson khuyên rằng đây là cách tiếp cận sai lầm. Thay vào đó, các nhà phát triển nên coi SBOM như một phương tiện vận hành mạnh mẽ.

SBOM cung cấp khả năng kiểm toán bảo mật tự động và quản lý giấy phép. Ví dụ, các công ty có chính sách không sử dụng mã GPLv3 có thể sử dụng SBOM để kiểm tra sự tuân thủ. Hơn thế nữa, kết hợp với các tệp VEX (Vulnerability Exploitability eXchange), SBOM cho phép xác định chính xác liệu một lỗ hổng CVE có thực sự khai thác được trong bối cảnh cụ thể của hệ thống hay không.

"Thay vì chỉ dựa vào cảnh báo chung chung là 'nâng cấp ngay lập tức', bạn có thể đưa ra một tuyên bố không bị ảnh hưởng. Nó tinh tế hơn nhiều so với những gì Dependabot hay GitHub cung cấp," Peterson chia sẻ.

Kỷ luật Kỹ thuật: Từ Lock Files đến CI/CD

Để tạo ra SBOM chất lượng cao, bước đầu tiên và quan trọng nhất là kỷ luật trong quản lý lock file (tệp khóa). Nhiều hệ sinh thái cũ hoặc tệp khóa kém chất lượng không ghi lại đầy đủ cây dependency (phụ thuộc). Việc chuyển sang các trình quản lý gói hiện đại như UV cho Python hay Bun cho JavaScript không chỉ giúp cải thiện hiệu suất mà còn tạo ra các lock file chất lượng hơn, giúp việc kiểm kê phần mềm chính xác hơn.

Hệ thống CI/CD tự động

Quá trình tạo SBOM phải được tích hợp hoàn toàn vào đường ống CI/CD mà không có sự can thiệp của con người. Tài liệu SBOM kết quả phải được ký kỹ thuật số để đảm bảo một đường dẫn kiểm tra có thể kiểm chứng (auditable paper trail) và ngăn chặn sự thay đổi trong quá trình truyền tải.

Đối với các sản phẩm thương mại phức tạp, việc quản lý vòng đời phát hành (release lifecycle) trở nên khó khăn khi một phiên bản sản phẩm có thể bao gồm hàng chục SBOM khác nhau cho các thành phần như backend, container hay firmware. Công nghệ như Transparency Exchange API (TEA) được đề xuất như một cơ chế phát hiện trung lập cho phép tìm kiếm các tạo tác bảo mật này một cách minh bạch.

Cảnh báo từ vụ việc Trivy và Tấn công chuỗi cung ứng

Một điểm đáng lo ngại mà Peterson nhấn mạnh là việc chính các công cụ bảo mật có thể trở thành vector tấn công. Gần đây, Trivy, một công cụ quét SBOM phổ biến, đã bị xâm phạm trong hai bản phát hành, với mã độc đánh cắp thông tin (infostealers) được nhúng vào gói phần mềm.

Điều này dẫn đến việc toàn bộ tổ chức GitHub của Aqua Security (công ty mẹ của Trivy) có thể đã bị ảnh hưởng. Peterson đã gỡ bỏ Trivy khỏi quy trình của sbomify như một biện pháp phòng ngừa.

Vụ việc này là lời nhắc nhở đau đớn về sự cần thiết của vệ sinh đường ống (pipeline hygiene): sử dụng thông tin đăng xác thực ngắn hạn (như OpenID Connect) và băm commit (commit hashes) thay vì các thẻ phiên bản có thể ghi đè hoặc thông tin đăng nhập dài hạn. Điều này đảm bảo tính toàn vẹn kỹ thuật số liên tục và không thể chối cãi.

Lựa chọn công cụ và Tương lai của SBOM

Khi chọn công cụ, Peterson khuyên các nhà phát triển nên ưu tiên các công cụ đặc thù cho hệ sinh thái (ecosystem-specific tools) thay vì các trình quét tổng quát (generic scanners). Các công cụ đặc thù thường cung cấp dữ liệu metadata tốt hơn và đạt được sự tuân thủ các yếu tố tối thiểu của NTIA.

Tương lai, SBOM được dự đoán sẽ trở thành "công dân hạng nhất" trong các trung tâm tin cậy (trust centers) của doanh nghiệp. Các khuôn khổ tuân thủ trong tương lai như PCI DSS, ISO hay SOC 2 đều dự kiến sẽ yêu cầu SBOM như một bài kiểm tra xem liệu doanh nghiệp có thực sự hiểu những gì đang nằm trong phần mềm của mình hay không.

Việc bắt đầu hành trình SBOM ngay bây giờ không chỉ giúp doanh nghiệp tránh được các rủi ro bảo mật hiện tại mà còn chuẩn bị sẵn sàng cho các yêu cầu pháp lý nghiêm ngặt sắp tới.