Basetenのセキュリティ欠陥で管理者トークンが露出、ネオクラウドへの信頼に課題

Basetenは、Strixがわずか25分で管理者権限を持つ有効なGitHubトークンを発見したことを受け、重大なセキュリティ欠陥を修正した。Basetenのセキュリティ欠陥は、公開アクセス可能なコンテナレジストリから始まり、同社のAI推論プラットフォームを支えるリポジトリにまで及んだ。

この発見は、計画的な監査や報告された侵害によるものではなかった。Strixは、データ、モデル、コードを委ねる前に、推論プロバイダー候補としてBasetenを評価していた。Strixによれば、その自律型セキュリティエージェントに与えられたのはBasetenのドメインパターンのみだった。

このため、本件は通常の認証情報漏えいよりも重大な意味を持つ。報道によれば、このトークンは2023年3月のイメージビルド以降有効なままであり、企業の購入担当者がベンダー審査中に発見した。Basetenは通報後に迅速に対応したが、この露出は専門特化型AIクラウドをめぐるセキュリティ保証に疑問を投げかけている。

Basetenのセキュリティ欠陥は公開レジストリから始まった

匿名でダウンロード可能なコンテナイメージが、Basetenの公開攻撃面から特権を持つ社内開発システムへの経路を生み出していた。

Strixは、Basetenに関連するホストをマッピングすることからレビューを始めた。エージェントは証明書記録を調査し、サブドメインを列挙したうえで、Harborレジストリを特定した。Harborは、コンテナイメージと関連ソフトウェアアーティファクトを保管・配布するためのシステムだ。

このレジストリ内のあるプロジェクトは、認証なしでアクセスできたと報じられている。訪問者はリポジトリを一覧表示し、匿名プルトークンを要求し、イメージマニフェストとblobをダウンロードできた。これにより、baseten/baseten-appという名前のイメージにアクセスできた。

公開コンテナイメージであること自体は、必ずしも脆弱性ではない。企業は顧客、統合、オープンソースプロジェクト向けに、意図してイメージを公開している。そこでStrixは、アクセス可能なアーティファクトに機密情報が含まれているかを判断するため、調査を続けた。

エージェントはまず、イメージ内で2件のAWS認証情報を検出した。読み取り専用のID要求は無効なトークンという応答を返し、これらの認証情報がすでに機能しないことを示した。この結果により直ちに生じる重大性は下がったが、調査はそこで終わらなかった。

次にStrixはイメージレイヤーをスキャンし、その設定メタデータを調査した。エージェントは、イメージのビルドステップがどのように作成されたかを記録するフィールドであるhistory[].created_byの中から、GitHubのパーソナルアクセストークンを見つけた。

このトークンは、記録されたRUNコマンド内に展開されていたとみられる。その後のコンテナでは通常のファイルとしてシークレットが露出していなくても、ビルド履歴にはその値が残る可能性がある。

Strixは読み取り専用のGitHubリクエストで認証情報をテストした。同社の詳細な開示タイムラインによれば、GitHubはbasetenbotというアカウントを特定する成功応答を返した。

このアカウントはBasetenのGitHub組織に属していたと報じられている。その後のリポジトリ権限チェックでは、複数の社内リポジトリに対する管理者権限およびプッシュ権限が示された。Strixによれば、これにはBasetenの主力製品リポジトリ、クラスターを制御するGitOpsリポジトリ、Homebrew配布用リポジトリが含まれていた。

GitOpsは、バージョン管理されたファイルによってデプロイ済みインフラを定義する運用モデルである。そのためGitOpsリポジトリへのアクセスは、通常のソースコード閲覧を超える影響を持ち得る。悪意ある変更によって、本番システムの設定や更新方法に影響が及ぶ可能性がある。

他のプライベートリポジトリでも、読み取りおよび書き込みアクセスが許可されていたとされる。Strixによれば、一部は特定の顧客に関連していたが、その内容をダウンロードしてはいない。また、コードのプッシュ、設定変更、リポジトリのクローンも行っていないとしている。

