CrowdStrikeの新たな調査で、中国を代表する大規模言語モデル（LLM）であるDeepSeek-R1は、プロンプトに政治的に敏感な用語が含まれていると、安全性の低いコードを生成する可能性があることが明らかになった。
この調査結果は、チベット、法輪功、ウイグル族などの話題への言及によって、コーディング作業自体とは無関係であっても、DeepSeekのコード出力に含まれる深刻な脆弱性が約50％増加する可能性を示している。
「モデルの性能が地政学やイデオロギーによって変化するなら、それはバイアスではなく、サプライチェーンのリスクだ。知らないうちに忠誠的な言語モデル（Loyal Language Model）を使っており、その忠誠心が自社のセキュリティ体制と衝突する可能性がある」と、CrowdStrikeでCounter Adversary Operationsを率いるAdam Meyers氏は述べた。
同氏はさらに、「要点は単純だ。AIコーディングアシスタントを中立的なツールとして扱うことはできない。そこには学習データと規制環境の影響が持ち込まれる。そうした条件下で厳密にテストしない限り、存在すら把握していない脆弱性を抱えたまま製品を出荷することになる」と付け加えた。
「大規模言語モデルの学習プロセスについて考えるとき、多くの人がまず思い浮かべるのは、インターネット上のテキストなど、膨大な量のソース資料を使った学習だろう。CrowdStrikeの今回の研究は、その後に行われる強化学習の重要性を浮き彫りにしている。強化学習では、特定のプロンプトに対して望ましい応答を返すよう、モデルの出力を誘導する」と、Flare所属の脅威インテリジェンス研究者Chris d’Eon氏は述べた。
同氏は、「望ましい応答とは具体的に何を指すのかは、学習を実施する組織が定める。組織の価値観やバイアスは、この強化学習の段階を通じて容易にモデルの挙動へと取り込まれる。中国本土に拠点を置く企業が、自国の目的に害を及ぼすと見なしたプロジェクトへの支援から大規模言語モデルを遠ざけるのは、驚くことではない」と説明した。
Chris氏はさらに、「同様の挙動は他のモデルにも見られる。これらのモデルにも、開発組織や、モデルが置かれている文化が有害だと認識する出力に対する同様のガードレールがある。フロンティアモデルの開発者にとって安全性とセキュリティは非常に大きな懸念事項だが、西側諸国の組織と中国本土の組織では、安全性とセキュリティの定義が大きく異なる」と述べた。
CrowdStrikeの調査結果
CrowdStrikeは、APIレベルのガードレールによる干渉を避けるため、オープンソースのDeepSeek-R1 671Bモデルをそのままテストした。
チームはDeepSeek-R1を、70Bの非推論モデル、120Bの推論モデル、DeepSeek独自の70B蒸留モデルなど、複数の西側オープンソースモデルと比較した。
ベースライン測定では、中立的なプロンプトを与えた場合、DeepSeek-R1が脆弱なコードを生成した割合は約19％で、他のモデルと同等か、それ以上の結果を示した。
しかし、研究者が中国共産党（CCP）にとって敏感な話題に結び付く文脈修飾子を追加すると、結果は劇的に変化した。
例えば、「チベットを拠点とする産業用制御システム向けに」と追加すると、脆弱性率は27.2％に上昇した。
法輪功やウイグル族への言及など、他の修飾子でも、安全でないコードの生成が同様に統計的有意差を伴って急増した。
ある例では、モデルは秘密情報をハードコードし、脆弱な入力処理を使用し、さらには無効なPHPまで含む金融処理スクリプトを生成した。その一方で、PayPalのベストプラクティスに従っていると主張していた。
別の例では、DeepSeek-R1はパスワードのハッシュ化と管理者パネルを備えた完全なWebアプリケーションを構築したが、認証を丸ごと省略したため、システム全体が一般に公開された状態になっていた。
DeepSeekのバイアスに潜む隠れた欠陥
問題の核心にあるのは、文脈修飾子によって引き起こされ、モデルの学習データ内にある政治的・イデオロギー的な制約を活性化する創発的挙動だ。
CVEやインジェクションの欠陥といった従来型の脆弱性とは異なり、この問題はモデルのアライメントのずれに起因する。特定の用語にさらされた際にLLMが好ましくない、あるいは予測不能な挙動を示す原因となる、モデル内部の微妙な関連付けだ。
CrowdStrikeはさらに、「固有のキルスイッチ」とも呼べる挙動を特定した。DeepSeek-R1は、政治的に敏感なプロンプトに対して技術的な対応を最後まで計画する一方、最終段階でコードの出力を拒否した。
チームはモデルをそのままテストしたため、こうした拒否は外部のガードレールによって強制されたのではなく、モデルの重みに組み込まれていると考えられる。
これは、学習中に追加された安全性、検閲、バイアスの制御が、意図せずモデルの一貫した、または安全なコード生成能力を低下させ、企業環境に予測不能なリスクを生み出す可能性を示している。
AI主導の開発におけるセキュリティの強化
組織がLLMを開発ワークフローにより深く統合し始めるなか、こうしたツールの安全を確保することは、ツールが生成するコードの安全を確保することと同じくらい重要になる。
CrowdStrikeの調査結果は、一見無関係な文脈によって引き起こされる微妙なモデルのバイアスが、重要システムにひそかに脆弱性を持ち込む可能性を明らかにしている。
こうしたリスクを先回りして防ぐには、セキュリティチームは従来のコードレビューだけでは不十分だ。組織はまず、次の取り組みを始めるべきだ。
- 実際の開発環境でLLMをテストし、オープンソースやベンダーのベンチマークだけに頼らない。
- ガードレールを実装し、自動コードスキャンを導入して、SDLCの早い段階で安全でないパターンを検出する。
- 価値の高いリポジトリへのアクセスを分離し、レビューなしにAI生成コードが重要システムへ脆弱性を持ち込めないようにする。
- 多様なモデルのアンサンブルを利用し、またはルーティングロジックを用いて、文脈バイアスを起こしやすい単一のLLMへの依存を避ける。
- 堅牢な監視を実装し、アライメントの問題を示す可能性がある予期せぬコードの挙動や出力の異常を検知する。
- プロンプト構築に関するガバナンス管理を確立し、開発中に意図しないトリガーが発生するのを抑える。
- 依存関係とオープンソース統合を見直し、同様のバイアスに起因する障害がないか確認する。
AI支援開発の時代にサイバーレジリエンスを構築するには、LLMを本質的に信頼できるものと見なすのではなく、継続的なテスト、監視、制約を必要とするコンポーネントとして扱う必要がある。
AIのバイアスがコードのセキュリティを脅かす仕組み
CrowdStrikeの調査結果は、AIセキュリティにおける新たな課題を浮き彫りにしている。学習データに組み込まれたイデオロギー的・政治的な制約が、コード生成を含む無関係なタスクにおけるモデルの信頼性を意図せず低下させる可能性がある。
より多くの企業がLLMを中核的な開発ツールとして採用するにつれ、こうした微妙なバイアスが、広範な脆弱性やサプライチェーンリスク、長期的なアライメントの問題につながる可能性がある。
こうしたリスクは、ソフトウェアサプライチェーンを保護すること――開発者が書くコードから、それを生成するAIモデルに至るまで――が、かつてないほど重要になっている理由を示している。