SecureBuild , một dịch vụ tạo ra các bản build bảo mật của các dự án mã nguồn mở đồng thời chia sẻ doanh thu với những người duy trì, đã thu hút sự chú ý từ cộng đồng công nghệ - nhưng không nhất thiết vì những lý do mà họ mong đợi. Lời hứa về thỏa thuận mức độ dịch vụ (SLA) 6 ngày để sửa các lỗ hổng nghiêm trọng đã gây ra cuộc thảo luận gay gắt về những gì cấu thành thời gian phản hồi bảo mật phù hợp trong bối cảnh mối đe dọa ngày nay.
Tranh cãi về SLA 6 ngày
Cam kết 6 ngày của công ty để sửa các lỗi CVE nghiêm trọng đã trở thành tâm điểm của những lời chỉ trích. Các chuyên gia bảo mật trong cộng đồng đang đặt câu hỏi liệu thời gian này có đáp ứng các tiêu chuẩn bảo mật hiện đại hay không. Một số tổ chức được báo cáo là đang thúc đẩy giới hạn 48 giờ cho các bản vá lỗ hổng nghiêm trọng, khiến lời hứa của SecureBuild có vẻ chậm chạp khi so sánh.
Tuy nhiên, thực tế có vẻ phức tạp hơn. Trong khi SecureBuild nhằm mục đích cung cấp các bản sửa lỗi nhanh hơn nhiều so với 6 ngày đã hứa, họ thừa nhận rằng cây phụ thuộc sâu đôi khi có thể làm phức tạp quá trình vá lỗi. Công ty có kế hoạch tham vọng để cuối cùng giảm thời gian phản hồi xuống chỉ 6 giờ, mặc dù họ chưa cung cấp lộ trình để đạt được mục tiêu này.
Bảng So Sánh Thời Gian SLA của SecureBuild
- CVE Nghiêm Trọng: SLA 6 ngày (mục tiêu: 6 giờ)
- CVE Cao/Trung Bình/Thấp: SLA 13 ngày
- Kỳ vọng ngành: 48 giờ cho các lỗ hổng nghiêm trọng
- Tiêu chuẩn kiểm toán: Thường quy định 30 ngày cho các lỗ hổng nghiêm trọng
Suy nghĩ lại về chiến lược phản hồi CVE
Một lời chỉ trích đặc biệt sắc bén xuất hiện từ cuộc thảo luận cộng đồng, thách thức toàn bộ cách tiếp cận đua nhau sửa mọi CVE. Các chuyên gia bảo mật lập luận rằng các tổ chức không nên theo dõi lỗ hổng theo ngày, mà thay vào đó nên tập trung vào việc vá lỗi trước khi việc khai thác tích cực bắt đầu trong thực tế.
Bạn cần có các bản vá ra trước khi việc khai thác tích cực trong thực tế bắt đầu, đó là chỉ số duy nhất quan trọng.
Quan điểm này cho thấy rằng SecureBuild và các dịch vụ tương tự có thể đang giải quyết sai vấn đề. Thay vì hứa thời gian phản hồi chung cho tất cả CVE, trọng tâm nên là xác định những lỗ hổng nào thực sự đang được khai thác và ưu tiên chúng một cách phù hợp.
Kiểm tra thực tế mô hình kinh doanh
Ngoài cuộc tranh luận kỹ thuật, các thành viên cộng đồng đang đặt câu hỏi về tiền đề kinh doanh cơ bản. Một nhà quan sát lưu ý rằng có thể có sự chồng chéo tối thiểu giữa các tổ chức dựa bảo mật của họ trên phản hồi CVE nhanh chóng và những tổ chức thực sự quan tâm đến việc hỗ trợ tài chính các dự án mã nguồn mở.
Lãnh đạo SecureBuild đã phản bác sự hoài nghi này, chỉ ra cơ sở khách hàng của họ gồm các nhà cung cấp phần mềm độc lập (ISV) phân phối phần mềm thương mại cho các môi trường doanh nghiệp như ngân hàng và cơ quan chính phủ. Họ tuyên bố gần một nửa khách hàng của họ là các công ty open-core, cho thấy thực sự có thị trường cho các tổ chức có ý thức bảo mật muốn hỗ trợ tính bền vững của mã nguồn mở.
Mô hình chia sẻ doanh thu
- Các nhà phát triển mã nguồn mở: 70% doanh thu từ đăng ký
- SecureBuild : 30% doanh thu từ đăng ký
- Không yêu cầu hợp đồng hỗ trợ
- Không cần thay đổi mã nguồn từ các dự án
Nhìn về phía trước
Cuộc thảo luận tiết lộ một căng thẳng rộng lớn hơn trong ngành bảo mật giữa quản lý lỗ hổng toàn diện và phản ứng mối đe dọa có mục tiêu. Trong khi mô hình chia sẻ doanh thu 70-30 của SecureBuild với những người duy trì mã nguồn mở giải quyết những thách thức bền vững thực sự, cách tiếp cận bảo mật của họ có thể cần tinh chỉnh để đáp ứng kỳ vọng ngành đang phát triển.
Khi các tổ chức ngày càng đòi hỏi thời gian phản hồi nhanh hơn và ưu tiên mối đe dọa tinh vi hơn, các dịch vụ như SecureBuild sẽ cần cân bằng lộ trình tham vọng của họ với thực tế thực tế của các phụ thuộc phần mềm phức tạp và bản chất thực sự của các mối đe dọa bảo mật.
Tham khảo: Secure, Sustainable Open Source