これらの制限は重要だ。利用可能な証拠は、このトークンが広範な権限を持っていたという主張を裏付けている。一方で、攻撃者が以前にこのイメージを発見したこと、トークンを使用したこと、顧客情報にアクセスしたこと、あるいはBasetenのシステムを変更したことまでは立証していない。

この区別は、露出と侵害確認を分けるものだ。認証情報は、誰かが悪用した証拠がなくても深刻なセキュリティリスクを生み得る。特に、技術的な説明が欠陥を発見した企業自身によるものである場合、公開報道ではこの違いを維持すべきである。

Strixによれば、影響を受けたイメージは2023年3月3日付だった。この認証情報は2026年7月にテストされた時点でも有効だった。その長期存続により、よくあるビルド上のミスが、はるかに大きなアクセス制御上の失敗へと変わった。

スコープが限定され、有効期限の短い認証情報であれば、被害は抑えられたはずだ。しかし報じられたトークンは、複数の機密性の高いリポジトリへのアクセスと長期存続を兼ね備えていた。公開レジストリが発見可能性をもたらし、過剰な権限が影響を拡大した。

古いDockerビルドが有効なシークレットを残していた

本件は、コンテナの可視ファイルシステムからシークレットを削除しても、必ずしもイメージから消えるわけではない理由を示している。

コンテナイメージには、コンテナ起動時に利用できるファイルだけでなく、レイヤー、設定データ、ビルド命令、アーティファクトの構築方法を明らかにし得るメタデータも含まれる。

このケースでは、シークレットはイメージのビルド履歴に現れていたと報じられている。ビルドはGitHubトークンを引数として受け取り、それを使ってプライベート依存関係への認証付きアクセスを設定していた。

このパターンは、開発中には妥当に見える場合がある。ビルドにプライベートリポジトリのコードが必要であるため、エンジニアが認証情報を渡し、Gitをその認証情報で使うよう設定する。ビルドは完了し、生成されたアプリケーションには明らかなトークンファイルが含まれていないように見える。

しかし、ビルドプロセス自体が置換後の値を保持する可能性がある。その結果、イメージを取得できる人物は、通常のランタイムテストで開発者がほとんど確認しないメタデータを調査できるようになる。

Dockerの現行ビルドシークレットガイダンスは、ビルド引数と環境変数はシークレットには不適切だと明記している。これらの値は、生成されたイメージまたはそのメタデータに残存する可能性がある。

Dockerは代わりにシークレットマウントまたはSSHマウントを推奨している。シークレットマウントでは、認証情報を必要とするビルド命令にのみ利用可能にできる。認証情報をイメージのファイルシステムや記録済みコマンドの一部にする必要はない。

この変更は、Basetenのセキュリティ欠陥の一部にしか対処しない。報じられたDockerfileのパターンでは、認証済みGitHub URLもグローバルGit設定に書き込まれていた。より安全な注入方法であっても、使用するコマンドが別の場所にシークレットを保存すれば失敗する。

したがって、安全なビルドには2つの制御が必要となる。チームは一時的な仕組みを通じて認証情報を注入し、それを使うコマンドが別の永続的コピーを作成しないことを検証しなければならない。

イメージスキャンも、現在のファイルだけを対象にしてはならない。従来のスキャナーは、認識可能な認証情報形式、脆弱なパッケージ、悪意あるバイナリをレイヤー内で検索することが多い。完全なレビューには、設定blob、履歴フィールド、環境設定、プロベナンス記録、エクスポートされたキャッシュを含めるべきだ。

古いイメージにも同様の精査が必要である。レジストリは、チームが使用をやめた後もタグやアーティファクトを保持し得る。こうしたアーティファクトには、以前のセキュリティ慣行、より広い権限、あるいは誰も失効させるのを覚えていなかった認証情報が反映されている場合がある。

Strixの説明にあるイメージは3年以上前のものだった。Basetenのプラットフォーム、デプロイ手法、セキュリティプログラムは、その期間中に変化していた可能性が高い。それでも、この古いアーティファクトはダウンロード可能な状態にあり、なお有効な認証情報と結び付いていたとされる。

