Claudeで自社ソースコードの敵対的テストを行う方法

要点： 「このコードをレビューして」と頼めば、丁寧な形をした要約が返ってきます。ある信頼境界にあるひとつの前提を壊してみろと頼めば、選別する価値のある指摘が返ってきます。かかる時間はどちらも五分。役に立つのは片方だけです。これを機能させる規律は、再現できていない指摘を一件も数えないこと。これを正当に保つ規律は、対象が自社のコードで、自社のシステムで、承認があることです。

ほとんどのソフトウェアは、意図的に攻撃されたことがありません。書いた本人たちがレビューし、ビルドの仕組みに入っている検査を通り、そして出荷される。最初に出会う本当に敵対的な読者は、味方ではありません。

資格のある人によるペネトレーションテストがその正しい答えであり、実際の費用と日程がかかります。何もしないことと正式に依頼することの間に、安い中間段階があります。見慣れないコードを読み、それがどう壊れるかの仮説を立てるのが非常に得意なモデルを使って、午後いっぱい自分のコードを攻撃してみることです。正しくやれば実在の欠陥が見つかります。多くの人がやる形でやれば何も見つからず、全員が安心して終わります。それはやらないより悪い結果です。

以下はすべて、コードが自社のもの、システムが自社のもの、あるいは所有者からの書面による承認があることを前提にしています。これは形式ではありません。セキュリティの仕事とまったく別の何かを分ける線であり、誰かに問われた後ではなく着手前に文書で持っておく価値があります。

「このコードをレビューして」がほとんど何も見つけない理由

問題はモデルではなく指示の側にあります。

標的がないので、網羅性を最適化します。 レビューを求められたモデルは、どんなコードにも常に当てはまることを返します。エラー処理を改善できる、この関数は長い、テストを追加してはどうか。すべて正しく、どれも脆弱性ではありません。

どの入力を攻撃者が操作できるのかを知りません。 信頼境界がなければ、文字列はただの文字列です。同じ連結が、起動スクリプトの中なら些事で、リクエストハンドラの中なら重大な問題になります。そしてファイル自体には、どちらを見ているのかを伝えるものがありません。

特に言われなければ同調的です。 「これは安全に見えますか」は安心を誘う問いで、望みどおりのものが返ってきます。問題を見つけることが成功であって気まずい結果ではない、という枠組みにする必要があります。

ファイル単体では肝心な部分が欠けています。 何が、何を伴い、誰の代理で、どの検査の後にこれを呼ぶのか。その文脈はコードベースの別の場所にあり、ファイルだけのレビューは断片のレビューです。

敵対的な枠組みが変えること

ファイルを要約させるのではなく前提を攻撃させるには

壊してほしい前提を一文で述べ、その反証を求めます。「この認可コードをレビューして」ではなく「このエンドポイントは、呼び出し元が自分の組織に属する注文IDしか参照できないと前提している。その前提が偽になりうる経路をすべて挙げてほしい」。一回につき前提はひとつ。標的が狭いほど出力は使えるものになります。

判定ではなく成立経路を要求すること。 指摘は連なりとして届くべきです。この入力を、この状態で、この主体が送ると、この結果になる。経路のない主張は指摘の格好をした推測で、経路を求めるだけでかなりの割合が目に触れる前に落ちます。

「見つからない」を許可すること。 このコードとこの前提に関して「成立する攻撃は見つからない」は妥当で有用な回答だと明示してください。そう言わなければ、空白は埋められます。

自分のモデルに照らして順位づけさせること。 攻撃者が実際に最初に試すのはどれで、なぜかを聞きます。返ってくる理由は順位そのものより情報量が多く、モデルがどこで構成を誤解したかも露わになります。

答えを実際に変える文脈はどれか

四つあり、その欠落こそ多くの試みが失敗する理由です。

信頼境界——攻撃者が操作できるデータがどこから入り、その線の両側のデータについてシステムが何を信じているか。認証と認可のモデル——呼び出し元の身元がどう確立され、権限がどこで検査され、検査が飛ばされると何が起きるか。データモデル——何がテナント単位で、何が利用者単位で、何も分離されていないのはどれか。脅威モデル——名前の分かる十二人が使う社内ツールと、公開の登録フォームでは、注ぐべき注意がまったく違います。

これらを渡せばモデルはあなたのシステムについて推論します。渡さなければ、もっともらしい構成を勝手に作り、自分で作ったほうをレビューします。

実践的な敵対的パスの手順

