Việc duy trì vô số thành phần nguồn mở có thể khó khăn. Đây là cách các nhóm có thể bắt đầu giải quyết vấn đề bảo mật nguồn mở và tiếp tục đổi mới.

Mã nguồn mở là một phần của khoảng 99% cơ sở mã nguồn thương mại, theo nghiên cứu từ Synopsys. Hầu hết các nhà phát triển thích sử dụng phần mềm nguồn mở vì tính linh hoạt và tốc độ đổi mới của nó trong cộng đồng nguồn mở. Tuy nhiên, nghiên cứu tương tự cho thấy 75% cơ sở mã đã được kiểm tra có chứa các thành phần nguồn mở có ít nhất một lỗ hổng đã biết. Thủ phạm chính: Việc sử dụng phần mềm lỗi thời không còn được cộng đồng nguồn mở duy trì. 

Nhiều công ty phần mềm độc quyền vẫn cố gắng gieo rắc nỗi sợ hãi xung quanh những rủi ro nguồn mở ngày càng gia tăng, khi, nếu được quản lý đúng cách, thì điều ngược lại sẽ xảy ra. MỘT Nghiên cứu của Đại học Purdue cho thấy cộng đồng nguồn mở chú ý nhiều hơn đến các lỗ hổng và rủi ro bảo mật, đồng thời phát hành các bản vá nhanh hơn phần mềm độc quyền. Tiền thưởng phát hiện lỗi cũng đang trở nên phổ biến hơn trong nguồn mở; ví dụ, Ủy ban Châu Âu đề nghị tài trợ vào năm 2019 cho 14 chương trình tiền thưởng lỗi mã nguồn mở.

Mặc dù vậy, trách nhiệm của người dùng thường là cài đặt các bản vá bảo mật cập nhật nhất do cộng đồng nguồn mở cung cấp. Điều này có thể làm cho an ninh trở thành một thách thức. Nhiều nhóm kỹ thuật được dàn trải quá mỏng để có thể nghĩ đến việc duy trì vô số thành phần nguồn mở trong kho công nghệ của họ. Vậy làm thế nào để các tổ chức giải quyết các vấn đề bảo mật nguồn mở và tiếp tục đổi mới cùng một lúc?  

Dưới đây là ba lời khuyên để bắt đầu.

Nắm bắt sự phát triển phần mềm an toàn
Trong nhiều tổ chức, các nhóm bảo mật và kỹ thuật chia sẻ trách nhiệm về bảo mật. Điều đó có thể làm cho vấn đề ai “sở hữu” bảo mật nguồn mở trở nên mờ mịt. Các đội tiên tiến hơn nắm lấy một vòng đời phát triển phần mềm an toàn (SSDLC), nơi bảo mật trở thành một phần không thể thiếu trong mọi giai đoạn trong quá trình phát triển. Cách tiếp cận này đòi hỏi các kỹ sư phải được đào tạo về các phương pháp hay nhất về mã hóa an toàn. Đội đỏ kiểm tra áp suất mà các kỹ sư hệ thống xây dựng để đảm bảo rằng không có gì lọt qua kẽ hở.

Bất kể ai tìm thấy lỗ hổng - cho dù đó là kỹ sư phần mềm, người kiểm tra nội bộ, hacker mũ trắng hay ai khác - thì điều bắt buộc về mặt đạo đức là phải sửa những lỗi này một cách nhanh chóng và chia sẻ công khai các bản sửa lỗi với mọi người trong cộng đồng nguồn mở. Càng để mắt tới phần mềm nguồn mở thì mọi người càng được bảo vệ tốt hơn trước các mối đe dọa bảo mật tiềm ẩn.