これはインフラ負債の一般的な形態だ。アプリケーションは進化しても、忘れられたビルド出力はアクセス可能なまま残る。IDにアクセス権限が蓄積されたり、リポジトリの重要性が増したりすれば、そのリスクは高まる可能性がある。

認証情報管理も、露出に別の層を加えた。GitHubは、組織に対し、より細分化された認証情報を優先し、トークンガイダンスで有効期限を設定するよう助言している。

きめ細かなトークンでは、選択したリポジトリと特定の操作にアクセスを限定できる。GitHub Appsは、長期間稼働する組織統合に別の選択肢を提供できる。その権限とトークンの有効期間は、広範なスコープを持つ個人認証情報よりも正確に制御できる。

報じられたbasetenbotトークンは、複数の防御原則に同時に反していたように見える。長期存続で、広範な認可を持ち、ビルド中に埋め込まれ、公開レジストリプロジェクト経由で到達可能だった。

各々の弱点が、他の弱点を増幅した。レジストリ露出だけであれば、古いイメージが露出しただけで済んだ可能性がある。埋め込まれたトークンだけであれば、入手は困難なままだったかもしれない。広範なリポジトリ権限が、その組み合わせを重大な発見へと変えた。

この複合効果こそ、セキュリティチームが個別の設定ミスではなく攻撃経路を調査する理由である。ありふれたミスが連続すると、単一のコンポーネントが与えるよう設計されていなかったアクセスが生じ得る。

Basetenの迅速な対応はリスクを低減したが、信頼の問題は残る

Basetenは即時の露出を1日以内に封じ込めたと報じられているが、企業の購入担当者は、同様の認証情報やアーティファクトが他に残っていないことを示す証拠を依然として必要としている。

Strixは7月13日遅くに、公開Harborプロジェクト、有効なトークン、その権限を報告した。開示によれば、Basetenは翌朝にこのプロジェクトを非公開にした。

その後Strixは、GitHubトークンが依然として有効であるとBasetenに伝えた。7月14日後半、Basetenのセキュリティチームのメンバーは、この問題を重大と分類し、トークンがローテーションされたことを確認したと報じられている。

Basetenはまた、Strixにダウンロード済みイメージの削除を求めた。Strixは削除を確認し、より重大度の低い追加の2件の発見を共有したとしている。7月17日までに、Basetenは残るこれらの項目を解決した。

この対応は迅速かつ直接的だった。Basetenは報じられた重大度に異議を唱えたようには見えず、Strixは同社のセキュリティチームの協力を評価した。Strixが9月1日に技術的な説明を公開する前に、両社は連携していた。

迅速な是正は重要である。なぜなら、開示への対応はプロバイダーの運用成熟度の一部を示すからだ。組織は、すべてのアーティファクトや設定に誤りがないことを保証することはできない。しかし、報告の検証、封じ込め、調査、そこからの学習をどれほど迅速に行うかは制御できる。

ただし、ローテーションは既知の認証情報を無効化するだけだ。2026年7月以前に誰かがこのトークンを使用したか、イメージのコピーがダウンロードされたか、関連するビルド慣行が他のアーティファクトにも影響したかについては答えにならない。

現時点で、悪意ある使用を裏付ける公開証拠はない。Strixは、自社のリクエストは読み取り専用であり、リポジトリ権限を確認した時点で停止したとしている。Basetenも、このトークンに関連した侵害、顧客データの損失、または無許可のリポジトリ変更を公に説明していない。

報告された悪用がないことを、悪用がなかった証拠に置き換えるべきではない。有意義なインシデントレビューでは、GitHubの監査イベント、レジストリのダウンロードログ、トークンのアクティビティ、リポジトリ変更、露出期間中のデプロイを調査することになる。

このレビューでは、保持期間の制約も考慮する必要がある。ログが、イメージ構築以降の全期間をカバーしているとは限らない。3年前の認証情報は、すべての利用を再構築するために必要なテレメトリーより長く存続し得る。

Basetenの公開されたセキュリティ条項では、共有インフラ上の顧客コンテンツに対する論理的分離が説明されている。また、追加の隔離を必要とする購入者向けに、専用クラスターや顧客ホスト型デプロイメントについても言及している。

