漏洞揭露

什麼是漏洞揭露？

漏洞揭露是指針對軟體、智能合約、錢包、協議、基礎設施或 Web3 應用程式中的安全弱點，進行通報、驗證、修復及公開溝通的流程。

在加密貨幣領域，漏洞揭露尤其重要，因為單一 Bug 就可能使使用者資金、協議金庫、跨鏈橋、驗證者、治理合約、錢包、NFT 或 DeFi 倉位面臨風險。

NIST 聯邦漏洞揭露指南將漏洞揭露描述為用於通報、評估及管理漏洞揭露的框架。

CISA 協調式漏洞揭露計畫將協調式漏洞揭露描述為保護關鍵基礎設施及改善資安的一環。

簡單來說，漏洞揭露是指在攻擊者能利用安全缺陷，或使用者遭受可避免的損害之前，將問題告知正確的人員。

良好的揭露流程可為安全研究人員提供安全的通報管道。

它讓專案團隊有時間確認問題、準備修復措施、保護使用者並清楚溝通。

它也會在問題處理後，向大眾提供足夠資訊以理解風險。

漏洞揭露為何在加密貨幣領域重要

漏洞揭露在加密貨幣領域很重要，因為區塊鏈系統通常直接透過程式碼管理真實金融價值。

一般 Web 應用程式 Bug 可能洩漏資料或中斷服務。

智能合約 Bug 則可能造成即時資產竊取、無限鑄造、預言機操縱、治理接管、跨鏈橋資金遭掏空、強制平倉濫用或資金永久鎖定。

DeFiLlama 駭客攻擊資料庫追蹤 DeFi 駭客攻擊、跨鏈橋、協議邏輯失敗及其他加密貨幣漏洞利用事件中，數十億美元的損失。

這顯示加密貨幣漏洞揭露不只是技術禮貌。

它是一項金融安全流程。

當白帽駭客負責任地通報 Bug，協議可能在攻擊者發現前修復問題。

當協議忽略通報或缺乏揭露管道時，研究人員可能不知道該如何安全通報。

若揭露過早，攻擊者可能在使用者受到保護前利用弱點。

若揭露過晚，使用者可能在不了解危險的情況下持續與具風險的程式碼互動。

目標是在維持透明度的同時降低損害。

漏洞揭露與協調式漏洞揭露的差異

漏洞揭露是通報及溝通安全缺陷的廣義行為。

協調式漏洞揭露（Coordinated Vulnerability Disclosure，通常簡稱 CVD）是一種結構化流程，研究人員、供應商、專案團隊、受影響方及有時候的協調者會在公開揭露前共同合作。

CERT 協調式漏洞揭露指南將 CVD 說明為涉及發現者、通報者、供應商及協調者的流程。

在 Web3 中，協調式揭露可能涉及安全研究人員、協議核心團隊、多重簽名者、DAO 代表、稽核人員、錢包開發者、跨鏈橋營運者、基礎設施提供者或漏洞賞金平台。

協調很重要，因為加密貨幣系統通常具有可組合性。

一個協議中的漏洞可能影響與其整合的其他協議。

錢包函式庫中的 Bug 可能影響許多應用程式。

跨鏈橋中的漏洞可能影響多條鏈上的資產。

揭露流程必須識別誰需要知道、何時需要知道，以及如何在不增加攻擊風險下分享資訊。

漏洞揭露與漏洞賞金的差異

漏洞揭露與漏洞賞金有關聯，但並非同一件事。

漏洞揭露是通報及處理安全弱點的流程。

漏洞賞金是針對有效漏洞報告向研究人員支付獎勵的計畫。

專案可以有漏洞揭露政策，但不支付獎勵。

專案也可以有漏洞賞金計畫，其中包含嚴格的範圍、嚴重程度規則、獎勵區間、通報要求及揭露限制。

Ethereum Foundation 漏洞賞金計畫展示大型協議生態系統如何定義通報管道、範圍及安全研究期望。

漏洞賞金可鼓勵研究人員通報問題，而非私下出售漏洞或加以利用。

不過，賞金不會自動讓專案變得安全。

專案仍需要分類處理、工程回應、修補程式部署、使用者溝通及事件規劃。

漏洞賞金是激勵層，而漏洞揭露則是完整安全工作流程。

負責任揭露與完整揭露

