KENSAI 製品アップデート: 証拠優先の公開と提出規律で same-day サーフェスを引き締め

KENSAI は 4 月 16 日の運用をさらに引き締め、受理確率の判断、提出時の動画証拠の必須化、言語別ブログインデックスの徹底によって、same-day 公開を必要な全言語で揃えるようにしました。

今日リリースした内容

今日の作業では二つのシステムを同時に引き締めました。KENSAI が bug bounty finding を提出可能と判断する基準と、公開ブログがその日の公開完了をどう証明するかです。結果はシンプルで、見せかけが減りました。明確な受理確率と動画証拠がなければ finding は本当に ready とは言えず、ローカル HTML、ローカル JSON、overview ページが同じ事実を示していなければ daily post も本当に published とは言えません。

厳しく聞こえますが、これが正しい基準です。弱いガイダンスは提出サイクルを無駄にし、部分的な公開はユーザーやクローラが古い面に当たるまで気づかれない静かなドリフトを生みます。

1) 提出ガイダンスは受理確率から始め、必要なら送らない判断を先に出す

提出ガイダンスは、まず一番言いにくい部分から始める必要があります。受理確率が低い、scope の根拠が弱い、あるいは informative や out of scope で終わる可能性が高いなら、推奨ははっきり送らないと書くべきです。本来キューを出るべきでないレポートを磨き続けるより、その方がはるかに健全です。

これでキューはより正直になります。時間も信頼も限られているなら、楽観より証拠と受理確率を優先すべきであり、セキュリティのワークフローはまさにそう動くべきです。

2) 動画証拠が ready の定義に入った

二つ目の引き締めは証拠です。今やテキストだけの write-up では finding を submission-ready と呼べません。攻撃経路そのものが重要なら、挙動を明確に示し、レビュー側の懐疑にも耐える動画証拠が提出パッケージに必要です。

これはチームを物語の誇張ではなく再現可能な証拠へ押し戻します。同時に、面白いシグナルと本当に提出可能なレポートの境界もより明確になります。

3) same-day 公開は、ローカル HTML、ローカル JSON、overview ページが一緒に動く時だけ誠実になる

公開側でも同じルールです。内部の意図より公開された証拠が勝ちます。各言語は自分の JSON インデックスにだけ存在すべきで、英語インデックスに非英語エントリを混ぜてはいけません。さらに locale ファイルが入った後は overview ページを再生成する必要があります。

それで初めて same-day サーフェスが誠実になります。レンダリング済み HTML が存在し、正しい言語別 JSON がその記事を指し、各言語 overview が英語とまったく同じ 4 月 16 日セットを表示している時だけ、その日は公開済みと数えられます。

なぜ重要か

これこそ守る価値のある製品挙動です。強い主張を偽装しにくくする時、システムは信頼を獲得します。Submission readiness は証拠を意味し、publication は公開面で見える整合性を意味すべきです。

内部状態がいつかユーザーの見える状態に追いつくことを願うより、ずっと良い運用ループです。