これらの管理策は実行時データの分離に対応するものだが、今回の事案はプラットフォームを取り巻くソフトウェア・サプライチェーンで発生した。リポジトリの認証情報とビルド成果物は顧客ワークロードの上流に位置する。そこでの侵害は、複数のデプロイメント層に影響し得る。

これが信頼に関する中心的な問題を生む。エンタープライズの購入者は、推論リクエストが暗号化または分離されているかだけを評価するわけではない。そのリクエストを処理するソフトウェア、設定、オートメーションを誰が変更できるかも評価しなければならない。

プッシュ権限を持つトークンは、本番データを直接読み取らなくても完全性を脅かし得る。攻撃者はコードやデプロイメント定義の改変を試み、その後、通常のオートメーションが変更を配布するのを待つ可能性がある。

管理アクセスは、リポジトリ設定や組織ポリシー次第で、さらに広範な影響をもたらし得る。権限、ブランチ保護、webhook、シークレット、オートメーションの変更を許す可能性がある。Strixは、そうした破壊的な経路をテストしていない。

したがって顧客にとってのリスクは、ソースコードの機密性だけに限定されない。サプライチェーンの改ざん、運用の中断、あるいは悪意あるソフトウェア変更を介した間接的なアクセスの可能性も含まれる。

Basetenは、開示された経路を迅速に封じ込めた点で評価に値する。しかし、信頼は対応速度だけに依拠できない。顧客には、同社が隣接する成果物を確認し、認証情報の権限範囲を縮小し、過去のアクセスを調査したという保証も必要だ。

その保証は、顧客への直接連絡、独立した評価、監査証跡、あるいはより詳細な公開ポストモーテムを通じて示される可能性がある。いずれも、新たな攻撃機会を生む情報の公開を要するべきではない。

適切な基準は、影響に見合った透明性である。Basetenはすべての内部統制を開示する必要はないが、影響を受けた関係者は何が露出したのか、どのログが確認されたのか、顧客側の対応が必要かを理解できるべきだ。

NeocloudのスピードがHyperscalerへの期待と衝突している

より大きな問題は、特化型AIインフラのセキュリティが必然的に不足することではない。顧客が、はるかに若い運用環境にもクラウド級の統制を期待するようになったことだ。

Basetenは、AIモデルのデプロイと提供のためのインフラを提供している。この推論作業には、独自のモデル重み、プロンプト、顧客記録、アプリケーションロジック、接続先システムの認証情報が含まれ得る。

特化型AIクラウド事業者は、チームにアクセラレーターとマネージド推論機能への迅速なアクセスを提供することで競争している。モデル性能、デプロイ速度、GPU利用率について、汎用クラウドよりも狭い領域に集中できる。

この特化は、求められるセキュリティ基準を引き下げない。AIワークロードは価値の高い知的財産と機微な運用データを組み合わせることが多いため、むしろ基準を高める可能性がある。

Neocloudというラベルは、異なる事業・技術モデルを含む。一部の企業は主にアクセラレーター容量を貸し出す。別の企業は、自ら運用する、または大手クラウドから調達したインフラ上で、マネージド学習、推論、オーケストレーション、開発者プラットフォームを提供する。

そのため顧客は、各層をどの当事者が管理しているかを特定しなければならない。関連する連鎖には、データセンター運営者、ハードウェア事業者、インフラ・クラウド、モデル提供プラットフォーム、コンテナレジストリ、ソースコードホスト、顧客アプリケーションが含まれ得る。

一つの層の失敗は他の層にも及び得る。Basetenのセキュリティ上の欠陥は、GPUやモデルへの攻撃を必要としなかった。通常のWeb探索からレジストリに至り、イメージメタデータからソース管理の権限へと進んだ。

まさにこのため、従来型のクラウドセキュリティ統制はいまなお重要である。AIインフラは高度なアクセラレーターや特化型ネットワークを利用するかもしれないが、露出したレジストリ、永続的なシークレット、過剰な権限は依然として馴染み深い問題だ。