何かを指示する前に標的モデルを作る

三十分かけて書き出します。入口、役割、各役割に許されること、最も失いたくないデータの所在、そして「間違っていたと分かったら最も動揺する前提」を三つ。この文書がパス全体の基準になり、ここで止めても価値があります。多くのチームは一度も書き出しておらず、それ自体が問題の一部です。

攻撃仮説は一度にひとつ

境界ごと、前提ごとに進めます。十の懸念を含む指示は十すべてに浅い出力を返し、ひとつだけの指示は手を動かせるものを返します。範囲は「まとめて意味を成す」コードに絞ります。ハンドラと、それが依存するミドルウェアとデータアクセス。リポジトリ全体ではありません。入り切らないうえ、入ったとしても注意が薄まります。

攻撃者は意識的に変えてください。未認証の他人、別組織に属する認証済みの顧客、トークンが失効していない元従業員、そして一時間前に自分が正当に送った要求を再送できる者。同じコードに対する四通りの読者で、見つけるものが違います。

選別——再現するまで一件も数えない

指摘には必ずひとつだけ札をつけます。再現済みは、悪いことを実際に起こせたということです。テストの中で、ローカルの環境に対して、手順を書き残して。反証済みは、経路をたどった結果それが存在しないということ。情報不足は結論ではなく預かり場所で、そこに一週間留まった指摘は誰も信じていない指摘です。

作業になるのは再現済みのものだけ。この規則は初回には厳しく感じられ、そしてこの取り組みに価値がある理由のすべてです。

敵対的AIレビュー vs 静的解析 vs 本物のペネトレーションテスト

• 費用 — AIレビューの圧勝。価格は購読料と午後半日です。
• コードの網羅範囲 — 静的解析の勝ち。誰がどこを見るか決めなくても、毎回のビルドで全体を通ります。
• 意図と業務ロジックの理解 — AIレビューの明確な勝ち。「この返金経路は顧客から到達できてはならない」をスキャナは知りませんが、標的モデルに照らして推論するモデルは扱えます。
• 偽陽性の負担 — 静的解析もAIレビューも負けますが、負け方が違います。スキャナは機械的な偽陽性を大量に出し、人は濾し方を覚えます。AIレビューは数は少なく、はるかに説得力があります。
• サービスをまたぐ連鎖的な攻撃 — ペネトレーションテストの圧勝。弱いリセット手順と別サービスの情報漏れを組み合わせるのは経験ある実務家の仕事で、他の二つは試みもしません。
• 顧客や監査に示せる保証 — ペネトレーションテストの勝ちで、差は大きい。資格ある実務家の報告書は証拠ですが、チャットの記録は証拠ではありません。

献立ではなく順序として読んでください。AIレビュー、静的解析、そして依頼という順にすれば、高い工程が「無料で見つけられたもの」に費やされません。

偽陽性という問題

流暢でもっともらしい文章はモデルの最も強い出力であり、あなたの最大の費用でもあります。重要な失敗は二種類あり、紙の上では見分けがつきません。

ひとつは、実在する脆弱性の型を正確に説明しているのに、コードは実際にはそうしていない指摘。モデルは形に一致し、その帰結を語ったのです。もうひとつは、技術的には正しいのに到達できない指摘。三層上の検査がすでに防いでいるからです。どちらも自信に満ち、具体的で、不安を煽ります。

見落とされがちな代償もあります。*直してしまった*偽陽性は、放置した偽陽性より悪い。正常なコードを変更し、レビューの時間を使い、そのうえで「安全になった」と信じて立ち去ることになるからです。まず再現すること。常に。

これでは決して見つからないもの

実行環境とインフラの設定不備。 権限を誤ったストレージ、世界に開いたセキュリティグループ、既定の資格情報のままの管理画面。どれもソースの中にはありません。

渡していないコードのすべて。 依存関係も当然そこに含まれます。

サービスをまたぐ連鎖。 単体では無害な情報漏れが難しい攻撃を容易にする、その働きは二つのシステムの隙間にあり、あなたは別々にレビューしました。

外部の人間が気づく業務ロジックの悪用。 価格の境界事例、返金の流れ、複数段階の処理での競合。一部はコードに見えますが、最も価値のある例は、ファイルではなく事業を考えている人にしか見えません。

ビルド経路と秘密情報の扱い。 そこへ意図的に向けない限り対象外で、向ける人はほとんどいません。

この一覧こそが、「これはペネトレーションテストの代わりになるか」への正直な答えが「ならない」である理由であり、そう言うこと自体が免責ではなく主張です。

