Việc phát hiện gần đây về một cửa hậu trong tiện ích nén dữ liệu Xperia Utils — hiện diện trong hầu hết các bản phân phối Linux chính — là một lời nhắc nhở rõ ràng rằng các tổ chức sử dụng các thành phần nguồn mở cuối cùng phải chịu trách nhiệm bảo mật phần mềm.

Hz Utils, giống như hàng nghìn dự án nguồn mở khác, được điều hành bởi tình nguyện viên và trong trường hợp của nó, có một người bảo trì duy nhất quản lý nó. Những dự án như vậy thường có ít hoặc không có nguồn lực để xử lý các vấn đề bảo mật, nghĩa là các tổ chức phải tự chịu rủi ro khi sử dụng phần mềm. Các chuyên gia bảo mật cho biết điều đó có nghĩa là các nhóm phát triển và bảo mật phải thực hiện các biện pháp quản lý rủi ro nguồn mở giống như cách họ thực hiện với mã được phát triển nội bộ.

Jamie Scott, giám đốc sản phẩm sáng lập tại Endor Labs cho biết: “Mặc dù tổ chức khó có thể ngăn chặn [tất cả] một cách hiệu quả các rủi ro trong chuỗi cung ứng, nhưng các tổ chức hoàn toàn có thể tập trung vào chiến lược nhằm giảm khả năng xảy ra một cuộc tấn công chuỗi cung ứng thành công”.

Nguồn mở không giống như gia công phần mềm: “Những người bảo trì phần mềm nguồn mở là tình nguyện viên. Ở cấp độ ngành, chúng ta cần đối xử với họ như vậy. Chúng tôi sở hữu phần mềm của mình; chúng tôi chịu trách nhiệm về phần mềm mà chúng tôi sử dụng lại.”

Có ý định tốt, nguồn lực hạn chế

Những lo ngại về bảo mật phần mềm nguồn mở không có nghĩa là mới. Nhưng nó thường đòi hỏi những khám phá như Lỗ hổng Log4Shell và cửa sau trong XX Utils để thực sự hiểu rõ mức độ dễ bị tổn thương của các tổ chức đối với các thành phần trong mã của họ. Và thông thường, mã này đến từ các dự án nguồn mở có chủ đích tốt nhưng lại có nguồn lực hạn chế và được bảo trì ở mức tối thiểu.

Ví dụ: XX Utils về cơ bản là dự án của một người. Một cá nhân khác đã thành công lẻn backdoor vào tiện ích trong khoảng thời gian gần ba năm, bằng cách dần dần có được đủ sự tin tưởng từ người duy trì dự án. Nếu một nhà phát triển của Microsoft không tình cờ phát hiện ra nó vào cuối tháng 3 khi điều tra hành vi kỳ lạ liên quan đến cài đặt Debian, thì cửa sau có thể đã xuất hiện trên hàng triệu thiết bị trên toàn cầu - bao gồm cả những thiết bị thuộc các tập đoàn lớn và cơ quan chính phủ. Hóa ra, cửa hậu này có tác động tối thiểu vì nó ảnh hưởng đến các phiên bản của XX Utils vốn chỉ có trong phiên bản beta và không ổn định của Debian, Fedora, Kali, SUSE mở và Arch Linux.

Sự xâm phạm mã nguồn mở tiếp theo như vậy có thể còn tồi tệ hơn nhiều. Donald Fischer, đồng sáng lập và Giám đốc điều hành của Tidelift cho biết: “Điều đáng sợ nhất đối với các tổ chức doanh nghiệp là các ứng dụng của họ được xây dựng dựa trên các dự án phần mềm nguồn mở giống như XX Utils”. “XZ Utils là một gói gồm hàng chục nghìn ứng dụng được các tổ chức doanh nghiệp điển hình sử dụng hàng ngày,” ông nói.

Ông lưu ý rằng hầu hết các tổ chức này đều thiếu tầm nhìn đầy đủ về tính bảo mật và khả năng phục hồi của phần này trong chuỗi cung ứng phần mềm của họ để có thể đánh giá rủi ro.

Mới đây Trường Kinh doanh Harvard nghiên cứu ước tính giá trị phía cầu của phần mềm nguồn mở là 8.8 nghìn tỷ USD đáng kinh ngạc. Fischer cho biết, những người bảo trì là cốt lõi của hệ sinh thái này và nhiều người trong số họ đang bay một mình. Một cuộc khảo sát do Tidelift thực hiện năm ngoái cho thấy 44% người bảo trì dự án nguồn mở tự mô tả họ là người duy nhất bảo trì dự án của họ. XNUMX% tự nhận mình là những người có sở thích không được trả lương, và tỷ lệ tương tự cho biết họ đã bỏ việc hoặc đang cân nhắc việc từ bỏ vai trò là người duy trì dự án. Fischer cho biết, nhiều người bảo trì mô tả những nỗ lực của họ là công việc căng thẳng, cô đơn và không mang lại lợi ích về mặt tài chính.