負責任揭露通常是指私下向受影響團隊通報漏洞，並在公開細節前給予其修復時間。

完整揭露是指公開分享漏洞細節，有時立即公開，有時則在期限後公開。

在加密貨幣領域，如果 Bug 影響持有使用者資金的運作中智能合約，立即完整揭露可能極其危險。

攻擊者可複製報告內容，並在修復措施部署前利用協議。

不過，無限期私下揭露也可能有害，因為專案延遲行動時，使用者可能持續曝露於風險中。

因此，協調式揭露通常會採用時程、升級規則及公開揭露期望。

Ethereum 公開揭露儲存庫指出，Ethereum Foundation 目標是在其漏洞賞金計畫收到 Bug 報告後 90 天內公開揭露，但會在情況需要時調整時機。

明確時程有助於平衡使用者保護、研究人員公平性與公共透明度。

漏洞揭露政策

漏洞揭露政策會告知研究人員如何安全通報安全問題。

政策應說明哪些系統屬於範圍內。

它應說明允許哪些測試。

它應說明禁止哪些測試。

它應列出官方通報管道。

它應描述預期回應時間。

若有提供，應說明安全港條款。

它應描述公開揭露的處理方式。

它應說明是否提供獎勵。

它應告知研究人員如何保護使用者資料及避免造成損害。

ISO/IEC 29147:2018 標準頁面指出，漏洞揭露為供應商揭露產品及服務漏洞提供要求與建議。

對加密貨幣專案而言，揭露政策還應說明智能合約範圍、前端範圍、預言機範圍、跨鏈橋範圍、錢包範圍、治理範圍及金庫緊急程序。

security.txt 與通報管道

安全研究人員往往難以找到正確的漏洞通報聯絡人。

這正是 security.txt 存在的原因。

RFC 9116將 security.txt 定義為一種機器可讀格式，協助組織說明其漏洞揭露實務。

security.txt 檔案可列出聯絡資訊、加密金鑰、政策連結、招募連結、致謝資訊及揭露偏好。

對加密貨幣專案而言，security.txt 可協助白帽駭客迅速找到正確通報途徑。

這很重要，因為面對即時漏洞利用風險時，每一小時都可能很關鍵。

專案不應強迫研究人員在隨機社群管道中尋找、私訊創辦人，或猜測哪個電子郵件地址是真的。

清楚的通報管道可降低混亂並提升回應速度。

面臨重大風險價值的 Web3 專案，應在官方文件、網站頁尾、儲存庫安全政策及 security.txt 檔案中公布安全聯絡方式。

需要揭露的常見加密貨幣漏洞

加密貨幣漏洞揭露可能涉及許多類型的弱點。

智能合約 Bug 可能包括重入攻擊、存取控制失敗、價格預言機操縱、算術錯誤、商業邏輯錯誤、未檢查的外部呼叫及可升級性缺陷。

OWASP Smart Contract Top 10 2026列出主要 Web3 智能合約風險，包括存取控制漏洞、商業邏輯漏洞、價格預言機操縱、閃電貸攻擊、未檢查的外部呼叫、重入攻擊、整數溢位與下溢，以及代理升級性問題。

錢包漏洞可能涉及不安全簽名、助記詞曝露、交易模擬失敗、惡意 dApp 提示或不安全的金鑰儲存。

跨鏈橋漏洞可能涉及驗證者遭入侵、訊息驗證失敗、重放攻擊、最終性檢查不足或託管弱點。

前端漏洞可能涉及 DNS 劫持、惡意 JavaScript 注入、假合約地址、遭入侵的套件依賴或掏空錢包的 UI 變更。

基礎設施漏洞可能涉及 RPC Bug、索引器錯誤、驗證者用戶端問題、API 曝露、私鑰管理或雲端設定錯誤。

良好的揭露計畫會定義哪些問題屬於範圍內，以及應如何通報。

智能合約漏洞揭露

智能合約漏洞揭露尤其敏感，因為智能合約可能公開、不可變更，且直接連結資金。

發現智能合約 Bug 的研究人員應避免為獲利而加以利用。

研究人員應避免移動使用者資金，除非存在明確授權的安全港或緊急救援程序。

研究人員應蒐集足以證明問題的證據，同時避免造成不必要損害。

協議團隊應迅速確認收到報告。

團隊應在安全環境中重現問題。

團隊應評估受影響合約、受影響資金、整合項目、升級路徑及治理控制。

