今日、 GitHubでのプルリクエストの3件に1件はAIエージェントが関わっています1年前、その数字は10分の1未満でした。このペースが続けば、今後2年以内にGitHubへプッシュされるコードの大部分はエージェントによって書かれる可能性があります。その多くは、人間に完全に読まれることさえないかもしれません。
開発者やエージェントがより速く動くようになれば、コード作成の加速するペースに保護措置が追いつくよう確保する責任が私たちにはあります。つまり、リークが起こる前により多くを防ぎ、発生してしまった情報漏えいへの対応が手作業の人間の努力に依存する度合いを減らすということです。
漏洩したシークレットにとって重大な転換点です。開発者がますます不注意になっているのではなく、変化のスピードに追いつけていないのです。 ソフトウェア開発者がより多くのソフトウェアを作成できるようにするツールは、そのソフトウェアを保護する作業をもっと担うべきである。
本稿では、その主張を裏付ける9四半期分のデータを共有します。また、Microsoft Applied Sciencesと共に構築したファインチューニング済みの分類器も紹介します。これは、非構造化されたシークレットへプッシュ保護を拡張するためのものです。このモデルは候補となるシークレット一式を2ミリ秒未満で評価でき、防止できるシークレットの数を2倍以上に増やせる可能性があります。
追い越されたのであって、不注意だったのではない
公開されているコードにはおよそ2秒に1回、新しいシークレットが現れており、過去3年間で年々倍増しています。世間の議論はすぐに、AIが開発者を不注意にしたという考えに飛びつきます。
2024年第2四半期から2026年第2四半期の間に、スクリーニング済みプッシュは増加しました。 2.84倍 認証情報を含むプッシュが増加する一方で 2.59倍9四半期分の完全なデータを通じて、1回のプッシュあたりの発生率に関して統計的に検出可能な傾向は見られませんでした。同時に、開発者たちが偶発的な機密情報の露出のリスクをこれまで以上に理解し、そのリスクを受け入れることに消極的になっていることを示唆するデータが見つかりました。同じ期間にわたり、開発者によって上書きされたプッシュ経路のブロックの割合は、 6.63%から3.93%へ。これらの数値は、エージェントが開発者をより不注意にさせているという一般的な主張に疑問を投げかけるものです。
プッシュは増加するも、プッシュ検出率に明確な上昇なし2026年Q2 · 574Mプッシュ · 0.47%にシークレット公開時のプッシュ、2024年Q2〜2026年Q2。プッシュ検出率とは、シークレットが検出された割合を指します。GitHub自身のトークンを含む、サポート対象のプロバイダーパターンを対象としています。一定のレートでは、アクティビティが2倍になると予想される露出も2倍になります。各露出に同じ人間の対応が必要であれば、作業量も2倍になります。シークレットを手動で失効させるまでの平均時間はおおよそ 40日。おおよそ 5人に1人が90日以上かかりました。私たちはソフトウェアの作成を加速させていますが、漏洩した認証情報は数週間から数か月間使用可能なまま残る可能性があります。なぜなら、人的な対応は開発と同じスピードで拡張できないからです。
開発者にもっと注意するよう求めるだけでは、それ自体でこの問題を解決することはできません。コード量が増え続ける中で、ソフトウェア開発を持続可能なものとするためには、より多くの露出を防止し、残ったものに必要な人手を減らさなければなりません。
予防は計算資源に伴って拡大する
私はここ数年GitHubでシークレットスキャンに取り組んできましたが、この1年はその領域のプロダクトリードを務めています。私たちが最も大きなインパクトを上げてきたのは、検出からそれに基づいて動作できるシステムまでを結びつけることででした。
GitHubのカタログでは、150社を超えるテクノロジーパートナーを、当社の シークレットスキャニングパートナープログラム。 当社はパートナープログラムを通じて、参加しているシークレット発行者と連携し、ディテクターの構築や公開された露出の報告を行い、対応できるようにしています。2026年第2四半期には、公開スキャンにより、再観測を含めて平均して毎秒26件のクレデンシャル一致を報告することに成功しました。通知を受け取ると、これらのパートナーの多くはただちにトークンを失効させます。OpenAI APIキー、Google Cloudアカウントのクレデンシャル、Slackのウェブフック、Hugging Faceのユーザートークン、SendGridキーなどです。所有者は依然としてトークンを置き換える必要があるかもしれませんが、失効は、開発者がGitHubのアラートを発見して処理するのを待つことなく行うことができます。
プッシュ保護はより早い段階で介入します。認識可能な認証情報がリポジトリの履歴に入る前にそれを阻止し、露出を調査する事態になる前に開発者やエージェントが変更を修正する機会を与えます。私たちは技術パートナーと協力し、彼らの検出器の精度率を可能な限り高め、開発者コミュニティに対してこれらのシークレットをデフォルトでプッシュ保護できると確信できるレベルに到達させるよう取り組んでいます。
パートナーの皆様のご尽力のおかげで、この1ヶ月間、シークレットは最低でも毎秒1回、プッシュ保護によってブロックされました。発行者に紐付いた資格情報に関しては、GitHubはすり抜けたシークレットよりも多くのシークレットをブロックしています。開発者の皆様にとってそれが当たり前のことに感じられるようにできたことを誇りに思います。
修復は人の規模に比例する
追加のシークレットタイプを含めると、プッシュ保護は新たに検出されたシークレットの約30%を、リポジトリ履歴に入る前に阻止します。残りの70%は、残念ながら資格情報がすでに漏洩した後に発見することになります。そして:
- 防止は計算資源の規模に比例しますが、修復は依然として人の規模に比例します。
- プッシュを拒否するには計算資源がかかりますが、すでに公開履歴に漏れ出たシークレットの後始末には、開発者の時間と注意がかかります。
- コードの量が増えるにつれ、より多くの漏洩を防止し、残ってしまった漏洩に必要な人的労力を削減しなければ、導入される脆弱性の量が手に負えないものになってしまいます。
開発者にもっと注意するよう求めるだけでは、この不均衡を解消することはできません。こうしたシークレットをより多く、より開発フローの早い段階で検出することは、プラットフォームが担わなければならない取り組みです。
「四体問題を解く」
シークレットがpush境界を越える前であれば、それを止めるコストは小さく、判断は二値的です。ブロックするか許可するか。一度越えてしまうと、同じ文字列が実際のシステムへの認証に使われ得るため、コストは無限大になり得ます。
翻訳:多くの場合、検出のための唯一の手がかりは、周辺のコードやワールドのコンテキストかもしれません。プロバイダーが発行するトークンには、識別可能なプレフィックスがあることがあります。内部データベースのパスワードは、まったく非構造化で、識別パターンが一切ないこともあります。私たちはすでに、push後のシークレットを見つけるためにコンテキストを利用していました。問題は、そのコンテキストに基づく判断を他の要因とどうバランスさせるかでした。
私たちはこれを、秘密保護における「四体問題」と呼んでいます: 「精度、レイテンシ、スループット、およびコスト」 「結びついた制約」です。防止は開発者の時間に見合う価値がなければなりません。後でレビューするのに適した指摘は、プッシュをブロックする正当な理由にならないかもしれません。誤検知は開発者を中断させ、次のブロックが信頼されにくくします。遅すぎたり、コストが高すぎたり、スケールが難しすぎるチェックは、実行頻度を制限します。
2ミリ秒未満で押すだけで保護
私たちの新しいModernBERT分類器は、コードや文章を生成することなく、候補となるシークレットを文脈に沿って評価します。既存のLLMベースのパイプラインよりも正確であるだけでなく、非常に高速で、候補のバッチを2ミリ秒未満で評価できます。また、非常にコスト効率が高く、重要な処理経路で大規模に実行できるほどです。
当社のモデルがプッシュ保護に組み込まれたことで、防止できるシークレットの数を2倍以上にすることが可能になりました。この機能は現在プライベートプレビュー中です。今月後半には、Enterprise CloudおよびGitHub TeamsでGitHub Secret Protectionをご利用の組織向けに提供される予定です。この機能はAIクレジットを消費します。
また、このプッシュを超えて、開発者向けサーフェスにもモデルを提供していきます。
- 本日より、すべての AI秘密検出機能を持つ組織 するだろう である 自動的に 更新された 新しいモデル。 これらのプッシュ後スキャンから開かれたアラートは、organization が秘密情報スキャンを購入していれば、追加コストなしで引き続き含まれます。
- ザ このモデルはGitHub Enterprise Server 3.23にも同梱されます パブリックプレビュー中、エアギャップ環境でも AI 検出によるアラートを Secret Protection の顧客に提供します。
- 私たちは 分類器を追加し、
/security-reviewCopilot CLIおよびCopilot App用のコマンドそのため、Copilot ユーザーは、組織の GitHub Secret Protection プランがなくても、プッシュ前にシークレットへ対処できます。AI クレジットの使用量は、AI 使用状況インサイトにおいて GitHub Secret Protection に帰属されます。
今後の展望
私たちが望む未来とは、開発者がすべてのリクエストを監督することなく、より多くの作業をエージェントに任せられる未来であり、組織が認証情報を安全に保つために必要な人員の数が、書くコードの量に比例しなくなる未来です。ソフトウェアを生み出す面で実現しつつある進歩と同等の進歩を、ソフトウェアを守る面でも開発者コミュニティにもたらすことが、私たちの責務です。
私たちは、より多くのソフトウェアを人々に作ってほしいと考えています。それを守る能力も、作る能力とともに大きくなるべきです。
同投稿 機密保護はソフトウェアと共に拡張しなければならない 最初に掲載されたのは The GitHub Blog.