Công bố lỗ hổng

Công bố lỗ hổng là gì?

Công bố lỗ hổng là quy trình báo cáo, xác thực, khắc phục và công khai thông tin về điểm yếu bảo mật trong phần mềm, hợp đồng thông minh, ví, giao thức, cơ sở hạ tầng hoặc ứng dụng Web3.

Trong crypto, công bố lỗ hổng đặc biệt quan trọng vì chỉ một lỗi có thể khiến tiền của người dùng, ngân quỹ giao thức, bridge, validator, hợp đồng quản trị, ví, NFT hoặc vị thế DeFi gặp rủi ro.

Hướng dẫn công bố lỗ hổng liên bang của NIST mô tả công bố lỗ hổng là một khuôn khổ để báo cáo, đánh giá và quản lý việc công bố lỗ hổng.

Chương trình công bố lỗ hổng có phối hợp của CISA mô tả công bố lỗ hổng có phối hợp là một phần của việc bảo vệ cơ sở hạ tầng trọng yếu và nâng cao an ninh mạng.

Nói đơn giản, công bố lỗ hổng là thông báo cho đúng đối tượng về một lỗi bảo mật trước khi kẻ tấn công có thể khai thác lỗi đó hoặc trước khi người dùng chịu thiệt hại có thể tránh được.

Một quy trình công bố tốt mang đến cho nhà nghiên cứu bảo mật một kênh báo cáo an toàn.

Nó cho đội ngũ dự án thời gian xác nhận vấn đề, chuẩn bị bản sửa lỗi, bảo vệ người dùng và truyền thông rõ ràng.

Nó cũng cung cấp cho công chúng đủ thông tin để hiểu rủi ro sau khi sự cố được xử lý.

Vì sao công bố lỗ hổng quan trọng trong crypto?

Công bố lỗ hổng quan trọng trong crypto vì các hệ thống blockchain thường quản lý trực tiếp giá trị tài chính thực thông qua mã.

Một lỗi ứng dụng web thông thường có thể làm lộ dữ liệu hoặc gián đoạn dịch vụ.

Một lỗi hợp đồng thông minh có thể cho phép đánh cắp tài sản tức thời, mint vô hạn, thao túng oracle, chiếm quyền quản trị, rút cạn bridge, lạm dụng thanh lý hoặc khóa tiền vĩnh viễn.

Cơ sở dữ liệu hack của DeFiLlama theo dõi hàng tỷ USD thiệt hại từ các vụ hack DeFi, bridge, lỗi logic giao thức và các hình thức khai thác crypto khác.

Điều này cho thấy công bố lỗ hổng crypto không chỉ là phép lịch sự về kỹ thuật.

Đó là một quy trình bảo vệ an toàn tài chính.

Khi whitehat báo cáo lỗi một cách có trách nhiệm, giao thức có thể khắc phục vấn đề trước khi kẻ tấn công phát hiện ra.

Khi giao thức phớt lờ báo cáo hoặc không có kênh công bố, nhà nghiên cứu có thể không biết nên báo cáo an toàn ở đâu.

Khi công bố diễn ra quá sớm, kẻ tấn công có thể khai thác điểm yếu trước khi người dùng được bảo vệ.

Khi công bố diễn ra quá muộn, người dùng có thể tiếp tục tương tác với mã rủi ro mà không nhận biết nguy hiểm.

Mục tiêu là giảm thiệt hại trong khi vẫn duy trì tính minh bạch.

Công bố lỗ hổng và công bố lỗ hổng có phối hợp

Công bố lỗ hổng là hành động rộng hơn của việc báo cáo và truyền đạt thông tin về một lỗi bảo mật.

Công bố lỗ hổng có phối hợp, thường được rút gọn là CVD, là quy trình có cấu trúc trong đó nhà nghiên cứu, nhà cung cấp, đội ngũ dự án, các bên bị ảnh hưởng và đôi khi là điều phối viên cùng hợp tác trước khi công bố công khai.

Hướng dẫn CERT về công bố lỗ hổng có phối hợp giải thích CVD là quy trình có sự tham gia của người phát hiện, người báo cáo, nhà cung cấp và điều phối viên.

Trong Web3, công bố có phối hợp có thể liên quan đến nhà nghiên cứu bảo mật, đội ngũ cốt lõi của giao thức, người ký multisig, đại biểu DAO, auditor, nhà phát triển ví, đơn vị vận hành bridge, nhà cung cấp cơ sở hạ tầng hoặc nền tảng bug bounty.

Việc phối hợp quan trọng vì các hệ thống crypto thường có tính kết hợp.

Lỗ hổng trong một giao thức có thể ảnh hưởng đến các giao thức khác tích hợp nó.

Lỗi trong thư viện ví có thể ảnh hưởng đến nhiều ứng dụng.

Lỗ hổng trong bridge có thể ảnh hưởng đến tài sản trên nhiều chain.

Quy trình công bố phải xác định ai cần biết, khi nào cần biết và cách chia sẻ thông tin mà không làm tăng rủi ro bị tấn công.

Công bố lỗ hổng và bug bounty

Công bố lỗ hổng và bug bounty có liên quan nhưng không phải là cùng một khái niệm.