團隊應決定是否暫停、升級、遷移、通知整合方或採取緊急行動。

在保護措施就緒後，團隊應在安全時發布清楚的事後檢討報告或公告。

智能合約揭露必須審慎，因為一旦漏洞利用細節公開，攻擊者便可迅速行動。

Web3 中的漏洞賞金平台

漏洞賞金平台有助於管理漏洞提交、分類處理、獎勵、嚴重程度評分、研究人員溝通及計畫範圍。

Immunefi 平台稱其使用大量區塊鏈漏洞利用、Bug 報告及修復資料，以支援鏈上安全防禦。

Immunefi 於 2026 年針對重大加密貨幣漏洞的研究指出，加密貨幣中很大比例的上線後重大漏洞是透過其平台揭露。

漏洞賞金平台可協助專案以結構化方式接收報告。

它也可協助研究人員了解應在哪裡提交、哪些內容符合資格，以及如何計算獎勵。

不過，平台不會免除專案團隊的責任。

專案仍需要工程師、安全負責人、緊急簽署者、法律審查及溝通計畫。

缺乏回應能力的賞金收件匣可能使研究人員受挫，並增加使用者風險。

嚴謹的 Web3 漏洞賞金計畫應與面臨的風險價值相符。

嚴重程度與影響評估

嚴重程度評估決定漏洞有多危險。

在加密貨幣領域，嚴重程度應聚焦於現實影響，而不僅是技術上的巧妙程度。

重大漏洞可能允許直接竊取、資金永久損失、無限鑄造、治理接管、跨鏈橋遭入侵、驗證者遭削減質押或協議關閉。

高嚴重程度問題可能需要特定條件，但仍會威脅大量資金或重要權限。

中嚴重程度問題可能造成有限損失、阻斷服務、錯誤會計處理或受限的權限提升。

低嚴重程度問題可能是實際影響有限的輕微弱點。

良好的嚴重程度評分應考量面臨風險的資產、漏洞利用複雜度、所需權限、受影響使用者、可組合性、可升級性，以及攻擊者是否能在一筆鏈上交易中利用該問題。

嚴重程度也應考慮 Bug 是否已知、已被利用，或在公開程式碼中可見。

強大的揭露計畫會說明嚴重程度如何對應回應優先順序及賞金範圍。

揭露時程

揭露時程定義報告何時被確認、何時進行分類處理、預計何時修復，以及何時可公開揭露。

傳統軟體揭露通常依政策採用 60 或 90 天等時程。

若運作中的資金面臨風險，加密貨幣時程可能更短。

智能合約漏洞利用可能需要在數分鐘或數小時內進行緊急回應。

協議升級可能需要多重簽名操作、治理投票、時間鎖延遲、流動性遷移或使用者提領期間。

這使 Web3 中的揭露時程更加複雜。

若在時間鎖結束前揭露，攻擊者可能在修復執行前利用已知問題。

若揭露延遲太久，使用者可能在不知情下繼續存入具漏洞的合約。

良好的政策會說明緊急例外、禁言期望、研究人員更新及公開揭露規則。

明確時程可減少研究人員與專案之間的衝突。

白帽駭客與安全港

白帽駭客是旨在協助保護使用者及系統，而非惡意利用系統的安全研究人員。

在加密貨幣領域，由於鏈上資金可能快速遭掏空，白帽駭客在進行中的漏洞利用事件中有時會面臨艱難抉擇。

某些情況可能需要緊急救援行動，但若未明確授權，這些行動可能帶來法律與倫理風險。

SEAL Whitehat Safe Harbor 架構說明一套法律與技術框架，讓協議可預先授權白帽駭客在漏洞利用進行中介入、救援資金，並依既定規則返還資金。

安全港條款有助於降低具道德研究人員的不確定性。

它也協助協議在危機發生前界定允許的緊急行動。

若沒有安全港，為保護使用者而移動資金的白帽駭客仍可能面臨法律風險。

有了明確安全港，協議可預先設定界線、返還規則、通報要求及法律保護。

法律與倫理風險

漏洞揭露可能為研究人員與專案雙方帶來法律風險。

若測試未獲授權，研究人員可能違反法律、服務條款、電腦濫用規則、隱私規則或反規避規則。

專案若威脅研究人員、忽略報告、未警告使用者或不當處理個人資料，也可能產生風險。