最近の業界監査は、複数のneocloud環境が脆弱なテナント境界、旧式コンポーネント、または過度に接続された管理システムに依存していると論じた。同レポートはセキュリティ論争をめぐる利害も認め、読者に根拠となる証拠を検討するよう促している。

Basetenの事案は、その調査で説明されたテナント間インフラの問題とは異なる。あるBaseten顧客が別の顧客の稼働中ワークロードにアクセスしたことを示す公開実証はない。

むしろこの事案は、サプライチェーンの集中を示している。報道によれば、単一のオートメーションIDが、製品、デプロイメント、配布、顧客固有リポジトリにまたがる重要なアクセス権を持っていた。この集中により、一つの漏洩トークンがもたらし得る影響範囲は拡大した。

この出来事は、競争上の不均衡という厄介な問題も露呈させる。大手Hyperscalerも深刻な脆弱性、認証情報漏洩、設定不備を経験してきた。その規模が免疫を与えるわけではない。

しかし既存の事業者は、IDシステム、監査ツール、シークレット検出プログラム、インシデント対応プロセスの構築に長年を費やしてきた。エンタープライズ顧客は、より小規模なAI事業者にも、開発のより早い段階で同等の証拠を示すことをますます期待している。

需要はその圧力を強めるだろう。Gartnerは市場予測において、neocloud事業者が2030年までにAIクラウド市場の有意な部分を獲得すると予測している。

成長はリターンと攻撃対象領域の双方を拡大する。エンタープライズのワークロードが増えれば、ID、イメージ、リポジトリ、リージョン、クラスター、ソフトウェア依存関係も増える。セキュリティプログラムは、そのすべてにわたって拡張されなければならない。

見込み顧客は、敵対的テストを調達プロセスの一部として扱うことで対応するだろう。Strixのスキャンが特に高度だったのは、購入者自身が自律型ペネトレーションテストシステムを開発しているためだ。大半の企業は、そのレビューを社内で再現できない。

それでも、より厳しい質問はできる。購入者は、レジストリ統制、認証情報の有効期間ポリシー、ソフトウェア部品表の実務、インシデント通知条件、独立したペネトレーションテストの要約を要求すべきだ。

また、事業者がビルド、デプロイメント、顧客向けIDを分離しているかも確認すべきである。依存関係を取得する認証情報が、本番コードリポジトリやデプロイメント定義を管理してはならない。

契約上の保証は依然として有用だが、アーキテクチャと運用上の証拠の方が重要である。ポリシーは最小権限を求めていても、古いオートメーショントークンが複数のリポジトリにわたるアクセスをひそかに保持している場合がある。

継続的な外部テストは、そうしたギャップの発見に役立つ。これは認証済みレビュー、コード分析、依存関係スキャン、内部脅威モデリングを補完すべきだ。ブラックボックステストは未認証の外部者に見えるものを捉え、内部評価は公開面からは見えない統制を調べる。

Strixの役割には、必要な留保がある。同社は自律型セキュリティテストを販売しており、この事案はその製品の能力を示している。したがって、その技術的な説明は同社の商業的利益を支えている。

これは発見の有効性を損なうものではない。詳細な時系列、限定的な検証手順、修正の流れ、Basetenとの協調に関する報告は、信頼性を加えている。それでも、トークンとレジストリの露出が解消されたため、独立報道は当初のアクセスを再現していない。

読者はこの発見を、開示され修正済みの脆弱性として扱うべきであり、すべてのneocloudが同じ弱点を共有する証拠と見なすべきではない。より広い教訓は、包括的な不信ではなく検証にある。

三つのシグナルが教訓が定着するかを示す

次の試金石は、Basetenとその同業者が、一件の認証情報漏洩をビルドシステム、ID、顧客保証にわたる持続的な変更へ転換できるかどうかだ。

最初のシグナルは、Basetenによる追跡レビューの範囲である。basetenbotのローテーションと一つのHarborプロジェクトの非公開化は、実証された経路に対処した。持続的な対応には、すべてのレジストリプロジェクト、過去のイメージ、ビルドキャッシュ、オートメーション認証情報の棚卸しが含まれるだろう。