Công bố lỗ hổng là quy trình báo cáo và xử lý một điểm yếu bảo mật.

Bug bounty là chương trình phần thưởng trả cho nhà nghiên cứu khi báo cáo lỗ hổng hợp lệ.

Một dự án có thể có chính sách công bố lỗ hổng mà không trả phần thưởng.

Một dự án cũng có thể có chương trình bug bounty với phạm vi nghiêm ngặt, quy tắc mức độ nghiêm trọng, khung phần thưởng, yêu cầu báo cáo và hạn chế công bố.

Chương trình Bug Bounty của Ethereum Foundation cho thấy cách một hệ sinh thái giao thức lớn xác định kênh báo cáo, phạm vi và kỳ vọng đối với nghiên cứu bảo mật.

Bug bounty có thể khuyến khích nhà nghiên cứu báo cáo vấn đề thay vì bán riêng hoặc khai thác chúng.

Tuy nhiên, phần thưởng không tự động khiến dự án trở nên bảo mật.

Dự án vẫn cần phân loại, phản hồi kỹ thuật, triển khai bản vá, truyền thông với người dùng và kế hoạch xử lý sự cố.

Bug bounty là lớp khuyến khích, trong khi công bố lỗ hổng là toàn bộ quy trình an toàn.

Công bố có trách nhiệm và công bố toàn bộ

Công bố có trách nhiệm thường là báo cáo riêng tư một lỗ hổng cho đội ngũ bị ảnh hưởng và cho họ thời gian khắc phục trước khi chi tiết được công bố công khai.

Công bố toàn bộ là việc công khai chi tiết lỗ hổng, đôi khi ngay lập tức và đôi khi sau một thời hạn.

Trong crypto, công bố toàn bộ ngay lập tức có thể cực kỳ nguy hiểm nếu lỗi ảnh hưởng đến hợp đồng thông minh đang hoạt động có tiền của người dùng.

Kẻ tấn công có thể sao chép báo cáo và khai thác giao thức trước khi bản sửa lỗi được triển khai.

Tuy nhiên, công bố riêng tư vô thời hạn cũng có thể gây hại vì người dùng có thể tiếp tục gặp rủi ro trong khi dự án trì hoãn hành động.

Đó là lý do công bố có phối hợp thường sử dụng timeline, quy tắc leo thang và kỳ vọng công bố công khai.

Kho lưu trữ công bố công khai của Ethereum cho biết Ethereum Foundation hướng tới việc công khai các lỗi được báo cáo qua chương trình bug bounty trong 90 ngày, với thời điểm được điều chỉnh nếu hoàn cảnh yêu cầu.

Timeline rõ ràng giúp cân bằng việc bảo vệ người dùng, tính công bằng với nhà nghiên cứu và minh bạch công khai.

Chính sách công bố lỗ hổng

Chính sách công bố lỗ hổng hướng dẫn nhà nghiên cứu cách báo cáo vấn đề bảo mật an toàn.

Chính sách này nên giải thích hệ thống nào thuộc phạm vi.

Nó nên giải thích hoạt động kiểm thử nào được phép.

Nó nên giải thích hoạt động kiểm thử nào bị cấm.

Nó nên liệt kê kênh báo cáo chính thức.

Nó nên mô tả thời gian phản hồi dự kiến.

Nó nên giải thích điều khoản safe harbor nếu có.

Nó nên mô tả cách xử lý công bố công khai.

Nó nên giải thích có cung cấp phần thưởng hay không.

Nó nên hướng dẫn nhà nghiên cứu bảo vệ dữ liệu người dùng và tránh gây hại.

Trang tiêu chuẩn ISO/IEC 29147:2018 cho biết công bố lỗ hổng đưa ra các yêu cầu và khuyến nghị dành cho nhà cung cấp về việc công bố lỗ hổng trong sản phẩm và dịch vụ.

Đối với dự án crypto, chính sách công bố cũng nên nêu rõ phạm vi hợp đồng thông minh, frontend, oracle, bridge, ví, quản trị và quy trình khẩn cấp đối với ngân quỹ.

Security.txt và các kênh báo cáo

Nhà nghiên cứu bảo mật thường gặp khó khăn trong việc tìm đúng đầu mối để báo cáo lỗ hổng.

Đó là lý do security.txt tồn tại.

RFC 9116 định nghĩa security.txt là định dạng máy có thể đọc, giúp tổ chức mô tả hoạt động công bố lỗ hổng của mình.

Tệp security.txt có thể liệt kê thông tin liên hệ, khóa mã hóa, liên kết chính sách, liên kết tuyển dụng, ghi nhận đóng góp và ưu tiên công bố.

Với dự án crypto, security.txt có thể giúp whitehat nhanh chóng tìm đúng kênh báo cáo.

Điều này quan trọng vì mỗi giờ đều có thể đáng giá trong lúc có nguy cơ khai thác đang diễn ra.

Dự án không nên buộc nhà nghiên cứu phải tìm kiếm các kênh xã hội ngẫu nhiên, nhắn tin trực tiếp cho nhà sáng lập hoặc đoán địa chỉ email nào là thật.

Kênh báo cáo rõ ràng giảm nhầm lẫn và cải thiện tốc độ phản hồi.

