Disclosure Timing Gap

What is a disclosure timing gap, and how does it differ from the post-mortem report discussed earlier in this series?

When this series broke down the post-mortem report earlier, the evaluation focus was on the report's content quality — whether the timeline was concrete, whether root cause analysis was honest, whether remediation measures were verifiable. A disclosure timing gap addresses a more upstream time variable: how much time genuinely elapsed between the team internally knowing about a problem and publicly disclosing it. Even if a post-mortem report's content is written in extreme detail and honesty, if the team only chose to disclose a month after the incident happened, during that month-long window, users were actually bearing risk under information asymmetry the entire time without knowing it at all.

This means evaluating a team's transparency can't just look at whether the final report is well-written — it needs to push one layer further back: is the gap between the problem being discovered and being disclosed itself reasonable?

Why does a disclosure timing gap exist — why doesn't a team publicly disclose a problem the instant they discover it?

A disclosure timing gap existing doesn't always mean the team deliberately concealed anything — some delay has relatively reasonable technical and legal considerations: after discovering a vulnerability, a team might need time to first complete a patch and confirm it works before disclosing publicly, avoiding a situation where publicizing vulnerability details before the fix is done gives other attackers a chance to exploit it; if an incident involves user asset loss, the team may also need time to clarify the scope of the loss and specifically who's affected before giving an accurate disclosure, rather than rushing out an incomplete preliminary statement that could cause unnecessary panic.

But a disclosure timing gap can also reflect less legitimate considerations — a team might assess that disclosing the problem would hurt its brand image or fundraising, and choose to delay as long as possible; or the team internally might have a genuine gap in judgment or decision-making delay about whether this problem is even serious enough to warrant public disclosure. This means a disclosure timing gap is itself a neutral time metric that needs to be assessed together with the specific reason for the delay, rather than simply judging a team good or bad purely by the length of time.

開示タイムラグは実際どう評価すればよく、一般ユーザーはこのギャップを自分で検証する方法がありますか？

開示タイムラグを検証するには、2つの時点を照合する必要がある：問題が実際に発生した（または発見された）時点と、その問題が公開開示された時点である。前者は通常オンチェーンデータ（異常な取引の実際の発生タイムスタンプなど）やサードパーティのセキュリティ研究コミュニティの独立した分析を通じて確認する必要があり、後者は比較的検証しやすく、通常はチームが発表や事後検証レポートを公開した日付である。この2つの時点を並べて比較すれば、開示タイムラグの具体的な長さがわかる。

より細かい評価では、さらにこの時間差の期間中、チームがユーザーのリスクを低減するための何らかの中間的な行動を取っていたか（まだ完全に詳細を公開していなくても、影響を受けた機能を既に一時停止していたか、一部の高リスクユーザーに非公式に通知していたかなど）を確認することもできる。この「まだ公開していないが、既にユーザーを保護するために行動している」というやり方は、「全く行動を取らず、単に沈黙して待つだけ」というやり方と比べて、たとえ最終的な開示タイムラグの長さが同じくらいであっても、反映されるチームの姿勢は全く異なる。

開示タイムラグは一般ユーザーにどのような実際の影響を与えますか？DeFAI製品の評価と継続的な監視にどう応用すればいいですか？

利用しているDeFAI製品が過去にセキュリティインシデントを起こしたことがある場合、開示タイムラグを検証することで、最終的なレポートがどれだけ詳細に書かれているかだけでなく、このチームが問題に実際どれだけ速く対応したかをより正確に判断する助けになる。開示タイムラグが極めて短く、合理的な説明を提供できるチーム（「私たちはまず2日かけて緊急パッチを完了させ、安全を確認してから直ちに公開しました」など）は、通常、開示タイムラグが数週間に及び、何の説明も提供しないチームよりも信頼できる。

実際に応用する際、これは継続的に監視する価値のある環節でもある——利用している製品について、コミュニティやサードパーティの監視サービスが「異常が疑われるが公式にはまだ説明がない」というシグナルを発したことがある場合、公式の対応を待っているその時間自体が、あなたが現在経験している開示タイムラグである。警戒を強め、公式の正式な説明が出る前に、エクスポージャーを減らす行動（使用の一時停止、承認の取り消しなど）を先に取るべきかを検討する価値があり、公式発表を受動的に待ち、対応の主導権を自分がコントロールできない時間差に完全に委ねるのではない。