Google đề xuất thiết lập các quy tắc mới để cải thiện bảo mật nguồn mở

Tính bảo mật của phần mềm nguồn mở đã thu hút sự quan tâm của ngành, nhưng các giải pháp đòi hỏi sự đồng thuận về các thách thức và hợp tác trong việc thực hiện.

Vấn đề rất phức tạp và có nhiều khía cạnh cần giải quyết, từ chuỗi cung ứng, quản lý sự phụ thuộc, danh tính, trong số những thứ khác. Để làm được điều này, Google gần đây đã phát hành một khuôn khổ ("Biết, Ngăn chặn, Khắc phục") giải thích cách ngành công nghiệp có thể suy nghĩ về các lỗ hổng trong mã nguồn mở và các lĩnh vực cụ thể cần được giải quyết trước tiên.

Google giải thích lý do của nó:

“Do những sự kiện gần đây, thế giới phần mềm đã hiểu sâu hơn về nguy cơ thực sự của các cuộc tấn công chuỗi cung ứng. Phần mềm nguồn mở nên ít rủi ro hơn từ góc độ bảo mật, vì tất cả mã và phần phụ thuộc đều mở và có sẵn để kiểm tra và xác minh. Và trong khi điều này nói chung là đúng, người ta cho rằng mọi người đang thực sự làm công việc thanh tra này. Với rất nhiều phụ thuộc, không thể giám sát tất cả chúng và nhiều gói mã nguồn mở không được duy trì tốt.

“Thông thường một chương trình phụ thuộc trực tiếp hoặc gián tiếp vào hàng nghìn gói và thư viện. Ví dụ, Kubernetes hiện phụ thuộc vào khoảng 1000 gói. Mã nguồn mở có thể sử dụng các phần mềm phụ thuộc hơn là phần mềm độc quyền và đến từ nhiều nhà cung cấp hơn; số lượng các thực thể độc lập có thể được tin cậy có thể rất lớn. Điều này khiến cho việc hiểu cách sử dụng mã nguồn mở trong các sản phẩm là vô cùng khó khăn và những lỗ hổng nào có thể liên quan. Cũng không có gì đảm bảo rằng những gì được xây dựng sẽ khớp với mã nguồn.

Trong khuôn khổ do Google đề xuất, nên chia khó khăn này thành ba lĩnh vực vấn đề chủ yếu độc lập, mỗi lĩnh vực có các mục tiêu cụ thể:

Biết các lỗ hổng trong phần mềm của bạn

Biết được các lỗ hổng phần mềm của bạn khó hơn bạn có thể mong đợi vì nhiều lý do. Vâng ok tồn tại các cơ chế để báo cáo các lỗ hổng bảo mật, không rõ liệu chúng có thực sự ảnh hưởng đến các phiên bản cụ thể của phần mềm bạn đang sử dụng hay không:

• Mục tiêu: Dữ liệu về lỗ hổng bảo mật chính xác: Đầu tiên, điều quan trọng là phải nắm bắt chính xác siêu dữ liệu về lỗ hổng bảo mật từ tất cả các nguồn dữ liệu có sẵn. Ví dụ: việc biết phiên bản nào đã giới thiệu lỗ hổng sẽ giúp xác định xem phần mềm có bị ảnh hưởng hay không và biết khi nào nó đã được vá giúp đưa ra các bản sửa lỗi chính xác và kịp thời (và một cửa sổ hẹp để khai thác tiềm năng). Tốt nhất, quy trình phân loại này nên được tự động hóa.
• Thứ hai, hầu hết các lỗ hổng nằm trong phần phụ thuộc của bạn, chứ không phải trong mã mà bạn viết hoặc kiểm soát trực tiếp. Vì vậy, ngay cả khi mã của bạn không thay đổi, bối cảnh của các lỗ hổng ảnh hưởng đến phần mềm của bạn có thể liên tục thay đổi - một số được sửa và một số được thêm vào.
• Mục đích: Lược đồ tiêu chuẩn cho cơ sở dữ liệu lỗ hổng Cơ sở hạ tầng và các tiêu chuẩn ngành được yêu cầu để theo dõi và duy trì các lỗ hổng nguồn mở, hiểu hậu quả của chúng và quản lý các biện pháp giảm nhẹ của chúng. Một sơ đồ lỗ hổng tiêu chuẩn sẽ cho phép các công cụ phổ biến chạy trên nhiều cơ sở dữ liệu về lỗ hổng bảo mật và đơn giản hóa nhiệm vụ theo dõi, đặc biệt là khi các lỗ hổng vượt qua nhiều ngôn ngữ hoặc hệ thống con.

Tránh thêm các lỗ hổng bảo mật mới

Sẽ là lý tưởng nhất để tránh tạo ra các lỗ hổng Và trong khi các công cụ kiểm tra và phân tích có thể giúp ích, việc phòng ngừa sẽ luôn là một chủ đề khó khăn.

Đây, Google đề xuất tập trung vào hai khía cạnh cụ thể:

• Hiểu những rủi ro khi quyết định một người phụ thuộc mới
• Cải thiện các quy trình phát triển phần mềm quan trọng

Sửa chữa hoặc loại bỏ các lỗ hổng

Google thừa nhận rằng vấn đề sửa chữa chung nằm ngoài tầm quan trọng của nó, nhưng nhà xuất bản tin rằng còn nhiều điều mà các tác nhân có thể làm để giải quyết vấn đề cụ thể để quản lý các lỗ hổng trong các phần phụ thuộc.

Nó cũng đề cập đến: 

“Ngày nay, có rất ít sự trợ giúp về mặt này, nhưng khi chúng tôi cải thiện độ chính xác, thì việc đầu tư vào các quy trình và công cụ mới sẽ được trả tiền.

“Tất nhiên, một lựa chọn là vá lỗ hổng bảo mật trực tiếp. Nếu bạn có thể thực hiện việc này theo cách tương thích ngược, giải pháp có sẵn cho tất cả mọi người. Nhưng thách thức là bạn không có kinh nghiệm về vấn đề hoặc khả năng trực tiếp để thực hiện thay đổi. Việc khắc phục lỗ hổng cũng giả định rằng những người chịu trách nhiệm bảo trì phần mềm nhận thức được vấn đề và có kiến ​​thức và nguồn lực để tiết lộ lỗ hổng.

Fuente: https://security.googleblog.com