Một dự án Web3 có giá trị lớn gặp rủi ro nên công bố đầu mối bảo mật trong tài liệu chính thức, footer website, chính sách bảo mật của kho lưu trữ và tệp security.txt.

Các lỗ hổng crypto phổ biến cần được công bố

Công bố lỗ hổng crypto có thể liên quan đến nhiều loại điểm yếu.

Lỗi hợp đồng thông minh có thể bao gồm reentrancy, lỗi kiểm soát quyền truy cập, thao túng oracle giá, lỗi số học, lỗi logic nghiệp vụ, lệnh gọi bên ngoài không được kiểm tra và lỗi khả năng nâng cấp.

OWASP Smart Contract Top 10 2026 liệt kê các rủi ro lớn của hợp đồng thông minh Web3 như lỗ hổng kiểm soát quyền truy cập, lỗ hổng logic nghiệp vụ, thao túng oracle giá, tấn công flash loan, lệnh gọi bên ngoài không được kiểm tra, reentrancy, tràn số nguyên và vấn đề nâng cấp proxy.

Lỗ hổng ví có thể liên quan đến ký không an toàn, lộ seed phrase, lỗi mô phỏng giao dịch, yêu cầu dApp độc hại hoặc lưu trữ khóa không an toàn.

Lỗ hổng bridge có thể liên quan đến validator bị xâm phạm, lỗi xác minh thông điệp, tấn công replay, kiểm tra finality không đủ hoặc điểm yếu lưu ký.

Lỗ hổng frontend có thể liên quan đến chiếm quyền DNS, chèn JavaScript độc hại, địa chỉ hợp đồng giả, dependency gói bị xâm phạm hoặc thay đổi giao diện rút cạn ví.

Lỗ hổng cơ sở hạ tầng có thể liên quan đến lỗi RPC, lỗi indexer, sự cố client validator, lộ API, quản lý private key hoặc cấu hình cloud sai.

Chương trình công bố tốt xác định vấn đề nào thuộc phạm vi và cách cần báo cáo chúng.

Công bố lỗ hổng hợp đồng thông minh

Công bố lỗ hổng hợp đồng thông minh đặc biệt nhạy cảm vì hợp đồng thông minh có thể công khai, bất biến và kết nối trực tiếp với tiền.

Nhà nghiên cứu phát hiện lỗi hợp đồng thông minh nên tránh khai thác lỗi để thu lợi.

Nhà nghiên cứu nên tránh di chuyển tiền của người dùng, trừ khi có quy trình safe harbor hoặc cứu hộ khẩn cấp được cấp phép rõ ràng.

Nhà nghiên cứu nên thu thập đủ bằng chứng để chứng minh vấn đề mà không gây hại không cần thiết.

Đội ngũ giao thức nên nhanh chóng xác nhận đã nhận báo cáo.

Đội ngũ nên tái hiện sự cố trong môi trường an toàn.

Đội ngũ nên đánh giá hợp đồng bị ảnh hưởng, tiền bị ảnh hưởng, tích hợp, hướng nâng cấp và biện pháp kiểm soát quản trị.

Đội ngũ nên quyết định liệu có cần tạm dừng, nâng cấp, di chuyển, thông báo bên tích hợp hoặc thực hiện hành động khẩn cấp hay không.

Sau khi biện pháp bảo vệ được áp dụng, đội ngũ nên công bố postmortem hoặc thông báo tư vấn rõ ràng khi an toàn.

Công bố lỗ hổng hợp đồng thông minh cần thận trọng vì khi chi tiết khai thác đã công khai, kẻ tấn công có thể hành động nhanh.

Nền tảng bug bounty trong Web3

Các nền tảng bug bounty giúp quản lý báo cáo lỗ hổng, phân loại, phần thưởng, chấm điểm mức độ nghiêm trọng, trao đổi với nhà nghiên cứu và phạm vi chương trình.

Nền tảng Immunefi mô tả mình sử dụng tập dữ liệu lớn về khai thác blockchain, báo cáo lỗi và bản sửa lỗi để hỗ trợ phòng thủ bảo mật on-chain.

Nghiên cứu năm 2026 của Immunefi về các lỗ hổng crypto nghiêm trọng báo cáo rằng phần lớn lỗ hổng nghiêm trọng sau khi ra mắt trong crypto được công bố qua nền tảng này.

Nền tảng bug bounty có thể giúp dự án nhận báo cáo theo cách có cấu trúc.

Nó cũng có thể giúp nhà nghiên cứu hiểu nơi gửi báo cáo, nội dung đủ điều kiện và cách tính phần thưởng.

Tuy nhiên, nền tảng không loại bỏ trách nhiệm của đội ngũ dự án.

Dự án vẫn cần kỹ sư, người phụ trách bảo mật, người ký khẩn cấp, rà soát pháp lý và kế hoạch truyền thông.

Hộp thư nhận bounty không có năng lực phản hồi có thể khiến nhà nghiên cứu thất vọng và tăng rủi ro cho người dùng.

Một chương trình bounty Web3 nghiêm túc nên tương xứng với giá trị gặp rủi ro.

Đánh giá mức độ nghiêm trọng và tác động

Đánh giá mức độ nghiêm trọng quyết định lỗ hổng nguy hiểm đến mức nào.

