土曜の朝に見つかった八つのセキュリティ上の発見

監査は物事を表面化させる。正直な対応は、それを歓迎し、すべてを修正し、恒久的なガードレールを出荷することだ——それこそがランタイムがエンタープライズの信頼を勝ち取る方法だ。

監査は先週の終わりに受信箱に届いた。土曜の朝には、片方の画面にレポートを、もう片方の画面にコードベースを開いていた。重大または高リスクの発見が八件。週末の性格を決める種類の受信箱の中身だった。

これはエンタープライズのデューデリジェンスだった。潜在的なパートナーが、弁護士に前に進ませる前に、自社のセキュリティチームに公開API面のパスを実行するよう依頼していた。発見は具体的で、よく説明されており、まったく公正なものだった。それらはまた、意図的に防御していない限り、エージェント駆動のワークフローが特に脆弱にさらされる類のものでもあった。

土曜の終わりまでに、すべての発見にそれを着地させるPRがあった。これは、それぞれが何だったかについての投稿だ。

カテゴリとは何だったか

私は具体的な攻撃の詳細ではなくカテゴリについて話す。詳細は今や修正済みで競合他社にとって興味深いものではないからだ。カテゴリこそが、他のチームが防御したいと思うものだ。

一つ目:公開RESTサーフェスにおける入力検証。 いくつかのエンドポイントは、そうすべき以上に入力を信頼していた。具体的には、文字列入力の長さの境界、数値入力の範囲の境界、JSONペイロードの構造的検証だ。欠けていた検証はどれ単独では壊滅的ではなかった。「ここに長さの境界がなく、そこにレートリミットがなく、この管理者エンドポイントに認証チェックがない」という組み合わせが、攻撃者がその面を発見してしまえば壊滅的になる類のスタックだ。

二つ目:設定ファイルにハードコードされた認証情報。 数週間前のHMACの発見とは異なるものだ。これは、サンプルバージョンに実際の認証情報がコミットされた設定テンプレートだった。意図は、プレースホルダーであるサンプル認証情報を出荷することだった。実際に出荷されたのは、開発者のローカル環境からの実際の値であるサンプル認証情報だった。ローテーション、サンプルからの削除、シークレットスキャンCIパスへの追加を行った。

三つ目:安全でない暗号スイートのネゴシエーション。 外部サービスとTLSをネゴシエートするサブシステムが、2026年に受け入れられるべきでない暗号スイートを受け入れていた。具体的には、既知の脆弱性を持つ複数のプレTLS1.3スイートだ。修正は、暗号スイートのリストをTLS1.3のみのセットに制約し、レガシーなパートナーシステムに対するテスト用の文書化されたエスケープハッチ(明示的なフラグ)を用意することだった。

四つ目:C API境界における解放後使用。 ランタイムDLLの一つのC APIには、内部状態へのポインタを返す関数があり、呼び出し側は同じハンドルに対する後続の呼び出しによって内部状態が解放された後もそれを使い続けることができた。古典的なC APIの落とし穴だ。修正は「呼び出し側が保持するポインタ」というセマンティクスから、「呼び出し側が保持する不透明ハンドルとハンドルによる取得アクセサ」というセマンティクスへの切り替えだった。アクセサは呼び出しの期間だけ新しいポインタのコピーを返し、基盤となるメモリは公開されない。

五つ目:ライセンシングレイヤーにおけるスレッドセーフティの穴。 二つのスレッドが、同時検証呼び出し中に同じライセンス状態オブジェクトで競合し得た。負荷がかかると、あるスレッドが部分的に更新された状態を見て、ライセンスの有効性について間違った結論に達し得た。修正は、状態の周りに適切な読み書きロックを設けることで、検証パスは一般的なケース(ライセンス有効、状態変更不要)向けに最適化された。

六つ目:管理者エンドポイントにおける認可バイパス。 管理者エンドポイントの一つには、認証チェックはあったが認可チェックはなかった。認証されたユーザーなら誰でもそれを呼び出せた。管理者ロールを持たないユーザーも含めてだ。修正は、ロールチェックを追加し、「管理者として認証されている場合は許可」と「認証されているが管理者でない場合は拒否」の両方のパスを運動させるユニットテストを書き、同じパターンについて他のすべての管理者エンドポイントを監査することだった。他に三つのエンドポイントが同じ問題を持っていた。四つすべてが今は正しい。

