Báo cáo OSSRA 2024: Nỗi lo ngại gia tăng về quản lý mã nguồn mở
Trong phiên bản thứ chín của Synopsys, báo cáo Open Source Security and Risk Analysis (OSSRA) năm 2024. Mang đến cái nhìn sâu rộng về tình hình hiện tại của an ninh mã nguồn mở, tuân thủ, cấp phép. Và các rủi ro về chất lượng mã nguồn trong phần mềm thương mại.
Báo cáo này sử dụng dữ liệu từ việc phân tích các thông tin ẩn danh từ 1.067 mã nguồn mở. Trong 17 ngành công nghiệp trong năm 2023. Do đội ngũ dịch vụ kiểm tra Synopsys Black Duck® Audit Services thực hiện. Với mục tiêu chính là xác định các rủi ro phần mềm trong giao dịch sáp nhập và mua bán (merge & acquisition – M&A). Các ngành công nghiệp được đại diện trong báo cáo. Bao gồm ô tô, dữ liệu lớn, an ninh mạng, phần mềm doanh nghiệp, dịch vụ tài chính, chăm sóc sức khỏe, Internet vạn vật, sản xuất và ứng dụng di động.
Mã nguồn mở tồn tại đồng thời khắp mọi nơi, ở mọi lúc
Báo cáo OSSRA đề cập đến các thành phần và thư viện mã nguồn mở. Tạo nên cốt lõi của gần như mọi ứng dụng trong mọi ngành công nghiệp. 96% của tổng số mã nguồn (bao gồm mã và thư viện liên quan tạo nên một ứng dụng hoặc dịch vụ) chứa mã nguồn mở. 77% của tất cả mã trong các mã nguồn xuất phát từ mã nguồn mở. Mọi mã nguồn trong các ngành công nghiệp đều chứa mã nguồn mở (99% – 100%).
Với những lợi ích như thời gian đưa sản phẩm ra thị trường nhanh, tiết kiệm chi phí và phát triển ứng dụng hiệu quả. Không có gì ngạc nhiên khi các công ty phụ thuộc vào mã nguồn mở. Như một phần của quy trình phát triển phần mềm. Tuy nhiên, số lượng lớn các thành phần mã nguồn mở riêng lẻ trong một ứng dụng cụ thể. Được phát hiện bởi các nhóm kiểm tra và đánh giá cho thấy tồn tại nhiều thách thức trong việc theo dõi chúng.
Trung bình mỗi ứng dụng có hơn 500 thành phần mã nguồn mở
Báo cáo OSSRA chỉ ra rằng, số lượng trung bình các thành phần mã nguồn mở. Trong một ứng dụng trong năm nay. Là 526 – một con số cho thấy thực tế về tầm quan trọng, cần thiết. Cho việc kiểm thử bảo mật tự động. Việc kiểm tra thủ công có thể khả thi đối với một số lượng nhỏ thành phần. Nhưng nó trở nên gần như không thể khi thực hiện trên quy mô lớn.
Điều này đòi hỏi tổ chức cần một giải pháp tự động. Như phân tích thành phần phần mềm (SCA). Khác với kiểm tra thủ công. Các kiểm tra bảo mật tự động có thể được thực hiện nhanh chóng và đều đặn. Cho phép các nhà phát triển sớm xác định các vấn đề trong quá trình phát triển. Mà không ảnh hưởng đến kế hoạch ra mắt sản phẩm hoặc năng suất.
Lỗ hổng và vấn đề tuân thủ giấy phép. Là những mối đe doạ tiềm ẩn phổ biến trong mã nguồn mở. Hơn một nửa (53%) mã nguồn có vi phạm bản quyền. 84% mã nguồn có đánh giá rủi ro chứa ít nhất một lỗi bảo mật đã biết. Và 74% mã nguồn có nguy cơ cao bị tấn công. Tăng đáng kể so với báo cáo OSSRA của năm ngoái (48%).
Một lý do khác có thể xem xét là do suy thoái kinh tế và cắt giảm nhân sự. Dẫn đến thiếu nguồn lực để vá lỗi. Hơn nữa, gần như tất cả (91%) mã nguồn đang sử dụng các phiên bản chứa thành phần lỗi thời. Kết luận được suy ra là: phần lớn người dùng không cập nhật các thành phần mà họ đang sử dụng, dẫn đến những rủi ro cao hơn.
Đọc thêm: Khám phá sâu báo cáo OSSRA năm 2023: Các lỗ hổng bảo mật rủi ro cao
Một phần ba các mã nguồn đang sử dụng phiên bản jQuery có lỗ hổng
Dữ liệu từ OSSRA cho thấy rõ ràng rằng các nhóm phát triển cần cải thiện quản lý mã nguồn mở. Đặc biệt là cập nhật các thành phần mã nguồn mở lên phiên bản mới nhất. Hậu quả của việc sử dụng các phiên bản cũ/có lỗ hổng có thể rất nghiêm trọng.
Ví dụ, trong danh sách 10 lỗ hổng hàng đầu của OSSRA năm 2024. Lỗ hổng cross-site scripting đứng thứ 2 liên quan đến phiên bản jQuery từ 1.2 đến 3.5.0. Lỗ hổng này đã được vá trong phiên bản jQuery 3.5.0. Nhưng 1/3 các cơ sở mã được quét lỗ hổng bảo mật vẫn đang sử dụng phiên bản jQuery dễ bị tấn công. Kẻ tấn công có thể khai thác lỗ hổng này. Để đưa mã độc vào hệ thống, đánh cắp dữ liệu nhạy cảm như mật khẩu hoặc thông tin thẻ tín dụng.
Báo cáo CVE-2018-9206 về phương thức tấn công lỗ hổng của công cụ jQuery File Upload (Nguồn: Tạp chí ATTT)
Bản chất của jQuery là an toàn. Trên thực tế, đây là một thư viện mã nguồn mở được bảo trì tốt. Với số lượng người dùng, nhà phát triển và người bảo trì đông đảo. Tuy nhiên, theo dữ liệu OSSRA, jQuery là thành phần có nhiều lỗ hổng nhất. Mặc dù tất cả các lỗ hổng jQuery được liệt kê trong báo cáo đều có bản vá sẵn. Điều quan trọng đối với người dùng jQuery – và tất cả người dùng mã nguồn mở – là nhận thức về các rủi ro bảo mật tiềm ẩn liên quan đến các phiên bản phần mềm cũ. Và thực hiện các biện pháp để giảm thiểu những rủi ro đó.
Hầu hết những người bảo trì (những người đóng góp chính cho một dự án mã nguồn mở) đều chú ý cập nhật các dự án họ tham gia. Người sử dụng mã nguồn mở cũng nên cẩn thận như vậy. Cần theo dõi các phiên bản họ đang sử dụng. Thiết lập chu kỳ cập nhật thường xuyên và thực hành bảo trì phần mềm – ưu tiên các dự án có số lượng người tham gia lớn. Được bảo trì tốt và có nguồn gốc rõ ràng.
Hiểu rõ nội dung trong mã nguồn của bạn
Việc nắm rõ các thành phần mã nguồn mở trong code của bạn là vô cùng quan trọng. Nếu tổ chức bạn chưa thực hiện điều này. Bước đầu tiên là tạo và duy trì một Software Bill of Materials (SBOM). Để liệt kê chi tiết các thành phần có trong code của bạn. Bao gồm thông tin về phiên bản, giấy phép và nguồn gốc.
Sau khi có bản kiểm kê này, hãy thường xuyên cập nhật các thành phần mã nguồn mở. Đặc biệt là các thành phần phổ biến thường bị kẻ tấn công nhắm đến. Việc cập nhật mã nguồn mở cần được xem xét ưu tiên ngang với việc code do tổ chức bạn phát triển. Thiết lập lịch nâng cấp thường xuyên. Đặc biệt nếu bạn đang sử dụng các thư viện mã nguồn mở. Từ các dự án nổi tiếng có hoạt động bảo trì thường xuyên.
Hãy luôn cập nhật thông tin, tìm kiếm các nguồn tin tức hoặc thông báo được phát hành đều đặn cung cấp hướng dẫn cụ thể và chi tiết. Về các vấn đề ảnh hưởng đến các thành phần mã nguồn mở trong SBOM của bạn. Sử dụng công cụ SCA tự động thay vì quản lý mã nguồn mở thông qua bảng tính. Cho phép các nhà phát triển tập trung năng lượng vào việc viết code.
👉 Tải NGAY bản báo cáo OSSRA đầy đủ tại đây.