Trong crypto, mức độ nghiêm trọng nên tập trung vào tác động thực tế, không chỉ vẻ tinh tế về mặt kỹ thuật.

Lỗ hổng nghiêm trọng có thể cho phép đánh cắp trực tiếp, mất tiền vĩnh viễn, mint vô hạn, chiếm quyền quản trị, xâm phạm bridge, slashing validator hoặc dừng giao thức.

Sự cố mức độ cao có thể cần điều kiện đặc biệt nhưng vẫn đe dọa lượng tiền lớn hoặc quyền hạn quan trọng.

Sự cố mức độ trung bình có thể gây tổn thất hạn chế, từ chối dịch vụ, hạch toán sai hoặc leo thang đặc quyền có giới hạn.

Sự cố mức độ thấp có thể là điểm yếu nhỏ với tác động thực tế hạn chế.

Chấm điểm mức độ nghiêm trọng tốt nên xem xét tài sản gặp rủi ro, độ phức tạp khai thác, đặc quyền cần có, người dùng bị ảnh hưởng, tính kết hợp, khả năng nâng cấp và việc kẻ tấn công có thể khai thác on-chain trong một giao dịch hay không.

Mức độ nghiêm trọng cũng nên xem xét lỗi đã được biết đến, đã bị khai thác hoặc hiển thị trong mã công khai hay chưa.

Chương trình công bố mạnh giải thích cách mức độ nghiêm trọng tương ứng với mức độ ưu tiên phản hồi và khung bounty.

Timeline công bố

Timeline công bố xác định thời điểm báo cáo được xác nhận, thời điểm phân loại, thời điểm dự kiến có bản sửa lỗi và thời điểm có thể công bố công khai.

Công bố phần mềm truyền thống thường sử dụng các mốc như 60 hoặc 90 ngày tùy chính sách.

Timeline crypto có thể ngắn hơn khi tiền đang hoạt động gặp rủi ro.

Một vụ khai thác hợp đồng thông minh có thể cần phản ứng khẩn cấp trong vài phút hoặc vài giờ.

Nâng cấp giao thức có thể cần hành động multisig, phiếu bầu quản trị, thời gian chờ timelock, di chuyển thanh khoản hoặc thời gian rút tiền cho người dùng.

Điều này làm timeline công bố trong Web3 phức tạp hơn.

Nếu công bố trước khi timelock kết thúc, kẻ tấn công có thể khai thác lỗi đã biết trước khi bản sửa lỗi được thực thi.

Nếu trì hoãn công bố quá lâu, người dùng có thể vô tình tiếp tục nạp vào hợp đồng có lỗ hổng.

Một chính sách tốt giải thích ngoại lệ khẩn cấp, kỳ vọng về lệnh cấm tiết lộ, cập nhật cho nhà nghiên cứu và quy tắc công bố công khai.

Timeline rõ ràng làm giảm xung đột giữa nhà nghiên cứu và dự án.

Whitehat và safe harbor

Whitehat là nhà nghiên cứu bảo mật hướng tới bảo vệ người dùng và hệ thống thay vì khai thác độc hại.

Trong crypto, whitehat đôi khi phải đối mặt với lựa chọn khó khăn trong vụ khai thác đang diễn ra vì tiền on-chain có thể bị rút cạn nhanh chóng.

Một số tình huống có thể cần hành động cứu hộ khẩn cấp, nhưng hành động đó có thể tạo rủi ro pháp lý và đạo đức nếu không được cấp phép rõ ràng.

Khuôn khổ SEAL Whitehat Safe Harbor mô tả khuôn khổ pháp lý và kỹ thuật cho phép giao thức cấp phép trước cho whitehat can thiệp trong vụ khai thác đang diễn ra, cứu tiền và hoàn trả theo các quy tắc xác định.

Ngôn ngữ safe harbor giúp giảm sự không chắc chắn cho nhà nghiên cứu có đạo đức.

Nó cũng giúp giao thức xác định hành động khẩn cấp nào được cho phép trước khi khủng hoảng xảy ra.

Không có safe harbor, whitehat di chuyển tiền để bảo vệ người dùng vẫn có thể đối mặt rủi ro pháp lý.

Với safe harbor rõ ràng, giao thức có thể thiết lập trước ranh giới, quy tắc hoàn trả, yêu cầu báo cáo và biện pháp bảo vệ pháp lý.

Rủi ro pháp lý và đạo đức

Công bố lỗ hổng có thể liên quan đến rủi ro pháp lý cho cả nhà nghiên cứu và dự án.

Nhà nghiên cứu có thể vi phạm luật, điều khoản dịch vụ, quy định về lạm dụng máy tính, quy định về quyền riêng tư hoặc quy định chống vượt biện pháp bảo vệ nếu việc kiểm thử không được ủy quyền.

Dự án có thể tạo rủi ro khi đe dọa nhà nghiên cứu, phớt lờ báo cáo, không cảnh báo người dùng hoặc xử lý sai dữ liệu cá nhân.

Đó là lý do chính sách công bố cần xác định rõ hoạt động kiểm thử được ủy quyền.

Nhà nghiên cứu nên tránh kiểm thử phá hoại, đánh cắp dữ liệu, từ chối dịch vụ, social engineering và di chuyển tiền thật trừ khi được cho phép rõ ràng.