七つ目:認証失敗における不十分なロギング。 ユーザーが認証を試みて失敗したとき、ランタイムはその試行をログに記録していたが、ブルートフォースやクレデンシャル・スタッフィングのパターンを調査するのに十分なコンテキストを記録していなかった。修正は、IPアドレス、そのIPのレートリミット・カウンター、試行された認証方法とともに、すべての認証失敗に構造化ロギングを追加することだった。プライバシーを保護しつつ(パスワード内容はログに記録されない)、調査が必要になったときに調査できる十分なコンテキストを持つ。

八つ目:依存関係の更新の遅延。 ランタイムが取り込んでいるサードパーティ依存関係のいくつかが、マニフェストに既知の脆弱性のあるバージョンで固定されていた。修正は、それぞれを最新のパッチ済みバージョンに更新し、更新に対してテストスイートを実行し、更新が要求した少数のAPI形状の変更を解決することだった。八件の更新のうち二件は私たちのコードにアダプター変更を要求した。残りの六件はドロップインだった。Dependabotは今、これを自動的にフラグするよう設定されている。

セキュリティ作業の週末から学んだこと

三つのことだ。驚くべきものではない。言う価値がある。

セキュリティの発見は集まる。 八件の発見は一度に表面化するには多い。振り返ってみると、パターンは、それらすべてが共通の根本原因を共有していることだ:ランタイムはエージェント駆動のワークフローで急速に成長しており、エージェントは単独では正しいものを実装していた。セキュリティのような横断的関心事は、まさにPRごとのレビューをすり抜ける類のものだ。監査は、レビューが見逃したものを捕まえる。監査をスケジュールしよう。

いくつかの発見はエージェント駆動の失敗モードだ。 C APIの解放後使用は、プロンプトが所有権のセマンティクスを指定せずに「この内部状態を呼び出し側に公開する」と言ったときにエージェントが書く類のものだ。ライセンシングレイヤーのスレッドセーフティの穴も同様だ。両方とも同じパターンを捕まえている:所有権と並行性について尋ねられないエージェントは、両方を無視するコードを生み出す。

いくつかの発見はペース駆動の失敗モードだ。 依存関係の更新の遅延はエージェントの問題ではない。これは「速く出荷していて、依存関係を新鮮に保つことを仕事とする人がいない」問題だ。修正はプロセス(Dependabot)と規律(Dependabotのアラートに基づいて行動する)だ。修正は「もっと賢くなる」ではない。

新しい防御

今週末に着地した恒久的なガードレール。

CIにおけるセキュリティスキャナーパス。 入力検証、シークレットスキャン、暗号スイート・ポリシーのための静的解析。すべてのPRがスキャンを実行する。新しい発見を導入するPRはレビューのためにフラグされる。

管理者エンドポイントのテストパターン。 API内のすべての管理者エンドポイントは今、管理者許可パスと非管理者拒否パスの両方を運動させるペアのテストを持つ。このパターンは、@admin_requiredデコレータをスキャンし、対応するペアテストなしでデコレータが存在する場合にビルドを失敗させるCIチェックによって強制される。

共有状態へのスレッドセーフティ注釈。 ランタイム内のすべての共有状態オブジェクトは今、その並行性モデルについての明示的な注釈を持つ:不変、ロック保護、明示的なhappens-beforeを持つロックフリー、または単一スレッドだ。この注釈は型の一部だ。状態に触れるコードはその注釈を満たさなければならない。ロック保護および不変のケースについてはコンパイラが強制する。残りはレビューに委ねられる。

カレンダー上の月次セキュリティ監査。 パートナーが尋ねてくるのを待つのではない。監査は毎月第二土曜日の標準的な項目だ。最初のものは四月に実行される。

パートナーとビルダーがここから学ぶべきこと

パートナーシップのためにエンジンを評価していて、監査を依頼しようとしているなら、このチームはそれを歓迎する。監査は物事を表面化させる。物事は修正される。コードベースは良くなる。パートナー関係は良くなる。監査を歓迎する規律は、どの具体的な発見よりも重要だ。

これを読んでいるエンタープライズのセキュリティ専門家なら、私は監査の頻度と、より多くのエンジンチームに監査してほしい具体的な事柄についての提案を歓迎する。今週末の発見は自明なものだった。自明でないものこそ、次に私が見つけたいものだ。

エージェント駆動のワークフローを実行していて、最近セキュリティ監査を行っていないなら、行ってほしい。「エージェントが単独では正しいコードを書くが横断的な関心事を見逃す」というパターンは、このワークフローの形において普遍的だ。監査は横断的な関心事を捕まえる方法だ。他に私が見つけた方法はない。

週末終わりのチェック。八件の発見がクローズされた。六つの新しい防御が着地した。次の監査はカレンダーに載っている。パートナー関係は前進する。

構築に戻る。