Bài viết này dịch, thêm thắt từ bài "Given Enough Money, All Bugs Are Shallow" của Jeff Atwood.
Tiền (chi phí) và bug (lỗi phần mềm) có mỗi quan hệ hết sức mật thiết với nhau. Tôi xin liệt kê vài quy luật:
Bug được phát hiện càng muộn thì chi phí sửa càng lớn. Đôi khi không chỉ tỷ lệ với thời gian mà có thể là tỷ lệ bình phương thời gian.
Chỉ một lỗi ép kiểu dấu phẩy động 64 bit sang số tự nhiên 16 bit bị tràn đã khiến tên lửa Ariane 5 nổ tung vài giây sau khi rời bệ phóng. Xem video ở đây nhé. Hay lỗi của nhà khoa học châu Âu làm việc cho Nasa, khi ông này quen dùng hệ mét để tính toán trong khi các đồng nghiệp Mỹ là dùng hệ mile (dặm Mỹ) để tính khiến cho tàu đổ bộ không đủ năng lượng gửi thông tin về trái đất.
Eric Raymon từng viết "Give enough eyeballs, all bugs are shallow" ~ "Cứ có nhiều người xoi, lỗi nào cũng sẽ bị phát hiện". Ý tưởng này là nền tảng của phần mềm mã nguồn mở, bằng cách cho bất kỳ ai cũng có thể xem được mã nguồn, báo cáo lỗi, qua thời gian phần mềm sẽ ít lỗi hơn là phần mềm đóng mã. Quy luật Linux cũng phát biểu tương tự. Về cơ bản là ok. Code được viết kín bởi 10 lập trình viên trong một công ty nhỏ không thể nào được soi xét kỹ lưỡng như dự án mã nguồn được mở trên GitHub.
Tuy nhiên, lỗi Heartbleed SSL cho thấy một nghịch lý của quy luật này. Lỗi này nguy hiểm và tồi tệ đến mức ảnh hưởng đến 18% toàn bộ web site sử dụng giao thức HTTPs trên thế giới. Hacker có thể ngửi (sniff) các gói tin mã hóa SSL như là chưa được mã hóa trong 2 năm liền. Vâng 2 năm liền ! (bao nhiêu bí mật công nghệ, thông tin cá nhân, mã số tài khoản, mật khẩu đã bị đánh cắp vì Heartbleed SSL, ai có thể thống kê được?)
OpenSSL, thư viên dính lỗi này lại là thư viện mã nguồn mở được dùng ở hầu hết các hệ điều hành Linux, Unix, MacOSX... Nhẽ ra nó phải được thận trọng kiểm thử, đánh giá xoi xét khi đưa vào sử dụng chứ ?
Thực tế rất khó để sửa lỗi hầu hết các phần mềm mã nguồn mở. Tôi biết điều này vì tôi rất ít khi sửa lỗi mã nguồn mở dù tôi là một lập trình viên chuyên nghiệp. Thường thì tôi báo lại cho tác giả của mã đó và chờ xem anh ta sửa thế nào. ~ Neil Gunton.
Ngay cả cộng đồng hay vọc vạch đọc mã nguồn, họ cũng khó tìm ra những lỗi ẩn sâu. Bởi vì có rất ít trong số họ là chuyên gia về bảo mật ~ Jeremy Zawodny.
Thực tế là nhiều người dùng (many eyeballs), vọc vào phần mềm mã nguồn mở chưa hẳn đã làm nó an toàn hơn. Ngược lại tạo cảm giác cho nhiều người phần mềm đó rất an toàn --> Hiệu ứng đám đông ~ John Viega.
Tôi (Jeff Atwood) thấy ra vài vấn đề với quy luật Linux:
- Vọc vạch để dùng lại khác với vọc vạch để phát triển sửa đổi. Tải về gói RPM (Ubuntu), biên dịch mã nguồn trên Linux hay báo lại lỗi cho tác giả không có nghĩa là bạn đã tác động hay thực sự xem xét , soi kỹ lưỡng mã nguồn. Hầu hết lập trình viên sử dụng lại mã nguồn mở chỉ nhìn qua bề ngoài các hàm API, chứ ít ai đọc mã nguồn chạy các hàm API đó.
- Việc Copy & Paste dễ và nhanh hơn thực sự dành thời gian để đọc - phản biện mã nguồn của một ai đó. Càng nhiều code viết ra, càng nhiều thư viện, framework được viết ra cạnh tranh nhau về tính năng thì lại càng ít người đủ tâm trí quan tâm đánh giá mức độ bảo mật của chúng.
- Cộng đồng không có đủ các chuyên gia thực thụ để đánh giá mã nguồn. Số lượng lập trình viên thì tăng, nhưng chất lượng chiều sâu thì lại không tăng kịp.
Lỗi trái tim rỉ máu (Heartbleed SSL) là ví dụ thực tế chứng minh cho 3 vấn đề nói trên.
Ngày càng nhiều công ty trả tiền thưởng cho cộng đồng để tìm ra lỗi bảo mật
Một số công ty tự tổ chức các cuộc thi, một số thì thông qua các nhà tổ chức như BugCrowd, Synack, HackerOne, Crowcurity. Chủ phần mềm treo thưởng cho các hacker mũ trắng lao vào tìm sâu, bắt lỗi. Lỗi càng khó, càng hiểm thì thưởng càng to. Ví dụ giải ở Pwn2Own lên đến hàng trăm nghìn đô la. Thông điệp của ngày hôm nay: nếu bạn muốn phần mềm của mình thực sự an toàn, chất lượng bảo mật cao, hãy trả tiền cho chuyên gia vọc vạch để họ ganh đua nhau tìm lỗi.
Tiền khiến cho các lỗi bảo mật giấu làm con tin
Khi tiền trả ra để tìm lỗi bảo mật. Thì các chuyên gia bảo mật thường ém các lỗi này lại để chờ khi có giải thưởng đủ lớn mới công bố. Trong lúc các chuyên gia này ém lỗi bảo mật, các lỗi đó vẫn tồn tại, hacker mũ đen vẫn âm thầm khai thác nó. Sợ chưa. Lại một mặt trái của việc dùng tiền vá lỗ bảo mật nhé! Tôi (Jeff Atwood) thích cách Google tạo ra Pwnium:
- Biến sự kiện trao giải tìm lỗi bảo mật hàng năm thành việc hàng ngày.
- Tăng số tiền thưởng lên rất cao.
Biến việc tìm lỗi bảo mật là trách nhiệm cá nhân hơn là tập thể
Cha chung không ai khóc. Vài người báo một số lỗi bảo mật nhỏ trên Discourse sau đó cũng bỏ đấy. Mã nguồn mở là tặng miễn phí mà lại phải trả tiền cho người tìm lỗi thì phi lý quá. Đây là cách tôi đã làm: tôi đánh giá cao những báo lỗi từ cộng đồng, tôi cảm ơn những người báo lỗi bằng gửi tặng Sticker, áo phông, cảm ơn họ trực tiếp qua email, ghi danh họ trong mã nguồn và cập nhật code đã sửa.
Nếu không trả tiền tìm lỗi liệu mã nguồn mở có còn bảo mật?
Các công ty lớn có tài chính mạnh mở các giải thưởng để thu hút các chuyên gia săn bug tìm tiền thưởng. Vậy nếu phần mềm có chi phí thấp hoặc miễn phí có còn được các chuyên gia săn bug quan tâm. Một xu hướng biến lỗi bảo mật thành con tin để đổi trác tiền thưởng thực ra đã manh nha. Tôi đã nhận được những email gạ gẫm kiểu này.
Làm gì đây?
Mọi nhà phát triển, lập trình viên cùng có chung ít nhất một mục tiêu: Làm phần mềm ổn định hơn, an toàn hơn.
Các chương trình trao thưởng tìm lỗi bảo mật là một giải pháp hữu hiệu bổ xung cho việc mở mã nguồn để nhiều người dùng hơn, báo lỗi nhanh hơn. Tôi có vài lời khuyên cho các chương trình trao thưởng kiểu này:
- Công ty bạn nên cắt cử chuyên gia để tiếp nhận các báo lỗi từ cộng đồng hay các chuyên gia săn giải thưởng với quy trình tốt để tái tạo lại báo lỗi rõ ràng.
- Tổ chức các hoạt động có thưởng cuốn hút cộng đồng cùng hợp tác tìm ra lỗi hơn là giấu kín lỗi chờ săn giải thưởng.
- Xây dựng hệ thống minh bạch ghi nhận đóng góp của các cá nhân tìm ra lỗi
- Khuyến khích các tổ chức lớn tài trợ cho các cuộc tìm săn lỗi các dự án mã nguồn mở chứ không chỉ các dự án mã đóng.
Bình luận