Nhà nghiên cứu nên báo cáo nhanh và giữ bằng chứng ở mức tối thiểu.

Dự án nên phản hồi tôn trọng và tránh coi báo cáo thiện chí là cuộc tấn công.

Crypto bổ sung tính phức tạp pháp lý vì tiền có thể dịch chuyển xuyên biên giới và giao thức có thể do DAO hoặc foundation quản trị.

Chính sách rõ ràng không thể loại bỏ toàn bộ rủi ro pháp lý, nhưng có thể giảm nhầm lẫn và cải thiện niềm tin.

Bảo vệ pháp lý cho whitehat nên được lên kế hoạch trước khi lỗ hổng trở thành tình trạng khẩn cấp.

Công bố lỗ hổng cho DAO

DAO cần quy trình công bố lỗ hổng đặc biệt vì việc ra quyết định có thể công khai, chậm và do quản trị dẫn dắt.

Hướng dẫn DAO chính thức của Ethereum mô tả DAO là các tổ chức có nguồn gốc trên internet, được thành viên cùng sở hữu và quản lý.

Quản trị công khai có giá trị, nhưng thảo luận công khai về lỗ hổng nghiêm trọng chưa được vá có thể nguy hiểm.

DAO có thể cần hội đồng bảo mật riêng tư, multisig khẩn cấp, ủy ban bug bounty hoặc nhóm công bố với quyền truy cập hạn chế.

Nhóm này có thể phân loại báo cáo nhạy cảm trước khi thảo luận công khai hoàn toàn.

DAO vẫn có thể công bố postmortem và báo cáo trách nhiệm giải trình sau khi người dùng được bảo vệ.

Thách thức chính là cân bằng minh bạch và bảo mật vận hành.

Nếu mọi bản sửa lỗi cần đề xuất công khai, kẻ tấn công có thể khai thác trước khi quản trị hoàn tất.

Nếu mọi hành động khẩn cấp đều bí mật, người dùng có thể mất niềm tin.

DAO trưởng thành xác định quyền hạn khẩn cấp, quy tắc công bố, trách nhiệm người ký và kỳ vọng báo cáo công khai trước khủng hoảng.

Công bố lỗ hổng cho giao thức DeFi

Giao thức DeFi cần phản hồi công bố nhanh vì tài sản có thể bị rút cạn hoặc thao túng trực tiếp on-chain.

Hướng dẫn DeFi chính thức của Ethereum giải thích rằng tài chính phi tập trung sử dụng blockchain công khai và hợp đồng thông minh để cung cấp sản phẩm và dịch vụ tài chính.

Lỗ hổng DeFi có thể ảnh hưởng đến pool thanh khoản, thị trường cho vay, phép tính tài sản thế chấp, cổ phần vault, oracle, logic thanh lý, hạch toán phần thưởng, hợp đồng staking hoặc biện pháp kiểm soát quản trị.

Tính kết hợp khiến việc này khó hơn vì một giao thức có lỗ hổng có thể được tích hợp vào nhiều giao thức khác.

Phản hồi công bố DeFi nên nhanh chóng xác định các tích hợp hạ nguồn.

Nó nên đánh giá có cần tạm dừng nạp tiền hay không.

Nó nên quyết định có cần rút tiền khẩn cấp, nâng cấp hợp đồng, thay đổi oracle hoặc di chuyển thanh khoản hay không.

Nó nên phối hợp với auditor và đối tác bảo mật khi có thể.

Nó nên truyền đạt đủ để bảo vệ người dùng mà không tiết lộ hướng dẫn khai thác quá sớm.

Sau khi khắc phục, giao thức nên giải thích rõ nguyên nhân gốc rễ và tác động đối với người dùng.

Công bố lỗ hổng cho ví và ứng dụng Web3

Lỗ hổng ví và ứng dụng Web3 có thể gây hại cho người dùng ngay cả khi hợp đồng thông minh không bị lỗi.

Lỗi ví có thể hiển thị sai chi tiết giao dịch.

Lỗi frontend dApp có thể dẫn người dùng đến sai hợp đồng.

Lỗi kết nối ví có thể phê duyệt sai chain hoặc phương thức.

Lỗi mô phỏng giao dịch có thể che giấu việc di chuyển tài sản nguy hiểm.

Lỗi extension trình duyệt có thể làm lộ dữ liệu nhạy cảm.

Một dependency bị xâm phạm có thể chèn mã rút cạn ví.

Hướng dẫn bảo mật chính thức của Ethereum giải thích người dùng phải bảo vệ quyền truy cập ví, private key và cụm từ khôi phục.

Công bố lỗ hổng ví cần được xử lý cực kỳ thận trọng vì người dùng phụ thuộc vào giao diện ví để hiểu nội dung họ đang ký.

Đội ngũ ví nên có đầu mối bảo mật rõ ràng, quy trình cập nhật nhanh, kế hoạch truyền thông về rủi ro ký và hệ thống cảnh báo người dùng.

Ứng dụng Web3 không nên cho rằng audit hợp đồng là đủ nếu frontend có thể bị xâm phạm.

Công bố công khai và postmortem