Fischer cho biết: “Vụ hack Xperia utils giúp giải quyết rõ ràng những rủi ro khi đầu tư dưới mức vào sức khỏe và khả năng phục hồi của chuỗi cung ứng phần mềm nguồn mở [mà] các tổ chức doanh nghiệp dựa vào”. “Các tổ chức doanh nghiệp cần nhận ra rằng phần lớn các gói nguồn mở đáng tin cậy nhất được duy trì bởi các tình nguyện viên tự mô tả mình là những người có sở thích không được trả lương. Những người bảo trì này không phải là nhà cung cấp cho doanh nghiệp nhưng được kỳ vọng sẽ hoạt động và giao hàng giống như họ.”

Nguy hiểm: Phụ thuộc bắc cầu

A nghiên cứu mà Endor thực hiện vào năm 2022 đã phát hiện ra rằng 95% lỗ hổng nguồn mở xuất hiện trong cái gọi là phần phụ thuộc bắc cầu hoặc các gói hoặc thư viện nguồn mở thứ cấp mà gói nguồn mở chính có thể phụ thuộc vào. Thông thường, đây là những gói mà các nhà phát triển không tự mình trực tiếp chọn mà được gói nguồn mở tự động sử dụng trong dự án phát triển của họ.

Scott nói: “Ví dụ: khi bạn tin cậy một gói Maven, thì trung bình sẽ có thêm 14 phần phụ thuộc mà bạn hoàn toàn tin tưởng”. “Con số này thậm chí còn lớn hơn trong một số hệ sinh thái phần mềm nhất định như NPM, nơi bạn trung bình nhập 77 thành phần phần mềm khác cho mỗi thành phần mà bạn tin tưởng.”

Ông nói, một cách để bắt đầu giảm thiểu rủi ro nguồn mở là chú ý đến những sự phụ thuộc này và chọn lọc những dự án bạn chọn.

Các tổ chức nên kiểm tra các phần phụ thuộc, đặc biệt là các gói nhỏ hơn, dùng một lần, được quản lý bởi các nhóm một và hai người, cho biết thêm Dimitri Stiliadis, CTO và đồng sáng lập của Endor. Họ nên xác định xem liệu các phần phụ thuộc trong môi trường của họ có các biện pháp kiểm soát bảo mật thích hợp hay không hoặc liệu một cá nhân có cam kết tất cả mã hay không; liệu họ có các tệp nhị phân trong kho của mình mà không ai biết hay không; hoặc thậm chí nếu ai đó đang tích cực duy trì dự án, Stiliadis nói.

“Tập trung nỗ lực vào việc cải thiện hiệu quả phản hồi của bạn - các biện pháp kiểm soát cơ bản như duy trì kho phần mềm hoàn thiện vẫn là một trong những chương trình có giá trị cao nhất mà bạn có thể áp dụng để nhanh chóng xác định, xác định phạm vi và ứng phó với rủi ro phần mềm khi chúng được xác định,” Scott lời khuyên.

Các công cụ phân tích thành phần phần mềm, trình quét lỗ hổng, hệ thống EDR/XDR và ​​SBOM cũng có thể giúp các tổ chức nhanh chóng xác định các thành phần nguồn mở dễ bị tổn thương và bị xâm phạm.

Thừa nhận mối đe dọa

Fischer của Tidelift cho biết: “Việc giảm thiểu rủi ro bắt đầu bằng sự hiểu biết và thừa nhận được chia sẻ trong C-Suite và thậm chí ở cấp độ hội đồng quản trị rằng khoảng 70% thành phần của sản phẩm phần mềm trung bình là phần mềm nguồn mở trước đây được tạo ra bởi hầu hết những người đóng góp không được trả thù lao”.  

Các quy định và hướng dẫn mới trong ngành dịch vụ tài chính, FDA và NIST sẽ định hình cách phát triển phần mềm trong những năm tới và các tổ chức cần chuẩn bị cho chúng ngay từ bây giờ. Ông nói: “Những người chiến thắng ở đây sẽ nhanh chóng thích ứng từ chiến lược phản ứng sang chiến lược chủ động để quản lý rủi ro liên quan đến nguồn mở”.

Fischer khuyến nghị các tổ chức nên nhờ đội ngũ kỹ thuật và bảo mật của họ xác định cách các thành phần nguồn mở mới đi vào môi trường của họ. Họ cũng nên xác định vai trò giám sát các thành phần này và chủ động loại bỏ những thành phần không phù hợp với khẩu vị rủi ro của công ty. “Phản ứng với các vấn đề ở giai đoạn cuối đã trở thành một cách không hiệu quả để đối phó với quy mô rủi ro đối với doanh nghiệp trong vài năm qua, và Chính phủ Mỹ đang phát tín hiệu thời đại đó sắp kết thúc,” ông nói.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security