
「90日間の脆弱(ぜいじゃく)性開示ルール」はGoogleの脆弱性調査チーム「Project Zero」が定めた「脆弱性発見から90日以内に修正パッチを公開できなければ詳細を公表する」というもので、セキュリティ業界で標準とされることがあります。しかし、セキュリティ研究者のヒマスヌ・アナンド氏は、このルールがAIの台頭やソフトウェアの複雑化などにより事実上崩壊しつつあると指摘しています。
90日間の脆弱性開示ポリシーはもはや意味をなさないという指摘、AIがバグ発見とエクスプロイト開発を爆速に - GIGAZINE
アナンド氏によると、90日の猶予期間を与えるルールはバグ発見報告がまれで、さらに発見されたバグを利用して攻撃するエクスプロイトの開発に時間がかかっていた時代に作られたものであるそうです。例えば2019年頃に重大なバグを発見した場合、同じバグを発見した人が他にもいることはごく珍しく、企業に報告すれば90日の猶予期間内にパッチが適用されるより早くそのバグが悪用される可能性は高くありませんでした。
90日間の脆弱性開示ポリシーはもはや意味をなさないという指摘、AIがバグ発見とエクスプロイト開発を爆速に - GIGAZINE
しかし、現代では高度に発達したコーディングAIによりバグ発見もエクスプロイト開発もごく短時間で可能になっています。重大なバグを報告したら全く同じ報告が数十件届いていたというケースもしばしばあり、善意の報告者だけが同じようにバグを発見していたわけではないと考えると、90日の猶予期間は「悪意ある発見者がバグを悪用できる90日の先行期間」となっているとアナンド氏は指摘しました。
90日間の脆弱性開示ポリシーはもはや意味をなさないという指摘、AIがバグ発見とエクスプロイト開発を爆速に - GIGAZINE
さらに、同じ理由で毎月セキュリティアップデートを実施する「月次パッチサイクル」も死んでいると考えられるとのこと。脆弱性の発見から最大で30日間修正までの猶予期間を与える月次パッチサイクルは、攻撃者がエクスプロイトをリリースするサイクルがそれより遅いという前提に基づいていました。
90日間の脆弱性開示ポリシーはもはや意味をなさないという指摘、AIがバグ発見とエクスプロイト開発を爆速に - GIGAZINE
アナンド氏は、時代遅れの90日ルールではなく、「あらゆるバグを優先度最高の『P0』として扱い、ただちにパッチを適用する」という必要があると述べています。無理な要求に聞こえるとしても「セキュリティ問題の報告があったらただちに修正に取り掛かり、数時間以内に完了する」ことが唯一の解決策だと言えるそうです。
90日間の脆弱性開示ポリシーはもはや意味をなさないという指摘、AIがバグ発見とエクスプロイト開発を爆速に - GIGAZINE
⇧ 改修の目途が付かないケースもあると思われるのだが、そのあたりの話に触れないのは良くないと思いますな...
昨今の「AI エージェント」のコーディングの影響で、改修に因る「影響範囲」の特定が困難になっている可能性もありますしな...
そもそも、レガシーな「システム」においては、「バージョンアップ」できずに塩漬けになっていることも往々にしてあるのが、日本の「ソフトウェア開発」の現状という気がしますしな...
TimescaleDBを先にアップグレードする必要があるはずだがMicrosoft Copilotは噓を付く...
業務において、
- ストリーミングレプリケーション構成を利用している
- 拡張機能TimescaleDBを利用している
の環境のPostgreSQLの「バージョンアップ」が必要になり、「バージョンアップ」のための手順を整理したかったので、「Microsoft Copilot」氏に質問してみたところ、表題の件...
で、公式の「TimescaleDB」の「ドキュメント」を見ると、
⇧ 上記にありますように、
- TimesaleDB のバージョンアップ
- PostgreSQL のバージョンアップ
の順番の手順とあるのだが、「Microsoft Copilot」氏は、
- PostgreSQL のバージョンアップ
- TimesaleDB のバージョンアップ
の順番の手順と言って来るのである...
しかも、こちらが、「TimescaleDB」の公式の「ドキュメント」に記載の順番が正しいのでは?と確認しても、一向に回答を訂正しないという困ったちゃん状態...
ちなみに、業務後に個人PCで「ChatGPT」氏に質問してみたところ、「TimescaleDB」の公式の「ドキュメント」通りの順番を回答して来た。
2026年5月13日(水)追記:↓ ここから
ちなみに、
⇧ 上記にあるように、「Upgrade self-hosted TimescaleDB to a new major version.」の「ドキュメント」を見てみても、
- TimesaleDB のバージョンアップ
- PostgreSQL のバージョンアップ
になっているのよね...
2026年5月13日(水)追記:↑ ここまで
流石に、「TimescaleDB」の公式の「ドキュメント」が嘘を付くはずが無いとは思いたいのであるからして、「Microsoft Copilot」氏の回答が「幻覚(ハルシネーション)」を引き起こしているのだとは思われるのだが、頑なに回答を訂正しないところが恐怖なのですよ...
By the way、
⇧ 上記にありますように、
- PostgreSQLのサーバー
- TimescaleDB
の「Linux」の「パッケージ」をインストールする必要があるのだが、「マイグレーション」の手順では「情報」が端折られるのよね...
まぁ、
⇧ 上記の公式の「PostgreSQL」の「ドキュメント」でも諸々の「情報」が端折られているからなぁ...
いつまで経っても「ファインダビリティ(Findability)」の欠片も無い「ドキュメント」であるからして、「情報」を継ぎ接ぎして手順を用意する必要が発生するの何とかならんもんか...
正しい手順になっているのかが分からないのが、非常にストレスなのよね...
このあたり、「クラウドサービスプロバイダー」の「PaaS(Platform as a Service)」としての「PostgreSQL」を利用するのであれば、「バージョンアップ」の煩わしさは無くなるのだろうか?
毎度モヤモヤ感が半端ない…
今回はこのへんで。

