アカウント名:
パスワード:
いくらベンダーが無視できるリスクと判断したとはいえ、ゼロデイ脆弱性を生み出すことになりかねないと思うのですが、こういうのを見つけ出す人にとっては、誰かがひどい目に遭うリスクよりも功名心のほうが上なんでしょうか…。
脆弱性が一定の猶予期間の後に公表される仕組みが無い場合、公にバレるまで修正しなくても良いと言う事になってしまうので潜在的なリスクが高まります。脆弱性が公にならなくても闇市場で未公開の脆弱性情報が取引される可能性があり、サイバーテロ、あるいはサイバー戦争の温床になりますので脆弱性は速やかに修正され、公表される事が望ましいのです。
閾値というか「やるやる詐欺」の問題もあるから難しいけど、「開発元が修正しようとしてるけど、影響調査やパッチ配布のサイクルに間に合わない」場合は、少し公開を延期するシステムは必要だと思うんだよね。
脆弱性の対策はユーザー保護のためなんだから、ユーザーを危険に晒すやり方は最小限になるよう配慮されるべきだと思う。
少し延期して、結局修正前に開示される事例が出ることに変わりはない。それに脆弱性は製品のリリース時には生まれているわけだから、ブラックマーケットで取引されていれば、少し延ばすことがユーザーを救うとは限らない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
脆弱性をわざわざ公開するやり方って (スコア:0)
いくらベンダーが無視できるリスクと判断したとはいえ、ゼロデイ脆弱性を生み出すことになりかねないと思うのですが、こういうのを見つけ出す人にとっては、誰かがひどい目に遭うリスクよりも功名心のほうが上なんでしょうか…。
Re: (スコア:0)
脆弱性が一定の猶予期間の後に公表される仕組みが無い場合、公にバレるまで修正しなくても良いと言う事になってしまうので潜在的なリスクが高まります。
脆弱性が公にならなくても闇市場で未公開の脆弱性情報が取引される可能性があり、サイバーテロ、あるいはサイバー戦争の温床になりますので脆弱性は速やかに修正され、公表される事が望ましいのです。
Re: (スコア:0)
閾値というか「やるやる詐欺」の問題もあるから難しいけど、「開発元が修正しようとしてるけど、影響調査やパッチ配布のサイクルに間に合わない」場合は、少し公開を延期するシステムは必要だと思うんだよね。
脆弱性の対策はユーザー保護のためなんだから、ユーザーを危険に晒すやり方は最小限になるよう配慮されるべきだと思う。
Re:脆弱性をわざわざ公開するやり方って (スコア:0)
少し延期して、結局修正前に開示される事例が出ることに変わりはない。
それに脆弱性は製品のリリース時には生まれているわけだから、ブラックマーケットで取引されていれば、少し延ばすことがユーザーを救うとは限らない。