Công bố công khai nên giúp người dùng hiểu điều gì đã xảy ra, điều gì bị ảnh hưởng, điều gì đã được khắc phục và họ cần thực hiện hành động gì.

Một postmortem tốt giải thích loại lỗ hổng.

Nó giải thích timeline.

Nó giải thích hợp đồng hoặc hệ thống bị ảnh hưởng.

Nó giải thích tiền có gặp rủi ro hoặc bị mất hay không.

Nó giải thích bản sửa lỗi.

Nó giải thích người dùng nên làm gì tiếp theo.

Nó giải thích đội ngũ sẽ cải thiện điều gì.

Nó ghi nhận nhà nghiên cứu khi phù hợp và được phép.

Nó tránh công bố chi tiết có thể dùng ngay để khai thác trước khi người dùng được bảo vệ.

Công bố công khai quan trọng vì người dùng crypto thường cần quyết định có nên rút tiền, di chuyển, thu hồi quyền phê duyệt, cập nhật ví, tránh frontend hoặc theo dõi địa chỉ hay không.

Im lặng có thể gây hại vì khiến người dùng phải phỏng đoán.

Công bố rõ ràng xây dựng niềm tin ngay cả khi lỗ hổng nghiêm trọng.

Nhà nghiên cứu nên đưa gì vào báo cáo?

Một báo cáo lỗ hổng tốt cần rõ ràng, dựa trên thực tế và có thể tái tạo.

Báo cáo nên bao gồm dự án, thành phần, hợp đồng, commit, endpoint, phiên bản ví, chain hoặc địa chỉ bị ảnh hưởng.

Báo cáo nên mô tả lỗ hổng bằng ngôn ngữ dễ hiểu.

Báo cáo nên giải thích tác động.

Báo cáo nên có các bước proof of concept tránh gây hại cho người dùng thực.

Báo cáo nên nêu hành vi kỳ vọng và hành vi thực tế.

Báo cáo nên bao gồm ảnh chụp màn hình, log, giao dịch kiểm thử, kết quả kiểm thử cục bộ hoặc đoạn mã khi hữu ích.

Báo cáo nên giải thích tiền có gặp rủi ro hay không.

Báo cáo nên giải thích vấn đề có vẻ khai thác được trên mainnet hay không.

Báo cáo nên tránh các bí mật không cần thiết, dữ liệu người dùng và việc khai thác thực tế.

Báo cáo tốt giúp đội ngũ tái hiện và khắc phục vấn đề nhanh.

Dự án nên làm gì sau khi nhận báo cáo?

Dự án nên nhanh chóng xác nhận đã nhận báo cáo.

Dự án nên chỉ định người phụ trách bảo mật.

Dự án nên xác minh tuyên bố của nhà nghiên cứu trong môi trường an toàn.

Dự án nên đánh giá mức độ nghiêm trọng và hệ thống bị ảnh hưởng.

Dự án nên bảo toàn bằng chứng.

Dự án nên tránh thảo luận công khai trước khi có kế hoạch bảo vệ.

Dự án nên chuẩn bị bản sửa lỗi hoặc biện pháp giảm thiểu.

Dự án nên phối hợp với bên tích hợp bị ảnh hưởng nếu cần.

Dự án nên trả phần thưởng theo chính sách bounty khi áp dụng.

Dự án nên giao tiếp với nhà nghiên cứu một cách tôn trọng.

Dự án nên công bố thông tin hoặc postmortem khi người dùng được bảo vệ.

Dự án phớt lờ báo cáo tạo rủi ro cho người dùng và làm tổn hại niềm tin của nhà nghiên cứu.

Lợi ích của công bố lỗ hổng

Lợi ích đầu tiên là bảo vệ người dùng.

Lỗi bảo mật có thể được khắc phục trước khi kẻ tấn công khai thác.

Lợi ích thứ hai là niềm tin của nhà nghiên cứu.

Whitehat có nhiều khả năng báo cáo vấn đề hơn khi quy trình rõ ràng và công bằng.

Lợi ích thứ ba là khả năng chống chịu của giao thức.

Dự án học hỏi từ điểm yếu và cải thiện kiến trúc bảo mật.

Lợi ích thứ tư là tính minh bạch.

Người dùng có thể hiểu rủi ro thực tế sau khi sự cố được giải quyết.

Lợi ích thứ năm là an toàn hệ sinh thái.

Các giao thức tích hợp, ví và nhà cung cấp cơ sở hạ tầng có thể phối hợp khi lỗ hổng ảnh hưởng đến nhiều hệ thống.

Lợi ích thứ sáu là sự rõ ràng pháp lý.

Chính sách và điều khoản safe harbor làm giảm sự không chắc chắn cho nhà nghiên cứu thiện chí.

Lợi ích thứ bảy là văn hóa bảo mật tốt hơn.

Dự án chào đón báo cáo có nhiều khả năng cải thiện liên tục hơn.

Rủi ro của việc công bố lỗ hổng kém

Rủi ro đầu tiên là đẩy nhanh khai thác.

Chi tiết công khai quá sớm có thể giúp kẻ tấn công đánh cắp tiền.

Rủi ro thứ hai là gây hại cho người dùng.

Phản hồi chậm có thể khiến người dùng tiếp tục gặp rủi ro.