這正是揭露政策應明確定義授權測試的原因。

除非明確授權，研究人員應避免破壞性測試、資料竊取、阻斷服務、社交工程及真實資金移動。

研究人員應迅速通報，並將證據維持在最少必要範圍。

專案應尊重地回應，避免將善意報告視為攻擊。

加密貨幣帶來額外法律複雜性，因為資金可跨境移動，且協議可能由 DAO 或基金會治理。

明確政策無法消除所有法律風險，但可減少混亂並提升信任。

白帽駭客的法律保護應在漏洞成為緊急事件前規劃。

DAO 的漏洞揭露

DAO 需要特殊的漏洞揭露流程，因為其決策可能公開、緩慢且受治理驅動。

官方Ethereum DAO 指南將 DAO 描述為由成員共同擁有及管理的網路原生組織。

公開治理很有價值，但公開討論尚未修補的重大漏洞可能很危險。

DAO 可能需要私人安全委員會、緊急多重簽名、漏洞賞金委員會或存取受限的揭露小組。

此小組可在完整公開討論前，先分類處理敏感報告。

在使用者受到保護後，DAO 仍可發布事後檢討及問責報告。

核心挑戰是平衡透明度與操作安全。

如果每項修復都需要公開提案，攻擊者可能在治理完成前加以利用。

如果每項緊急行動都是祕密的，使用者可能失去信任。

成熟的 DAO 會在危機前定義緊急權力、揭露規則、簽署者職責及公開報告期望。

DeFi 協議的漏洞揭露

DeFi 協議需要快速的揭露回應，因為資產可能在鏈上直接遭掏空或操縱。

官方Ethereum DeFi 指南說明，去中心化金融透過公開區塊鏈及智能合約提供金融產品與服務。

DeFi 漏洞可能影響流動性池、借貸市場、抵押品計算、vault 份額、預言機、強制平倉邏輯、獎勵計算、質押合約或治理控制。

可組合性使情況更困難，因為一個具漏洞的協議可能整合至許多其他協議。

DeFi 揭露回應應迅速識別下游整合。

它應評估是否應暫停存入。

它應決定是否需要緊急提領、合約升級、預言機變更或流動性遷移。

在可行時，它應與稽核人員及安全合作夥伴協調。

它應提供足以保護使用者的資訊，但避免過早揭露漏洞利用指引。

修復後，協議應清楚說明根本原因與對使用者的影響。

錢包與 Web3 應用程式的漏洞揭露

即使智能合約未損壞，錢包與 Web3 應用程式漏洞仍可能傷害使用者。

錢包 Bug 可能顯示錯誤交易細節。

dApp 前端 Bug 可能將使用者導向錯誤合約。

錢包連線 Bug 可能批准錯誤鏈或方法。

交易模擬 Bug 可能隱藏危險資產移動。

瀏覽器擴充功能 Bug 可能曝露敏感資料。

遭入侵的依賴項可能注入掏空錢包的程式碼。

官方Ethereum 安全指南說明，使用者必須保護錢包存取權、私鑰及恢復助記詞。

錢包漏洞揭露應極為審慎處理，因為使用者仰賴錢包介面理解自己正在簽署的內容。

錢包團隊應具備清楚的安全聯絡方式、快速更新流程、簽名風險溝通計畫及使用者警示系統。

若前端可能遭入侵，Web3 應用程式不應認為合約稽核已足夠。

公開揭露與事後檢討

公開揭露應協助使用者了解發生什麼事、哪些部分受影響、修復了什麼，以及他們需要採取什麼行動。

良好的事後檢討會說明漏洞類型。

它會說明時程。

它會說明受影響的合約或系統。

它會說明資金是否面臨風險或已損失。

它會說明修復措施。

它會說明使用者接下來應做什麼。

它會說明團隊將改善什麼。

在適當且獲允許時，它會感謝研究人員。

它會避免在使用者受到保護前發布可直接用於漏洞利用的細節。

公開揭露很重要，因為加密貨幣使用者通常需要決定是否提領、遷移、撤銷授權、更新錢包、避開前端或監控地址。

沉默可能造成傷害，因為它讓使用者只能猜測。

即使漏洞嚴重，清楚揭露也能建立信任。

研究人員應在報告中包含什麼

強大的漏洞報告應清楚、符合事實且可重現。