この作業には、現在のデプロイメントで参照されなくなったイメージも含めるべきだ。チームは稼働中のリリースに集中するため、古いタグは定期スキャンから漏れがちである。しかし攻撃者は、有効なシークレットを含むダウンロード可能な成果物を利用できる。

レビューでは、イメージ設定とビルド履歴も検索すべきである。ファイルシステムのみのスキャンでは、Strixが説明した場所を見逃す。ビルドパイプラインには、公開前にレイヤーとメタデータの双方に含まれるシークレットを拒否するゲートが必要だ。

第二のシグナルは、ID設計の見直しである。Basetenは、広範な個人用アクセストークンを、限定的に認可された短命の認証情報へ置き換えることで、将来の影響範囲を縮小できる。

一つの依存関係を取得するビルドには、その依存関係への読み取りアクセスが必要だ。製品リポジトリ、デプロイメント設定、無関係な顧客プロジェクトを管理する権限は必要ない。

事業者は、環境と目的ごとにIDを分離すべきである。ビルド、リリース、デプロイメント、パッケージ配布、顧客統合のタスクが一つの認証情報を共有してはならない。一つのワークフローが侵害されても、意図的に設計された境界で止まるべきだ。

有効期限も同様に重要である。長期にわたるオートメーションシークレットは、チーム、リポジトリ、アーキテクチャの変更をまたいで残りがちだ。短命の認証情報にはより良いオートメーションが必要になるが、忘れられたコピーの有用性を大幅に低下させる。

第三のシグナルは、購入者の行動の変化である。セキュリティチームは、モデル、プロンプト、文書、ソースコードを送信する前に、見込みのAIベンダーをスキャンすることがますます重要になる。

すべての顧客が積極的なペネトレーションテストを実施する必要はない。無許可の活動は法的・運用上のリスクを生み得る。購入者は、許可された外部評価、文書レビュー、アクセス制御の検証、契約上のセキュリティ質問から始められる。

自社の保護策も維持すべきだ。機微なモデル資産とソース素材は、外部サービスに届く前に分類する必要がある。チームは、事業者が受け取るものをパーソナルナレッジベースで文書化し、そのインベントリをベンダーレビューに結び付けられる。

顧客は、完全な防止を前提とするのではなく、事業者の障害を想定して計画すべきだ。つまり、アップロードするシークレットを制限し、認証情報を分離し、異常な活動を監視し、重要なワークロードの退出経路を確保することである。

Basetenのセキュリティ上の欠陥は、明確な逆転を示している。見込み顧客は推論性能、信頼性、統合の手間を評価するはずだった。ところが、その予備的なセキュリティ確認によって、ベンダー自身を支えるシステムへのアクセスが明らかになった。

Basetenの迅速な対応は、この物語の一面を強めている。報道によれば、同社は深刻度を受け入れ、レジストリ露出を封じ込め、認証情報をローテーションし、残る指摘を数日以内に解消した。

未解決なのは、過去に関する保証だ。公開情報だけでは、他者がイメージを取得したか、そのトークンが以前に不正利用されたか、Basetenが類似の成果物をどこまで広く検索したかは分からない。

こうした未回答の疑問を憶測で埋めるべきではない。調達上の質問と監査対象にすべきである。

Neocloudにとって、スピードは依然として重要な優位性である。顧客は迅速なモデルデプロイメントと、希少なコンピューティング能力へのアクセスを求めている。しかし、購入者がそれを構築・運用するシステムを信頼できなければ、高速なインフラは価値を失う。

実務上の問いは、専門特化型AIクラウドがハイパースケーラーに機能面で一つひとつ対抗できるかどうかでは、もはやありません。成長を続ける中で、規律ある認証情報管理、テナント分離、サプライチェーン統制を実証できるかどうかです。

Basetenは判明していた露出を解消しました。今後、顧客はこの修正が単一のトークンや単一のレジストリプロジェクトにとどまらなかったことを示す証拠に注目すべきです。その証拠によって、これが孤立したミスにとどまるのか、それともネオクラウド市場全体が教訓として受け止め損ねた警告となるのかが決まります。