正しく進めるために——ソースの機密、承認、ITに任せる範囲

日常にする前に片づけておくことが三つあります。

第一に承認。自社のコードと自社のシステムであること。一部でも顧客のものなら、着手前に書面で許可を取ること。指摘に独立した検証が要る段階——あるいは顧客、保険会社、監査人が保証ではなく証拠を求める段階——に来たとき、それを提供するのが資格ある実務家によるペネトレーションテストです。実務家が構成の詳細を受け取って本記事と同じやり方で進めるオープンボックス型の依頼も含み、違いは責任が伴うことです。

第二に機密。ソースコードはたいてい会社で最も機微な資産であり、この進め方はそれを自社環境の外へ出します。使っている製品階層のデータ取り扱いと学習利用の条件を、思い込みではなく読んでください。法人向けと消費者向けは異なるのが普通で、条件も変わります。貼り付けるものからは資格情報を外すこと。有効な秘密を含むコードを既に外部ツールへ入れてしまったなら、保持されたかどうかを推論するのではなく、その秘密を更新してください。

第三に指摘のその後。再現済みの欠陥は、他の作業を追跡している場所に再現手順つきで置きます。サポートチケットを構造化した不具合報告に変える記事が、この書き起こしの問題を直接扱っています。AI+サポートはこの種の作業を開発者個人のログインではなく会社アカウントと統制されたアクセスの上に整えることを支援し、管理型ITサポートは、この作業が露わにしがちな資格情報の更新とアクセス衛生を扱います。Brocentは2007年の北京での創業以来アジアで管理型ITとセキュリティを提供しており、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

自社のソースコードをAIモデルに送って安全ですか？

階層と提供元によりますし、既定で起きることではなく意識して下す判断です。使っている製品の現在のデータ取り扱いと学習利用の条件を確認し、その用途向けに条件が書かれた法人向け階層を優先し、貼り付けられた秘密は漏洩したものとして扱ってください。本当に機微なシステムでは、リポジトリ全体を貼るのではなく、環境の外に出るものを絞ります。

指摘のうち本物はどのくらいですか？

初回はほとんどが雑音だと思ってください。そして普遍的な数字を出す相手は信用しないこと。指示の仕方、コードベース、渡した文脈の量で大きく変わります。重要なのは自分たちの比率を測ることです。数回ぶんの再現済みと反証済みを記録すれば、枠組みが効いているかはすぐ分かります。

これはペネトレーションテストの代わりになりますか？

なりません。見せたコードしかレビューせず、見ていないシステムをまたいで指摘を連鎖させられず、その出力は誰も受け取ってくれる証拠になりません。高い工程に金を払う前に、明白なものを見つけて直しておく安価な手段です。だからこそ高い工程の費用対効果が上がります。

CIに組み込めますか？

リポジトリ全体の走査としてより、変更されたコードに対する関門としてのほうがはるかにうまく働きます。差分を、その変更に関係する安全上の前提と照らしてレビューするのは有界で有用です。毎ビルドで無制限の敵対的パスを回すと一週間ほどで警告疲れが起き、最後は全員が無視して終わります。

再現できない指摘はどう扱いますか？

理由と一緒に一覧に残し、関連コードが変わったときに見直します。直さない、上に報告しない、作業にしない。再現できていない指摘は仮説であり、仮説を欠陥として扱うことが、チームがこの取り組み全体への信頼を失う道筋です。

モデルにはコードベース全体が必要ですか？

必要ありませんし、全部渡すとたいてい出力は悪くなります。効くのは正しい一切れ——試している境界、その呼び出し元、その間にある検査——と、書き出した標的モデルです。ここでは量より精度が効き、それが「一度にひとつの仮説」が「まとめて走査」より有効な理由でもあります。

まずどこから

壊れたときに最も痛い前提をひとつ選びます。たいていは「利用者が別組織のデータに到達できないこと」です。それを一文で書き、ハンドラとデータベースに至るまでの呼び出しを集め、それが偽になりうる経路をすべて挙げさせます。そして返ってきたものを、誰かに伝える前に再現してください。境界をひとつ丁寧にやるほうが、リポジトリ全体のレビューより自社のシステムについて多くを教えてくれますし、次の境界に使える型も手に入ります。その作業を有資格の実務家に検証してほしい、あるいは露わになった資格情報とアクセスの衛生をきちんと引き受けてほしいなら、お問い合わせください。