Linus Torvalds, người tạo ra Linux và Git, có định luật riêng của mình trong phát triển phần mềm, và nó diễn ra như thế này: "với đủ nhãn cầu, tất cả các lỗi đều nông." Cụm từ này đặt ngón tay vào chính nguyên tắc của mã nguồn mở: càng nhiều, càng vui - nếu mã dễ dàng có sẵn cho bất kỳ ai và mọi người để sửa lỗi, nó khá an toàn.
Nhưng có phải vậy không? Hay câu nói "tất cả các lỗi đều nông cạn" chỉ đúng với những con bọnông chứkhông phải những con nằm sâu hơn? Nó chỉ ra rằng các lỗi bảo mật trong mã nguồn mở có thể khó tìm thấy hơn chúng ta nghĩ. Emil Wåreus, Trưởng bộ phận R&D tại Debricked, đã tự mình nhìn sâu hơn vào hiệu suất của cộng đồng. Với tư cách là nhà khoa học dữ liệu, tất nhiên, anh ấy đã hỏi dữ liệu: cộng đồng nguồn mở tốt như thế nào trong việc tìm kiếm các lỗ hổng một cách kịp thời?
Sự hồi hộp của cuộc săn lùng (lỗ hổng)
Việc tìm kiếm các lỗ hổng nguồn mở thường được thực hiện bởi những người duy trì dự án nguồn mở, người dùng, kiểm toán viên hoặc các nhà nghiên cứu bảo mật bên ngoài. Nhưng bất chấp những nhà khảo cổ học mã tuyệt vời này giúp bảo vệ thế giới của chúng ta, cộng đồng vẫn phải vật lộn để tìm ra các lỗ hổng bảo mật.
Trung bình, phải mấthơn 800 ngàyđể phát hiện ra lỗ hổng bảo mật trong các dự án mã nguồn mở. Ví dụ, lỗ hổng Log4shell (CVE-2021-44228) khét tiếng chưa được phát hiện trong 2649 ngày.
Phân tích cho thấy 74% lỗi bảo mật thực sự chưa được phát hiện trong ít nhất một năm! Java và Ruby dường như có nhiều thách thức nhất ở đây, vì cộng đồng phải mất hơn 1000 ngày để tìm và tiết lộ các lỗ hổng. Những chiếc mũ [màu trắng] của chúng tôi dành cho cộng đồng PHP / Composer, điều này hơi vượt trội so với những người khác.
Cây kim trong một techstack
Các yếu tố thú vị khác là một số loại điểm yếu khác nhau (CWE) dường như khó tìm và tiết lộ hơn, điều này thực sự mâu thuẫn với định luật của Linus. Các loại điểm yếu CWE-400 (Tiêu thụ tài nguyên không được kiểm soát) và CWE-502 (Deserialization of Untrusted Data) thường không được bản địa hóa thành một hàm duy nhất hoặc có thể xuất hiện dưới dạng logic dự định trong ứng dụng. Nói cách khác, nó không thể được coi là "một lỗi nông".
Có vẻ như cộng đồng nhà phát triển tốt hơn một chút trong việc tìm kiếm CWE-20 (Xác thực đầu vào không phù hợp), trong đó lỗ hổng hầu hết thời gian chỉ là một vài dòng mã trong một chức năng duy nhất.
Giải quyết các lỗ hổng với biện pháp khắc phục mạnh mẽ
Tại sao điều này lại quan trọng? Là người tiêu dùng mã nguồn mở và đó là về mọi công ty trên toàn thế giới, vấn đề lỗ hổng trong mã nguồn mở là một vấn đề quan trọng. Dữ liệu cho chúng ta biết rằng chúng ta không thể hoàn toàn tin tưởng vào Định luật Linus - không phải vì mã nguồn mở kém an toàn hơn các phần mềm khác, mà vìkhông phải tất cả các lỗi đều nông cạn.
May mắn thay, có những công cụ mạnh mẽ để thực hiện phân tích quy mô lớn của rất nhiều dự án mã nguồn mở cùng một lúc. Đã có [tin tặc hiệp sĩ trắng tiết lộ 1000] lỗ hổng cùng một lúc bằng cách sử dụng các phương pháp này. Sẽ là ngây thơ nếu không cho rằng các tổ chức và cá nhân xấu tính cũng làm như vậy. Là một hệ sinh thái đặt nền tảng cho thế giới tập trung vào phần mềm của chúng ta, cộng đồng phải cải thiện khả năng tìm kiếm, tiết lộ và sửa chữa các lỗi bảo mật trong nguồn mở một cách đáng kể.
Năm ngoái, Google đã cam kết 10 tỷ đô la cho một quỹ nguồn mở để giúp bảo mật nguồn mở với vai trò người phụ trách cụ thể để làm việc cùng với các nhà duy trì với các nỗ lực bảo mật cụ thể.
Hơn nữa, Debricked giúp các công ty làm cho các lỗ hổng này có thể hành động bằng cách quét tất cả phần mềm của bạn, mọi chi nhánh, mọi cú đẩy và mọi cam kết, để tìm các lỗ hổng mới (mã nguồn mở).
Debricked thậm chí liên tục quét tất cả các cam kết cũ của bạn cho mọi lỗ hổng mới, để đảm bảo chúng mang lại thông tin cập nhật, chính xác và có thể hành động trên mã nguồn mở bạn sử dụng. Debricked thậm chí còn giúp các nhà phát triển khắc phục các lỗi bảo mật của bạn bằng các yêu cầu kéo tự động sẽ không gây ra địa ngục phụ thuộc; khá gọn gàng!
Sự thật nằm trong dữ liệu
Vì vậy, biết tất cả những điều này, cách tốt nhất để bảo vệ dự án hoặc công ty của bạn chống lại các lỗ hổng mã nguồn mở là gì? Như chúng ta đã thấy trong trường hợp của Log4j và Spring4shell cũng như các con số, chúng ta không bao giờ có thể thực sự tin tưởng rằng cộng đồng sẽ tìm ra và khắc phục mọi rủi ro. Rất có thể có rất nhiều lỗ hổng chưa được phát hiện và chưa được tiết lộ trong mã của bạn ngày hôm nay và bạn không thể làm gì nhiều về nó.
Theo Debricked, cách tốt nhất để giảm thiểu điều này là thực hiện quét lỗ hổng liên tục vào SDLC của bạn. Bằng cách tự động quét ở mỗi lần đẩy mã, kết hợp với cơ sở dữ liệu lỗ hổng hỗ trợ máy học. Điều này đảm bảo bạn được cập nhật trong thời gian thực, bạn sẽ biết về các lỗ hổng mới trước khi bất kỳ ai khác làm.
Ngay sau khi có bản sửa lỗi, bạn có thể tạo Yêu cầu kéo sửa chữa tự động hoặc giải quyết thủ công với sự trợ giúp của Debricked. Hiện tại, Debricked cung cấp biện pháp khắc phục cho JavaScript và Go, với nhiều hỗ trợ ngôn ngữ hơn sẽ sớm ra mắt.