Log4Shell (2021): một thư viện nguồn mở do tình nguyện viên duy trì và cuộc chạy đua tìm xem "mình đang dùng nó ở đâu"

Lỗ hổng CVE-2021-44228 trong thư viện ghi nhật ký Log4j có điểm CVSS 10, tồn tại từ năm 2013 và ảnh hưởng 93% môi trường đám mây doanh nghiệp theo khảo sát của Wiz và EY. Hội đồng Rà soát An toàn Mạng Mỹ gọi đây là lỗ hổng "đặc hữu". Bài học rủi ro: không có bản kê thành phần phần mềm thì không thể ứng phó nhanh, và phụ thuộc nguồn mở cần được quản lý như phụ thuộc nhà cung cấp.

Nguyễn Thu Hà, PMP

09/10/2026

4 phút đọc 0

Bình luận0

Bối cảnh thực tế

Log4j 2 là thư viện ghi nhật ký phổ biến của hệ sinh thái Java, được nhúng trong vô số ứng dụng, thiết bị và dịch vụ. Ngày 24/11/2021, nhà nghiên cứu Chen Zhaojun thuộc nhóm bảo mật Alibaba Cloud báo riêng lỗ hổng cho Apache Software Foundation. Bản vá đầu tiên được công bố vào khoảng ngày 9/12/2021 (phiên bản 2.15.0), khi mã khai thác đã lan nhanh.

Những dữ kiện được ghi nhận:

Lỗ hổng CVE-2021-44228 cho phép chạy mã từ xa thông qua chức năng tra cứu JNDI/LDAP, có điểm CVSS 10 và tồn tại trong mã nguồn từ năm 2013.
Bản vá đầu chưa đủ: các lỗ hổng liên quan tiếp tục được công bố và sửa ở 2.16.0, 2.17.0 và 2.17.1.
Theo khảo sát của Wiz và EY, 93% môi trường đám mây doanh nghiệp bị ảnh hưởng; mười ngày sau công bố mới khoảng 45% khối lượng công việc dễ tổn thương được vá.
Hội đồng Rà soát An toàn Mạng (CSRB) của Mỹ, trong báo cáo tháng 7/2022, nhận định Log4j là lỗ hổng "đặc hữu" sẽ tồn tại nhiều năm, và cộng đồng nguồn mở chưa được cấp đủ nguồn lực; vào thời điểm có bản vá đã có gần 7.000 dự án nguồn mở phụ thuộc vào Log4j. Báo cáo đưa ra 19 khuyến nghị.

Nhiều tổ chức mất nhiều ngày chỉ để trả lời câu hỏi đơn giản: ứng dụng nào của chúng tôi dùng Log4j, ở phiên bản nào, do ai quản lý? Chính Trung Quốc cũng tạm ngưng tư cách đối tác chia sẻ thông tin đe doạ của Alibaba Cloud trong sáu tháng vì cho rằng việc báo cáo chậm, càng cho thấy chuỗi phối hợp công bố lỗ hổng là một rủi ro riêng.

Phân tích nguyên nhân theo chuẩn PMP

Thiếu kiểm kê tài sản và thành phần (Plan Risk Management / Manage Project Knowledge)
Nhiều đội không có danh sách thành phần phần mềm đang chạy, nên việc xác định phạm vi ảnh hưởng phải làm thủ công trên từng hệ thống. Bản kê thành phần phần mềm (SBOM) là cơ sở dữ liệu tri thức giúp rút ngắn thời gian từ "có cảnh báo" đến "biết mình ở đâu".
Rủi ro phụ thuộc không được ghi vào sổ rủi ro
Thư viện nguồn mở thường được coi là "miễn phí và luôn có sẵn", không có chủ sở hữu rủi ro. Khi một thành phần sâu trong chuỗi phụ thuộc gián tiếp bị lỗi, không ai chịu trách nhiệm theo dõi. Rủi ro đáng ra phải được nhận diện, đánh giá xác suất và tác động ngay từ khâu chọn công nghệ.

Log4Shell (2021): một thư viện nguồn mở do tình nguyện viên duy trì và cuộc chạy đua tìm xem "mình đang dùng nó ở đâu"

Bối cảnh thực tế

Phân tích nguyên nhân theo chuẩn PMP

Thiếu kiểm kê tài sản và thành phần (Plan Risk Management / Manage Project Knowledge)

Rủi ro phụ thuộc không được ghi vào sổ rủi ro

Ứng phó theo kiểu chữa cháy thay vì kế hoạch ứng phó rủi ro (Implement Risk Responses)

Giao tiếp và ưu tiên hoá giữa các bên liên quan

Lẽ ra PM nên làm gì

Bước 1: Duy trì bản kê thành phần và chủ sở hữu cho mỗi phụ thuộc quan trọng

Bước 2: Chuẩn bị sẵn quy trình ứng phó lỗ hổng khẩn cấp

Bước 3: Đưa sự bền vững của thư viện nguồn mở vào đánh giá chọn công nghệ

Bước 4: Cập nhật truyền thông cho bên liên quan theo nhịp cố định

PM Takeaway (Bài học rút ra)

Nguồn tham khảo

Trắc nghiệm tình huống PMP

Để chuẩn bị cho lỗ hổng tiếp theo trong thư viện nguồn mở, đội của bạn nên đầu tư trước vào đâu?

Tình huống này hữu ích với bạn?

Bình luận (0)