Việc tải xuống Log4j dễ bị tổn thương đang diễn ra cho thấy cuộc khủng hoảng chuỗi cung ứng không phải là hồi chuông cảnh tỉnh đáng lẽ ra nó phải như vậy.
Trở lại tháng 12 năm 2021, những tiêu đề “mạng internet đang cháy” không hề là cường điệu.
Các đội bảo mật chạy đôn chạy đáo, chính phủ ban hành các chỉ thị, và trong một khoảnh khắc, vệ sinh chuỗi cung ứng phần mềm đã trở thành ưu tiên cấp cao nhất.
Tuy nhiên, khi chúng ta bước vào năm 2025, một mức cơ bản cứng đầu về việc tải xuống Log4j dễ bị tổn thương vẫn không chịu biến mất.
TheoSonatype, khoảng 13 phần trăm tổng số lượt tải xuống Log4j trong năm 2025 vẫn là các phiên bản chứa lỗ hổng Log4Shell; bất chấp việc các bản lặp an toàn đã có sẵn trong gần bốn năm.
Đó là khoảng 40 triệu lượt tải xuống nơi các nhóm đã chủ động chấp nhận một rủi ro đã biết.
Vấn đề cốt lõi không còn là về lỗ hổng mã nguồn mở nữa;
mà là một vấn đề về tiêu thụ và quản lý phụ thuộc.
Chúng ta không chỉ thất bại trong việc vá lỗi—chúng ta đang chủ động kéo các thành phần bị lỗi vào các bản dựng mới.
Nội dung chính
Không chỉ là hậu quả của Log4j
Nghiên cứu của Sonatype nêu bật việc tải xuống không chỉ là hậu quả kéo dài từ lỗ hổng Log4j.
Khi nhìn vào hệ sinh thái rộng lớn hơn, cùng một mô thức lặp lại:
khoảng 95 phần trăm các thành phần dễ bị tổn thương được tải xuống trong năm 2025 đã có một phiên bản an toàn hơn sẵn có.
Chỉ 0,5 phần trăm là các trường hợp đặc biệt mà không có bản sửa lỗi nào tồn tại.
Các nhà nghiên cứu gọi đây là “rủi ro ăn mòn” (tức là các lỗ hổng đã có bản sửa nhưng tiếp tục lan truyền vì người dùng không chuyển đổi.) Đó là một khối lượng khổng lồ sự phơi nhiễm không cần thiết.
Bảy thành phần dễ bị tổn thương được tải xuống thường xuyên nhất với các bản sửa lỗi có sẵn đã được tải xuống hơn 3,324 tỷ lần trong năm nay hoặc kể từ khi các bản vá của chúng được phát hành.
Rủi ro không trải đều trên toàn cầu.
Để xem ai thực sự đang vá lỗi, các nhà nghiên cứu đã phân tích mô hình tải xuống ở mười quốc gia có số lượng nhà phát triển lớn nhất.
Các thị trường châu Á hiện đang ở mức cao về tiêu thụ các thành phần dễ bị tổn thương:
Ấn Độ (29%), Trung Quốc (28%) và Nhật Bản (22%) vẫn đang kéo về các phiên bản dễ bị tổn thương Log4Shell với tỷ lệ đáng lo ngại.
Nhưng các nhóm phương Tây không nên quá thoải mái.
Hoa Kỳ (9%), Brazil (8%) và Pháp (8%) có thể hoạt động tốt hơn một cách tương đối, nhưng họ vẫn đang phân phối hàng triệu lượt tải xuống dễ bị tổn thương có thể tránh được.
Thực tế đáng lo ngại?
Không một quốc gia sản xuất phần mềm lớn nào trong số này tiến gần đến mức 0.
Thủ phạm thầm lặng trong chuỗi cung ứng
Trong khi lỗ hổng Log4j nhận được sự chú ý của báo chí, việc tải xuống các thành phần khác có thể nói là nguy hiểm hơn vì chúng thất bại một cách âm thầm.
Chúng là những thư viện “cài đặt và quên lãng” làm nền tảng cho cơ sở hạ tầng doanh nghiệp.
Lấy ví dụcommons-lang.
Phiên bản 2.6 là một phiên bản chính cũ đã được thay thế bởicommons-lang3hơn một thập kỷ trước.
Nó chứa một lỗ hổng đệ quy không kiểm soát nghiêm trọng (CVE-2025-48924).
Tuy nhiên, trong những tháng sau khi bản sửa lỗi được công bố vào tháng 7 năm 2025, các nhà nghiên cứu quan sát thấy hơn 155 triệu lượt tải xuống dễ bị tổn thương (99,88% tổng số cho thành phần đó.)
Vấn đề nằm ở đường nâng cấp.
Chuyển từ 2.6 lên 3.x không phải là một sự thay thế đơn giản;
nó đòi hỏi tái cấu trúc mã mở rộng.
Các hệ thống doanh nghiệp lớn, cũ phụ thuộc vào dòng 2.x và không thể thực tế di chuyển sang API 3.x không tương thích, vì vậy họ tiếp tục tải xuống phiên bản dễ bị tổn thương.
Sau đó làSnappy(0.4).
Thư viện nén này được nhúng rộng rãi trong các hệ thống phân tán lớn như Hadoop, HBase và Spark.
Các nền tảng này ghim các phụ thuộc của chúng để ổn định và hiếm khi cập nhật các thư viện cấp thấp do lo ngại về hiệu suất.
Do đó, 99,58 phần trăm lượt tải xuống vẫn dành cho phiên bản 0.4 dễ bị tổn thương, phơi bày hệ thống trước một lỗi xử lý bộ nhớ (CVE-2024-36124) có thể dẫn đến Từ chối Dịch vụ.
Jdom2kể một câu chuyện tương tự.
Thư viện Java phổ biến này để xử lý XML đã được sửa vào năm 2021 (phiên bản 2.0.6.1) để ngăn chặn các cuộc tấn công mở rộng XML “Billion Laughs”.
Tuy nhiên, phiên bản dễ bị tổn thương chiếm gần 58 phần trăm lượt tải xuống trong năm 2025—hơn 371 triệu lần kéo.
Tại sao lượt tải xuống các phiên bản dễ bị tổn thương của Log4j vẫn cao
Nếu các bản sửa lỗi cho những lỗ hổng chuỗi cung ứng này tồn tại, tại sao chúng ta không sử dụng chúng?
Lý do thường là thói quen và các động cơ không phù hợp tích tụ thành nợ kỹ thuật:
- Điểm mù chuyển tiếp:Các nhà phát triển thường thậm chí không biết họ đang sử dụng các thành phần này.
Nhiều thư viện dễ bị tổn thương đến một cách chuyển tiếp, được kéo vào bởi các framework khác sâu trong cây phụ thuộc.
Chúng không bao giờ xuất hiện trực tiếp trong tệp pom.xml hoặc build.gradle, tạo ra một khoảng trống sở hữu nơi không có đội cụ thể nào cảm thấy có trách nhiệm khắc phục.
- Quán tính và các bản dựng “vĩnh viễn”:Một khi một thư viện được tích hợp và biên dịch, nó có xu hướng ở lại đó.
Các tệp build được sao chép từ dịch vụ này sang dịch vụ khác, và các phiên bản bị ghim lại.
Nếu không có chủ sở hữu rõ ràng cho việc bảo trì phụ thuộc, những lựa chọn “tạm thời” này trở thành các yếu tố cố định vĩnh viễn.
- Công cụ ồn ào:Công cụ bảo mật thường làm mọi thứ tồi tệ hơn.
Nhiều công cụ SCA la hét về mọi CVE với âm lượng như nhau, tạo ra danh sách dài mà không có hướng dẫn hành động như “nâng cấp lên phiên bản X.Y.Z”.
Kết quả là sự mệt mỏi cảnh báo.
Các nhà phát triển coi đầu ra như tiếng ồn nền thay vì một công cụ hỗ trợ định hướng.
Chúng ta không thể ngăn chặn các lỗ hổng trong các phụ thuộc như Log4j xuất hiện, nhưng chúng ta có thể ngăn chặn việc tải xuống những lỗ hổng mà chúng ta đã biết.
Việc dọn dẹp mớ hỗn độn chuỗi cung ứng này đòi hỏi chuyển từ “nhận thức” thụ động sang kiểm soát chủ động.
- Đo lường mớ hỗn độn:Bạn không thể sửa cái bạn không theo dõi.
Các nhóm cần sử dụng công cụ SCA nội bộ của họ để có được mức cơ bản:
bao nhiêu phần trăm lượt tải xuống Log4j trong năm 2025 là dễ bị tổn thương?
Nếu số liệu thống kê nội bộ của bạn trông tệ hơn mức trung bình toàn cầu, việc thu hẹp khoảng cách đó là ưu tiên ngay lập tức.
- Tự động hóa công việc nặng nhọc:Dựa vào các nhà phát triển để kiểm tra thủ công các bản cập nhật thư viện là một chiến lược thất bại.
Tự động hóa nên xử lý các phần dễ dàng;
bot có thể mở các PR nâng cấp cho các phiên bản an toàn của Log4j và các thư viện tương tự.
Việc gộp các bản nâng cấp không phá vỡ này theo một nhịp độ thường xuyên biến chúng thành một phần công việc sprint bình thường thay vì một “tuần vá lỗi” được thúc đẩy bởi hoảng loạn.
- Ngăn chặn sự chảy máu tại nguồn:Đề xuất là không đủ;
bạn cần các rào chắn nơi việc tải xuống các phụ thuộc như Log4j thực sự xảy ra.
Kho lưu trữ artifact nên chặn hoặc cảnh báo chống lại các phiên bản dễ bị tổn thương đã biết khi có bản sửa lỗi.
Các pipeline CI/CD nên làm thất bại các bản dựng giới thiệu việc sử dụng mới các phiên bản bị cấm, ngăn chặn những vi phạm tồi tệ nhất lẻn trở lại.
- Sửa chữa các động cơ:Cuối cùng, hãy ngừng trừng phạt vệ sinh bảo mật.
Các quản lý sản phẩm hiện đang được khen thưởng vì đạt các mốc thời gian lộ trình, không phải vì dành một sprint để nâng cấp các thư viện ghi log.
Chúng ta cần định nghĩa lại hiệu suất “tốt”.
Thay vì đếm số CVE thô đã đóng, hãy đo lường việc giảm “rủi ro không cần thiết” (tức là tỷ lệ phần trăm lượt tải xuống dễ bị tổn thương khi một phiên bản đã sửa tồn tại.)
Kỷ niệm 5 năm lỗ hổng Log4j đang đến gần.
Đến thời điểm đó, các nhà phát triển và tổ chức có thể trở thành một con số thống kê khác từ các lỗ hổng chuỗi cung ứng, hoặc họ có thể quyết định rằng rủi ro không cần thiết không còn là tiếng ồn nền có thể chấp nhận được nữa.
Xem thêm:Hướng dẫn Sonatype đưa DevSecOps vào lập trình AI
Muốn tìm hiểu thêm về an ninh mạng từ các chuyên gia hàng đầu?Hãy xemCyber Security & Cloud Expodiễn ra tại Amsterdam, California và London.
Sự kiện toàn diện này là một phần củaTechExvà được tổ chức cùng với các sự kiện công nghệ hàng đầu khác bao gồmAI & Big Data Expo.
Nhấpvào đâyđể biết thêm thông tin.
Developer được cung cấp bởiTechForge Media.
Khám phá các sự kiện và hội thảo trực tuyến về công nghệ doanh nghiệp sắp tớitại đây.