Rủi ro thứ ba là làm nhà nghiên cứu thất vọng.

Nhà nghiên cứu có thể ngừng báo cáo nếu dự án phớt lờ hoặc đe dọa họ.

Rủi ro thứ tư là xung đột pháp lý.

Quy tắc không rõ ràng có thể tạo tranh chấp giữa whitehat và đội ngũ dự án.

Rủi ro thứ năm là tổn hại danh tiếng.

Người dùng có thể mất niềm tin nếu dự án che giấu lỗ hổng nghiêm trọng hoặc truyền thông kém.

Rủi ro thứ sáu là nhầm lẫn về quản trị.

DAO có thể khó hành động nhanh nếu không có quy trình công bố khẩn cấp.

Rủi ro thứ bảy là thiệt hại do tính kết hợp.

Lỗ hổng trong một giao thức có thể lan rủi ro qua các tích hợp trước khi các bên khác được cảnh báo.

Những hiểu lầm phổ biến về công bố lỗ hổng

Một hiểu lầm là công bố lỗ hổng có nghĩa phải công bố chi tiết khai thác ngay lập tức.

Việc công bố tốt thường bắt đầu riêng tư để đội ngũ bị ảnh hưởng có thể bảo vệ người dùng trước.

Một hiểu lầm khác là bug bounty tự động khiến dự án an toàn.

Bounty giúp nhận báo cáo nhưng không thay thế audit, giám sát, kiểm thử và phản hồi sự cố.

Hiểu lầm thứ ba là mọi hoạt động di chuyển tiền của whitehat đều an toàn.

Di chuyển tiền khi không được ủy quyền có thể tạo rủi ro pháp lý và đạo đức dù ý định tốt.

Hiểu lầm thứ tư là chỉ hợp đồng thông minh mới cần công bố.

Ví, frontend, API, hệ thống RPC, bridge, oracle, validator và hệ thống quản trị cũng có thể chứa lỗ hổng nghiêm trọng.

Hiểu lầm thứ năm là việc công bố kết thúc sau khi vá lỗi.

Người dùng vẫn có thể cần hướng dẫn di chuyển, hướng dẫn thu hồi quyền phê duyệt, cập nhật ví hoặc chi tiết postmortem.

Hiểu lầm thứ sáu là minh bạch công khai và phối hợp riêng tư là đối lập.

Quy trình trưởng thành có thể phối hợp riêng tư trước và công bố công khai sau khi biện pháp bảo vệ được áp dụng.

Công bố lỗ hổng theo cách hiểu đơn giản

Công bố lỗ hổng là báo cáo một lỗi bảo mật theo cách an toàn và có tổ chức.

Trong crypto, quy trình này bảo vệ tiền thật và người dùng thật.

Nhà nghiên cứu phát hiện điểm yếu.

Nhà nghiên cứu báo cáo qua kênh chính thức.

Dự án xác nhận vấn đề.

Dự án khắc phục hoặc giảm thiểu vấn đề.

Dự án truyền thông với người dùng khi an toàn để làm như vậy.

Nếu có bug bounty, nhà nghiên cứu có thể nhận phần thưởng.

Nếu có safe harbor, nhà nghiên cứu có thể có sự bảo vệ pháp lý rõ ràng hơn đối với hành động thiện chí.

Với người mới, quy tắc chính rất đơn giản.

Công bố lỗ hổng tốt giúp khắc phục lỗi trước khi kẻ tấn công biến chúng thành tổn thất.

FAQ

Công bố lỗ hổng là gì?

Công bố lỗ hổng là quy trình báo cáo, xác thực, khắc phục và truyền đạt thông tin về điểm yếu bảo mật trong phần mềm, hợp đồng thông minh, ví, giao thức hoặc cơ sở hạ tầng Web3.

Công bố lỗ hổng có phối hợp là gì?

Công bố lỗ hổng có phối hợp là quy trình có cấu trúc trong đó nhà nghiên cứu, nhà cung cấp, đội ngũ dự án và đôi khi điều phối viên cùng làm việc trước khi công bố công khai.

Vì sao công bố lỗ hổng quan trọng trong crypto?

Điều này quan trọng vì lỗ hổng crypto có thể ảnh hưởng trực tiếp đến tiền của người dùng, ngân quỹ giao thức, hợp đồng thông minh, bridge, ví và hệ thống quản trị.

Công bố lỗ hổng có giống bug bounty không?

Không. Công bố lỗ hổng là quy trình báo cáo và phản hồi, còn bug bounty là chương trình phần thưởng cho báo cáo bảo mật hợp lệ.

Báo cáo lỗ hổng crypto cần bao gồm gì?

Báo cáo cần nêu hệ thống bị ảnh hưởng, tác động, các bước tái tạo, bằng chứng proof of concept, chi tiết chain hoặc hợp đồng và khuyến nghị an toàn không gây hại cho người dùng.

Nhà nghiên cứu có nên công bố ngay lỗi hợp đồng thông minh không?

Thông thường là không, vì chi tiết khai thác công khai có thể giúp kẻ tấn công đánh cắp tiền trước khi dự án bảo vệ người dùng.

Công bố có trách nhiệm là gì?