Dành thời gian để quản lý rủi ro 
Nghiên cứu bảo mật nguồn mở tương tự được trích dẫn ở trên cho thấy rằng 91% cơ sở mã có chứa các thành phần đã lỗi thời hơn bốn năm hoặc không có hoạt động phát triển nào trong hai năm qua. Hầu hết các cộng đồng nguồn mở tích cực đều cập nhật phần mềm và thường xuyên phát hành các bản vá cho các lỗ hổng đã biết. Khi các dự án nguồn mở lớn hoặc phần phụ thuộc của chúng (mã bên ngoài mà dự án phụ thuộc vào) trở nên lỗi thời, cộng đồng sẽ ngừng sử dụng phần mềm (còn được gọi là hết vòng đời) và cung cấp phiên bản mới.

Tuy nhiên, nếu không có ai cập nhật nội bộ phần mềm thì đó chính là lúc phát sinh vấn đề. Vụ vi phạm Equifax khét tiếng hiện nay là một ví dụ điển hình. Năm 2017, Equifax xác nhận tin tặc đã khai thác lỗ hổng trong Apache Struts mã nguồn mở. Một bản vá cho lỗ hổng này đã được phát hành vào tháng XNUMX và tin tặc đã khai thác lỗi này để đột nhập vào máy chủ Equifax hai tháng sau đó. 

Để tránh những loại vấn đề này, các tổ chức nên dành 20% thời gian kỹ thuật để quản lý rủi ro nguồn mở. Điều này bao gồm việc quản lý lỗ hổng và bản vá nhất quán, cũng như luôn cập nhật thời hạn cuối vòng đời. Theo thời gian và thực hành, 20% này có thể giảm đi, tùy thuộc vào đánh giá rủi ro nội bộ.

Nắm bắt tự động hóa bất cứ nơi nào có thể
Nguồn mở được quản lý có thể giúp các nhóm có nguồn lực hạn chế luôn được bảo mật nguồn mở. Hầu hết các nhà cung cấp phần mềm nguồn mở thương mại đều cung cấp dịch vụ tự động hóa và/hoặc dịch vụ có thể giúp khách hàng duy trì các thành phần nguồn mở của họ, giảm bớt áp lực cho các nhóm nội bộ trong việc tự quản lý mọi thứ.

Nhiều kho lưu trữ mã cũng cung cấp các cách tự động kiểm tra bảo mật cho các thành phần nguồn mở. Ví dụ, Biểu đồ phụ thuộc của GitHub cho phép các nhà phát triển xem tất cả các gói mà phần mềm của họ phụ thuộc vào, cũng như mọi lỗ hổng được phát hiện trong các gói phụ thuộc này. Gần đây, các nhà phát triển có thể tự động hóa các bản vá này.

Một số cộng đồng nguồn mở hàng đầu đang tự mình chịu trách nhiệm về bảo mật bằng cách cung cấp các bản cập nhật bảo mật tự động. Ví dụ: cập nhật tự động là một sáng kiến ​​lớn mới được công bố gần đây bởi cộng đồng Drupal.

Tóm lại, bảo mật nguồn mở phát triển mạnh trong môi trường minh bạch triệt để. Các nhóm không nên đợi SecDevOps trở thành xu hướng chủ đạo; thay vào đó, họ nên sử dụng SSDLC và tích cực làm việc với các nhóm đỏ để xác định và khắc phục các lỗ hổng. Nếu các công ty minh bạch về các lỗi họ tìm thấy và sửa chúng một cách công khai thì toàn bộ cộng đồng sẽ thắng.

Nội dung liên quan:

Với tư cách là giám đốc an ninh thông tin và phó chủ tịch an ninh, Robert Cựu lãnh đạo các hoạt động quản trị, rủi ro, tuân thủ và bảo mật tại Acquia. Robert gần đây nhất đã giữ các vai trò tại Pegasystems với tư cách là giám đốc cấp cao về tuân thủ và tại HP/HPE/Micro Focus với tư cách là cấp cao… Xem Full Bio

Đề nghị đọc:

Thông tin chi tiết

Nguồn: https://www.darkreading.com/application-security/3-tips-for-securing-open-source-software/a/d-id/1338495?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple