Lỗ hổng bảo mật trong mã
Phần mềm hệ điều hành, phần mềm ứng dụng hoặc phần lõi trong một hệ thống nhúng là các thành phần cơ bản của bất kỳ cơ sở hạ tầng kỹ thuật số nào. Tuy nhiên, việc tăng tốc độ và áp lực về thời hạn trong các dự án số hóa thường dẫn đến việc bỏ qua các khía cạnh bảo mật thông tin cấp thiết. Các yêu cầu phát triển đối với phần mềm thường tập trung vào chức năng và nhấn mạnh các khía cạnh mang tính xây dựng, do đó, quan điểm tiêu cực về các lỗ hổng bảo mật tiềm ẩn hầu như hoàn toàn trái ngược với các mục tiêu phát triển thực tế: nhiều lập trình viên đơn giản là thiếu quan điểm có cấu trúc và sắc bén về an ninh mạng.
Trong những điều kiện này, các nhóm phát triển gặp khó khăn trong việc xem xét liên tục và đảm bảo nhất quán mã hóa phần mềm của họ, bằng chứng là có nhiều lỗ hổng mà Tập đoàn MITER phi lợi nhuận xuất bản hàng năm trong danh sách CVE (Common Vulnerabilities and Exposures - Lỗ hổng và Phơi nhiễm Thông thường). Các bản vá bảo mật thường xuyên của các nhà sản xuất phần mềm nổi tiếng thậm chí là một chỉ số cho thấy nhiệm vụ của Sisyphean là đóng các lỗi liên quan đến bảo mật, chứ đừng nói đến việc xác định chúng trước khi chúng được tung ra thị trường.
Mã nguồn mở - một trường hợp đặc biệt
Khi mã hóa phần mềm tự phát triển, các lập trình viên thích sử dụng các thư viện và mô-đun mã nguồn mở. Những lợi thế thực tế là rõ ràng: Nếu bạn không phải phát minh lại bánh xe nhiều lần, bạn sẽ được hưởng lợi từ sự thúc đẩy công nghệ này, phát triển nhanh chóng, chi phí phát triển thấp hơn, minh bạch hơn thông qua mã nguồn mở và khả năng tương tác cao hơn thông qua các tiêu chuẩn và giao diện mở .
Người ta cũng thường nói rằng mã từ nguồn mở mang lại mức độ bảo mật cao vì mã đã được xác thực bởi nhiều người dùng và trí thông minh phong phú của cộng đồng mã nguồn mở cho phép sửa lỗi nhanh chóng và hiệu quả.
Trong thực tế, niềm tin này bây giờ phải được đánh giá theo cách khác biệt và quan trọng. Ví dụ nghiêm trọng nhất là lỗ hổng bảo mật zero-day Log4Shell trong thư viện ghi nhật ký được sử dụng rộng rãi Log4J cho các ứng dụng Java, được phát hiện vào tháng 11 năm 2021. Bạn có thể đã nghe nói về mức báo động đỏ do Văn phòng Bảo mật Thông tin Liên bang Đức (BSI) đưa ra cho Log4Shell. Thư viện Log4J, được phân phối dưới dạng gần như tiêu chuẩn hoạt động đáng tin cậy thông qua Quỹ Apache, đã tự thiết lập trong nhiều hệ thống kể từ năm 2013 - bao gồm các dịch vụ web nổi tiếng như Amazon AWS.
Sự phức tạp của các thư viện được phát triển và cũng được duy trì tốt này hoàn toàn cung cấp các chức năng mạnh mẽ mà nhà phát triển nhập khẩu thường không biết trong quá trình phát triển mới kết hợp của chính mình, nhưng có thể bị kẻ tấn công khai thác.
Một yếu tố không an toàn khác của các thành phần nguồn mở được gọi là các cuộc tấn công chuỗi cung ứng, tức là các lỗ hổng tích hợp có chủ đích của các tác nhân độc hại, những người đóng vai trò là một phần của cộng đồng nguồn mở và hỗ trợ phát triển mã. Một lỗ hổng như vậy là một cách cực kỳ hiệu quả để tin tặc tấn công một số lượng lớn các tổ chức người dùng hạ nguồn. Do đó, không có gì ngạc nhiên khi vectơ tấn công này đang phát triển nhanh chóng: một nghiên cứu của Sonatype đã chẩn đoán mức tăng 650% khi so sánh năm 2020 và 2021.
