Phần 3: Tích Hợp Bảo Mật Vào Vòng Đời DevOps
Bài 10: Phân Tích Thành Phần (SCA)
Ứng dụng của bạn được xây dựng từ code của bạn... và 90% là code của người khác. SCA giúp kiểm tra 90% còn lại đó.
Ôn lại bài cũ: Phân Tích Mã Tĩnh (SAST - Bài 9)
Ở bài 9, chúng ta đã dùng SAST để quét mã nguồn *của chúng ta* (white-box). Nhưng các ứng dụng hiện đại phụ thuộc rất nhiều vào các thư viện mã nguồn mở (open-source dependencies). Nếu một trong các thư viện đó có lỗ hổng thì sao?
SCA là gì?
Software Composition Analysis (SCA), hay Phân tích Thành phần Phần mềm, là quá trình tự động hóa việc xác định các thành phần mã nguồn mở (open-source) trong một codebase.
Mục tiêu chính của SCA là phát hiện:
- Lỗ hổng bảo mật đã biết (CVEs) trong các thư viện bạn đang dùng.
- Các vấn đề về giấy phép (License Issues) (ví dụ: bạn có vô tình dùng thư viện có giấy phép GPL, buộc bạn phải mở nguồn toàn bộ code của mình không?).
Tại Sao SCA Cực Kỳ Quan Trọng?
Các ứng dụng hiện đại giống như những tảng băng trôi. Phần code bạn viết (SAST quét) chỉ là phần nổi. 90% chìm bên dưới chính là các thư viện open-source mà SCA nhắm tới.
Case Study Nổi Bật: Log4Shell (CVE-2021-44228)
Năm 2021, một lỗ hổng thực thi mã từ xa (RCE) nghiêm trọng được tìm thấy trong Log4j, một thư viện ghi log Java cực kỳ phổ biến. Hàng triệu ứng dụng - từ máy chủ Minecraft đến các hệ thống doanh nghiệp lớn - đều bị ảnh hưởng, không phải vì code *của họ* sai, mà vì họ dùng chung một thư viện có lỗ hổng. Đây chính là nơi SAST "bó tay" và SCA tỏa sáng.
SCA Hoạt Động Như Thế Nào?
1. Quét Manifest
Công cụ SCA đọc các file quản lý gói như `package.json`, `pom.xml`, `requirements.txt`.
2. Dựng Cây Phụ Thuộc
Xây dựng một biểu đồ đầy đủ, bao gồm cả các thư viện "ẩn" (transitive dependencies).
3. So Sánh Cơ sở dữ liệu
Đối chiếu từng thành phần với các CSDL lỗ hổng (NVD, GitHub Advisories...).
4. Báo Cáo
Báo cáo các lỗ hổng (CVE) và các rủi ro về giấy phép (GPL, MIT...)
Ví dụ: SCA tìm thấy gì?
Giả sử bạn có file `package.json` (cho Node.js) như sau:
{
"name": "my-cool-app",
"version": "1.0.0",
"dependencies": {
// Thư viện 'express' này có vẻ an toàn
"express": "4.17.1",
// Nhưng thư viện 'request' này đã cũ và bị deprecated
"request": "2.88.0"
}
}Một công cụ SCA khi quét sẽ ngay lập tức cảnh báo:
Phát Hiện Lỗ Hổng Nghiêm Trọng!
Thư viện: request@2.88.0
Lỗ hổng: CVE-2023-28155 (Server-Side Request Forgery - SSRF)
Gợi ý sửa lỗi: Nâng cấp lên thư viện thay thế (ví dụ: axios) vì request đã không còn được bảo trì.
Khái niệm liên quan: SBOM là gì?
Software Bill of Materials (SBOM)
Hãy nghĩ về SBOM như một "danh sách thành phần" (giống như trên đồ hộp). Nó là một file mô tả chi tiết *tất cả* các thành phần, thư viện, và cả các phụ thuộc của chúng, có trong một phần mềm.
SCA là *hành động* quét, còn SBOM là *kết quả* của việc quét đó (là một bản kê khai). SBOM đang trở thành một yêu cầu bắt buộc trong nhiều ngành công nghiệp, đặc biệt là khi làm việc với chính phủ Hoa Kỳ.
Các Công Cụ SCA Phổ Biến
Snyk Open Source
Cực kỳ mạnh mẽ và thân thiện với developer. Snyk quét và cung cấp các gợi ý sửa lỗi rất rõ ràng (ví dụ: "chỉ cần nâng cấp lên phiên bản X.Y.Z").
Điểm mạnh: Tích hợp IDE, sửa lỗi dễ dàng, CSDL lỗ hổng rất tốt.
Trivy (của Aqua Security)
Trivy là một công cụ đa năng. Ngoài việc quét lỗ hổng container (chúng ta sẽ học sau), nó còn quét được filesystem và repository, bao gồm cả các file `package.json`, `pom.xml`.
Điểm mạnh: Mã nguồn mở, nhẹ, dễ dùng trong CI, đa năng (quét cả container và code).
OWASP Dependency-Check
Một công cụ mã nguồn mở "cổ điển" từ OWASP. Nó quét các project (đặc biệt mạnh với Java và .NET) và so sánh với CSDL NVD.
Điểm mạnh: Mã nguồn mở 100%, hỗ trợ nhiều loại project, báo cáo chi tiết.
SAST + SCA = Bảo Vệ Toàn Diện Codebase
Bằng cách kết hợp SAST (quét code của bạn) và SCA (quét code của người khác), bạn đã có một tuyến phòng thủ cực kỳ vững chắc cho mã nguồn.
Nhưng... nếu code an toàn, thư viện an toàn, mà ứng dụng khi *chạy* lên lại bị lỗi thì sao? Đó là lúc chúng ta cần "thử" tấn công nó.