它應包含受影響專案、元件、合約、提交版本、端點、錢包版本、鏈或地址。

它應以淺白語言描述漏洞。

它應說明影響。

它應包含不會傷害真實使用者的概念驗證步驟。

它應包含預期行為與實際行為。

若有幫助，它應包含螢幕截圖、日誌、測試交易、本地測試結果或程式碼片段。

它應說明資金是否面臨風險。

它應說明該問題在主網上是否看似可被利用。

它應避免不必要的祕密、使用者資料及實際漏洞利用。

良好的報告可協助團隊迅速重現並修復問題。

專案收到報告後應採取的行動

專案應迅速確認收到報告。

它應指派安全負責人。

它應在安全環境中驗證研究人員的主張。

它應評估嚴重程度與受影響系統。

它應保存證據。

在保護計畫存在前，它應避免公開討論。

它應準備修復或緩解措施。

必要時，它應與受影響整合方協調。

適用時，它應依漏洞賞金政策支付獎勵。

它應尊重地與研究人員溝通。

在使用者受到保護時，它應發布揭露內容或事後檢討。

忽略報告的專案會為使用者帶來風險，並損害與研究人員之間的信任。

漏洞揭露的優點

漏洞揭露的第一項優點是保護使用者。

安全缺陷可在攻擊者利用前得到修復。

第二項優點是研究人員信任。

當流程清楚且公平時，白帽駭客更可能通報問題。

第三項優點是協議韌性。

專案可從弱點中學習並改善其安全架構。

第四項優點是透明度。

問題解決後，使用者可了解真實風險。

第五項優點是生態系統安全性。

當漏洞影響多個系統時，整合協議、錢包與基礎設施提供者可以協調。

第六項優點是法律清晰度。

政策與安全港條款可降低善意研究人員的不確定性。

第七項優點是更佳的安全文化。

歡迎通報的專案更可能持續改進。

不良漏洞揭露的風險

第一項風險是加速漏洞利用。

過早發布公開細節可能協助攻擊者竊取資金。

第二項風險是使用者損害。

延遲回應可能讓使用者持續曝露於風險中。

第三項風險是研究人員受挫。

如果專案忽略或威脅研究人員，研究人員可能不再通報。

第四項風險是法律衝突。

不清楚的規則可能引發白帽駭客與專案團隊之間的爭議。

第五項風險是聲譽損害。

如果專案隱瞞重大漏洞或溝通不佳，使用者可能失去信任。

第六項風險是治理混亂。

若不存在緊急揭露流程，DAO 可能難以迅速行動。

第七項風險是可組合性損害。

一個協議的漏洞可能在其他方收到警告前，透過整合傳播風險。

關於漏洞揭露的常見誤解

其中一項誤解是，漏洞揭露代表立即發布漏洞利用細節。

良好的揭露通常會先私下進行，讓受影響團隊先保護使用者。

另一項誤解是，有漏洞賞金就自動代表專案安全。

賞金有助於接收報告，但無法取代稽核、監控、測試及事件回應。

第三項誤解是，所有白帽駭客的資金移動都是安全的。

即使出於善意，未經授權移動資金仍可能帶來法律與倫理風險。

第四項誤解是，只有智能合約需要揭露。

錢包、前端、API、RPC 系統、跨鏈橋、預言機、驗證者及治理系統也可能存在嚴重漏洞。

第五項誤解是，修補程式發布後揭露就結束了。

使用者可能仍需要遷移指引、撤銷授權指引、錢包更新或事後檢討細節。

第六項誤解是，公開透明與私下協調彼此對立。

成熟流程可先私下協調，再於保護措施就緒後公開揭露。

簡單理解漏洞揭露

漏洞揭露是指以安全且有組織的方式通報安全 Bug。

在加密貨幣領域，此流程保護真實資金及真實使用者。

研究人員發現弱點。

研究人員透過官方管道通報。

專案確認問題。

專案修復或緩解問題。

專案在安全時與使用者溝通。

若存在漏洞賞金，研究人員可能獲得獎勵。

若存在安全港，研究人員的善意行動可能獲得更明確的法律保護。

對新手而言，主要規則很簡單。

良好的漏洞揭露有助於在攻擊者將 Bug 轉化為損失前修復問題。

常見問題

什麼是漏洞揭露？

漏洞揭露是通報、驗證、修復及溝通軟體、智能合約、錢包、協議或 Web3 基礎設施中安全弱點的流程。