Công bố có trách nhiệm thường là báo cáo riêng tư lỗ hổng và cho đội ngũ bị ảnh hưởng thời gian khắc phục trước khi chi tiết công khai được phát hành.

Công bố toàn bộ là gì?

Công bố toàn bộ là công khai chi tiết lỗ hổng, ngay lập tức hoặc sau một thời hạn.

Chính sách công bố lỗ hổng là gì?

Chính sách công bố lỗ hổng cho nhà nghiên cứu biết nội dung nào thuộc phạm vi, cách báo cáo vấn đề, hoạt động kiểm thử nào được phép và cách công bố sẽ được xử lý.

security.txt là gì?

Security.txt là định dạng tệp tiêu chuẩn hóa giúp tổ chức công bố thông tin liên hệ báo cáo lỗ hổng và hoạt động công bố.

Whitehat trong crypto là gì?

Whitehat là nhà nghiên cứu bảo mật cố gắng bảo vệ người dùng và hệ thống bằng cách báo cáo lỗ hổng hoặc hỗ trợ phòng thủ được ủy quyền.

Safe harbor là gì?

Safe harbor là ngôn ngữ chính sách hoặc pháp lý giúp nhà nghiên cứu thiện chí được bảo vệ rõ ràng hơn khi tuân theo quy tắc xác định.

Whitehat có thể di chuyển tiền của giao thức trong lúc bị khai thác không?

Họ chỉ nên làm vậy khi được ủy quyền rõ ràng bởi safe harbor, quy trình khẩn cấp hoặc quyền hợp lệ khác, vì di chuyển tiền không được ủy quyền có thể tạo rủi ro pháp lý.

Audit hợp đồng thông minh có thay thế công bố lỗ hổng không?

Không. Audit giảm rủi ro trước khi triển khai, còn công bố xử lý lỗ hổng được phát hiện sau khi triển khai hoặc ngoài phạm vi audit.

DAO có cần chính sách công bố lỗ hổng không?

Có. DAO cần kênh báo cáo riêng tư rõ ràng, quy tắc về thẩm quyền khẩn cấp, quy trình người ký và kỳ vọng công bố công khai.

Điều gì xảy ra sau khi lỗ hổng được khắc phục?

Dự án nên truyền đạt tác động đối với người dùng, công bố postmortem hoặc thông báo tư vấn khi an toàn, ghi nhận nhà nghiên cứu khi phù hợp và cải thiện biện pháp kiểm soát.

Công bố lỗ hổng có thể là lừa đảo không?

Có. Kẻ tấn công có thể gửi báo cáo giả, tệp độc hại, tin nhắn tống tiền hoặc liên kết phishing, nên dự án cần phân loại báo cáo an toàn.

Quy trình công bố lỗ hổng tốt nhất cho dự án Web3 là gì?

Quy trình tốt nhất bao gồm kênh báo cáo rõ ràng, phạm vi xác định, phân loại nhanh, chấm điểm mức độ nghiêm trọng, quy tắc bug bounty, ngôn ngữ safe harbor, phản hồi khẩn cấp và postmortem minh bạch.

Kết luận

Công bố lỗ hổng là quy trình bảo mật cốt lõi của ngành crypto.

Nó mang đến cho nhà nghiên cứu cách an toàn để báo cáo điểm yếu trước khi kẻ tấn công khai thác.

Nó cung cấp cho đội ngũ giao thức lộ trình có cấu trúc để xác nhận, khắc phục, giảm thiểu và truyền đạt các vấn đề bảo mật.

Nó bảo vệ người dùng tốt hơn và cung cấp thông tin tốt hơn về những hệ thống có thể đang nắm giữ tài sản của họ.

Trong Web3, công bố có tính cấp bách hơn nhiều môi trường phần mềm truyền thống vì mã có lỗ hổng có thể trực tiếp kiểm soát tiền đang hoạt động.

Lỗi hợp đồng thông minh, điểm yếu bridge, sự cố ví, lỗ hổng oracle, lỗi quản trị hoặc frontend bị xâm phạm có thể nhanh chóng gây tổn thất nghiêm trọng.

Đó là lý do dự án crypto cần chính sách công bố rõ ràng, đầu mối bảo mật, chương trình bug bounty, quy trình phân loại, kế hoạch khẩn cấp và thực hành postmortem.

DAO và giao thức DeFi cũng cần các kênh phối hợp riêng tư vì quản trị hoàn toàn công khai có thể để lộ chi tiết nguy hiểm trước khi bản sửa lỗi sẵn sàng.

Whitehat cần kênh báo cáo an toàn và sự rõ ràng pháp lý.

Người dùng cần truyền thông trung thực sau khi rủi ro được giảm bớt.

Đội ngũ bảo mật cần đủ thẩm quyền để hành động nhanh.

Công bố lỗ hổng không phải dấu hiệu dự án yếu.

Đó là dấu hiệu dự án đủ trưởng thành để xử lý thực tế bảo mật.

Nói đơn giản, dự án crypto tốt nhất không giả vờ rằng lỗ hổng sẽ không bao giờ xảy ra.

Họ chuẩn bị cho điều đó, chào đón báo cáo thiện chí, khắc phục nhanh và công bố rõ ràng khi người dùng được bảo vệ.