Hầu hết các nhà sáng lập nghĩ rằng bảo mật chỉ là bảo vệ hợp đồng thông minh. Nhưng dưới đây là một số quan niệm sai lầm phổ biến so với thực tế mà mọi nhà sáng lập cần hiểu rõ. > Quan niệm sai lầm: Một khi chúng tôi đã vượt qua kiểm toán, chúng tôi đã an toàn. Thực tế: Theo tôi, đây là một trong những hiểu lầm lớn nhất trong Web3. Kiểm toán không phải là chứng nhận bảo mật, mà chỉ là đánh giá mã nguồn của bạn tại một thời điểm cụ thể. Ngay khi bạn ra mắt tính năng mới, tích hợp một giao thức khác, cập nhật oracle hoặc thay đổi hạ tầng backend, hồ sơ rủi ro của bạn sẽ thay đổi. Kiểm toán giúp giảm rủi ro, nhưng mỗi lần cập nhật sau đó đều cần mức độ chú ý tương đương. > Quan niệm sai lầm: Hacker chỉ khai thác hợp đồng thông minh. Thực tế: Tôi không còn nghĩ điều đó đúng nữa. Những tổn thất lớn nhất trong vài năm qua không đến từ lỗi Solidity, mà từ các khóa riêng bị xâm phạm, lừa đảo, lỗi kiểm soát truy cập, hạ tầng backend, người ký oracle và sai sót vận hành. Giao diện người dùng, API, quy trình triển khai, ví và hạ tầng của bạn đều là một phần trong bề mặt tấn công của bạn. Theo tôi, các nhà sáng lập cần suy nghĩ vượt ra ngoài hợp đồng thông minh. Hạ tầng, khóa và quy trình vận hành của bạn quan trọng không kém. > Quan niệm sai lầm: Chúng tôi quá nhỏ để trở thành mục tiêu. Thực tế: Kẻ tấn công thường không quan tâm đến số lượng người theo dõi dự án của bạn. Họ chỉ quan tâm đến một điều: liệu họ có thể khai thác giá trị hay không. Nếu giao thức của bạn đang nắm giữ tài sản hoặc có người dùng, bạn đã trở thành mục tiêu hấp dẫn với ai đó. Việc chờ đến khi quy mô đủ lớn mới đầu tư vào bảo mật thường là quá muộn. > Quan niệm sai lầm: Một người ký hoặc khóa quản trị đáng tin cậy là đủ. Thực tế: Theo tôi, mọi khóa đặc quyền đều nên được đối xử như kho bạc của bạn. Khóa oracle, khóa triển khai, khóa nâng cấp, người ký multisig, thông tin đăng nhập backend — tất cả đều có thể trở thành điểm lỗi duy nhất. Một thông tin xác thực bị xâm phạm có thể khiến toàn bộ giao thức gặp nguy hiểm. > Quan niệm sai lầm: Chúng tôi sẽ cải thiện bảo mật sau khi ra mắt. Thực tế: Kẻ tấn công sẽ không chờ đến lúc đó. Các nhà sáng lập thường nghĩ bảo mật có thể được thêm vào ở các phiên bản sau. Tuy nhiên, các vụ khai thác không tuân theo lịch trình sản phẩm. Thời điểm tốt nhất để xây dựng giám sát, phản ứng sự cố và bảo mật vận hành là trước khi người dùng tin tưởng giao tài sản cho bạn. > Quan niệm sai lầm: Kiểm thử nội bộ là đủ. Thực tế: Nhóm của bạn biết cách giao thức hoạt động như mong đợi. Một nhà nghiên cứu bên ngoài lại nghĩ về cách nó có thể thất bại. Đó là lý do tại sao kiểm toán, đánh giá cạnh tranh, phần thưởng lỗi và kiểm thử liên tục đều đóng những vai trò khác nhau. Bảo mật được cải thiện nhờ những góc nhìn mới mẻ. > Quan niệm sai lầm: Mã nguồn mở có nghĩa là ai đó sẽ tìm thấy lỗi. Thực tế: Mã nguồn mở cải thiện tính minh bạch. Nhưng nó không đảm bảo ai đó sẽ xem xét từng dòng mã hoặc tiết lộ có trách nhiệm mọi lỗ hổng. Việc công bố mã không giống với việc xác minh nó. > Quan niệm sai lầm: Bảo mật là trách nhiệm của người kiểm toán. Thực tế: Đây có lẽ là sự thay đổi tư duy lớn nhất mà các nhà sáng lập cần thực hiện. Người kiểm toán giúp giảm rủi ro. Nhưng bảo mật được xây dựng bởi tất cả mọi người — các nhà sáng lập đưa ra quyết định sản phẩm, lập trình viên viết mã, nhóm DevOps quản lý hạ tầng và đội vận hành bảo vệ quyền truy cập. Tôi luôn tin rằng bảo mật không phải là thứ bạn hoàn thành, mà là thứ bạn không ngừng cải thiện. Tóm lại cuối cùng: Bối cảnh bảo mật đã thay đổi. Và tôi tin rằng cách tiếp cận của chúng ta đối với bảo mật cũng cần thay đổi theo. Việc chỉ tập trung vào hợp đồng thông minh giờ đây là chưa đủ. Là các nhà sáng lập, chúng ta cần nghĩ đến việc bảo vệ toàn bộ giao thức — từ hợp đồng và hạ tầng đến khóa, kiểm soát truy cập và mọi hệ thống duy trì hoạt động của giao thức.