什麼是協調式漏洞揭露？

協調式漏洞揭露是一種結構化流程，研究人員、供應商、專案團隊及有時候的協調者會在公開揭露前共同合作。

為何漏洞揭露在加密貨幣領域重要？

這很重要，因為加密貨幣漏洞可直接影響使用者資金、協議金庫、智能合約、跨鏈橋、錢包及治理系統。

漏洞揭露與漏洞賞金相同嗎？

不同。漏洞揭露是通報與回應流程，而漏洞賞金是針對有效安全報告的獎勵計畫。

加密貨幣漏洞報告應包含什麼？

應包含受影響系統、影響、重現步驟、概念驗證證據、鏈或合約細節，以及不傷害使用者的安全建議。

研究人員應立即公開揭露智能合約 Bug 嗎？

通常不應，因為公開漏洞利用細節可能協助攻擊者在專案保護使用者前竊取資金。

什麼是負責任揭露？

負責任揭露通常是指私下通報漏洞，並在公開細節前給予受影響團隊時間修復。

什麼是完整揭露？

完整揭露是指公開分享漏洞細節，可能立即公開，也可能在期限後公開。

什麼是漏洞揭露政策？

漏洞揭露政策會告知研究人員哪些內容屬於範圍內、如何通報問題、允許哪些測試，以及如何處理揭露。

什麼是 security.txt？

Security.txt 是標準化檔案格式，可協助組織公布漏洞通報聯絡資訊及揭露實務。

加密貨幣中的白帽駭客是什麼？

白帽駭客是透過通報漏洞或協助經授權防禦，嘗試保護使用者與系統的安全研究人員。

什麼是安全港？

安全港是政策或法律條款，當善意研究人員遵循既定規則時，為其提供更明確的保護。

白帽駭客可以在漏洞利用期間移動協議資金嗎？

只有在安全港、緊急程序或其他有效授權明確允許時才應這麼做，因為未經授權的資金移動可能帶來法律風險。

智能合約稽核可以取代漏洞揭露嗎？

不可以。稽核可降低部署前風險，而漏洞揭露則處理部署後或稽核窗口外發現的漏洞。

DAO 需要漏洞揭露政策嗎？

需要。DAO 需要清楚的私下通報途徑、緊急權限規則、簽署者程序及公開揭露期望。

漏洞修復後會發生什麼？

專案應溝通對使用者的影響、在安全時發布事後檢討或公告、於適當時感謝研究人員，並改善控制措施。

漏洞揭露可能是詐騙嗎？

可能。攻擊者可能傳送假報告、惡意檔案、勒索訊息或網路釣魚連結，因此專案應安全地分類處理報告。

Web3 專案最佳的漏洞揭露流程是什麼？

最佳流程包含清楚的通報管道、定義範圍、快速分類處理、嚴重程度評分、漏洞賞金規則、安全港條款、緊急回應及透明的事後檢討。

結論

漏洞揭露是加密貨幣產業的核心安全流程。

它讓研究人員能在攻擊者利用弱點前安全通報。

它為協議團隊提供結構化途徑，以確認、修復、緩解及溝通安全問題。

它為使用者提供更多保護及更好的系統資訊，而這些系統可能持有其資產。

在 Web3 中，揭露比許多傳統軟體環境更為緊急，因為具漏洞的程式碼可能直接控制運作中的資金。

智能合約 Bug、跨鏈橋缺陷、錢包問題、預言機弱點、治理 Bug 或前端遭入侵，都可能非常快速地造成嚴重損失。

這就是加密貨幣專案需要清楚的揭露政策、安全聯絡方式、漏洞賞金計畫、分類處理工作流程、緊急計畫及事後檢討實務的原因。

DAO 與 DeFi 協議也需要私下協調途徑，因為完全公開的治理可能在修復準備完成前暴露危險細節。

白帽駭客需要安全的通報管道與法律清晰度。

在風險降低後，使用者需要誠實溝通。

安全團隊需要足夠權限迅速採取行動。

漏洞揭露不是專案薄弱的象徵。

它是專案已成熟到足以面對安全現實的象徵。

簡單來說，最好的加密貨幣專案不會假裝漏洞永遠不會發生。

它們會為漏洞做好準備、歡迎善意報告、迅速修復問題，並在使用者受到保護時清楚揭露。