セキュアなコード開発はツールやソフトウェアにとどまらず、リスク管理を土台とする複雑な活動であり、開発者の強みと弱みを理解することも必要になる。
開発者の専門知識のレベルを把握することは大いに役立ち、セキュリティ問題が発生しやすい箇所や、どの開発者がどのタスクに最適かを判断する助けになる。
生成AIの大規模言語モデル（LLM）がより多くのコードを書くようになる中、その管理にも同じアプローチが必要となる。
各モデルにはそれぞれ好みのコーディングスタイルがあり、コード生成などの分野では強みを発揮する一方、セキュリティ上の盲点を抱えることもある。結局のところ、AIモデルにもそれぞれ固有のパーソナリティがある。
AIが生成したコードは「機械製」ではあるものの、LLMが持ち込む潜在的なリスクや脆弱性への対策を不十分なものにしないためには、各モデルとその生成コードに合わせて、保護とレビューの方法をカスタマイズする必要がある。
組織は、厳密なセキュリティレビューを確立し、人間の開発者がプロセスの軸となって効果的なセキュリティ対策を実装するとともに、使用する各LLM固有のコーディング気質も管理しなければならない。
AI生成コードを人間の開発者が作成したコードと異なる扱いにしてはならず、同じように個別化されたリスク評価を受ける必要がある。
主なポイント
- LLMにはそれぞれ異なる「コーディング・パーソナリティ」があり、コードの品質、複雑さ、ドキュメント、セキュリティ面の成果に影響を与える。
- Sonarの分析によると、主要なAIコーディングモデルには、セキュリティ上の盲点、技術的負債、高深刻度の脆弱性を持ち込む可能性など、共通する弱点がある。
- あらゆるタスクに秀でた単一のモデルは存在しないため、LLMの強みと弱みを具体的な開発用途に適合させることが重要になる。
- 開発者は、ソフトウェア開発ライフサイクル全体を通じてAI生成コードを効果的にレビュー、検証、保護するための高度なセキュリティスキルを身に付ける必要がある。
- 組織はAI生成コードを人間が書いたコードと同じように扱い、同じリスク評価、セキュアコーディングの実践、レビュープロセスを適用すべきだ。
コード生成において、LLMも人間と同じ
Sonarが最近発表したレポートでは、同社が主要なLLM 5つ、すなわちAnthropicのClaude Sonnet 4および3.7、OpenAIのGPT-4o、MetaのLlama 3.2 90B、オープンソースのOpenCoder-8Bを詳細に分析した。
このレポートでは、構文的に正しいコードの生成、技術的能力の発揮、さまざまなプログラミング言語への対応など、モデルの強みを異なる観点から比較している。
また、共通する弱点も明らかにしている。特に目立つのはセキュリティ意識の著しい欠如で、最高レベルの深刻度を持つ攻撃に対してソフトウェアを脆弱なままにする傾向、エンジニアリング規律の不足、乱雑なコードを生成しがちな点などが挙げられる。
リスク管理の重要性を浮き彫りにするもう1つの重要な発見は、LLMはどれも完全に同じではなく、それぞれに固有の癖や好み、セキュリティ上の盲点があるという事実だ。
人間の開発者にそれぞれ個性があるのと同様に、各モデルにも固有のスタイルがあり、レポートではこれを「コーディング・パーソナリティ」と呼んでいる。この違いは、人間の開発者がAIの生成物をレビュー、分析する方法に影響を及ぼし得る。
レポートでは、テストしたLLMについて、複雑さとコミュニケーション、冗長性、ドキュメントという3つの主要かつ測定可能な特性を特定した。
例えば、冗長なモデルは、比較的寡黙なモデルよりもタスクの実行に多くのコード行を生成するため、コードレビューがより複雑になる可能性がある。
同様に、冗長なモデルはより複雑なソリューションを生成する傾向がある。特定のタスクでは必要になる場合もあるが、より単純明快なアプローチを取るモデルに比べ、コードレビュー担当者には大きな認知的負荷がかかる。
テストしたモデルは、作業内容を説明するために提供するドキュメントの量に表れているように、さまざまなコミュニケーションスタイルも示した。
レポートによると、これらの指標を組み合わせることで、人間の開発者のタイプに相当するパーソナリティ・タイプが形成される。
- シニアアーキテクト（Claude Sonnet 4）。複雑なエンタープライズシステムの構築を得意とするが、その印象的なコードの陰に深刻なバグが潜んでいる可能性がある。
- 高速プロトタイパー（OpenCoder 8B）。猛烈な速さで、プロジェクトを迅速に始動させるのが得意だが、技術的負債を大量に生み出し、後から課題を引き起こす可能性がある。
- 果たされない期待（Llama 3.2 90B）。大きな可能性を秘めているものの、性能は中程度で、重大なセキュリティ上の盲点がある。
- 効率的なジェネラリスト（GPT-4o）。極端に冗長でも簡潔でもなく、さまざまな仕事に使えるうえ、最も深刻なセキュリティ問題は避ける傾向がある。ただし、不注意な面もあり、品質と信頼性を損なうミスを招く可能性がある。
- バランスの取れた前任者（Claude 3.7 Sonnet）。非常に機能的で優れたドキュメントを備えたコードを生成する一方、高深刻度の脆弱性を生み出すこともある。
これは、モデルごとに異なる強みと弱みがあることを見事に示している。どのLLMをどのプロジェクトに適用すべきかを決める際には、こうした特徴を知っておくことが非常に重要だ。重要なアプリケーションを任せるなら、 juniorプログラマーより先にシニアアーキテクトを信頼するのと同じである。
しかし同時に、開発者がAI生成コードを効果的かつ効率的にレビューするために必要なスキルを身に付けることの重要性も浮き彫りにしている。
AIのパーソナリティを管理するには、開発者のセキュリティ能力が必要
結局のところ、LLMにはメリットがあり、コードの改善を効率化できる一方、重要なのはソフトウェア開発ライフサイクル（SDLC）内でどれだけ慎重に管理されるかである。
リスクを確実に管理するには、開発者のセキュリティ能力を高めなければならない。
人間が関与していれば十分というわけではない。AIアシスタントによって加速された開発環境で、AI生成コードの信頼性を確保し、技術的負債を積み上げないための教育とスキルが必要になる。
同様に重要なのは、開発者がAIモデルに対して、セキュアなコードの生成と、AIの出力に対する適切なセキュリティレビューを促すようなプロンプトを作成できることだ。
AIモデルのコーディング・パーソナリティを理解することは役立つが、開発者のスキル向上は不可欠である。
リスクを低減し、ソフトウェアを安全にする最善の方法は、SDLCの最初から脆弱性を防ぐことだ。
生成されたコードの出所にかかわらず、セキュアコーディング、コードレビュー、テストを確実に行うには、開発者教育が不可欠である。
CISOは、目の前のタスクに対してリスクの低いモデルを優先するとともに、教育とスキル向上を通じて開発者を支援すべきだ。
LLMの「パーソナリティ」を考慮し、開発者のセキュリティ能力を徹底することで、組織はセキュリティ知識のギャップを埋め、技術的負債に対処し、自社のコードベースにおける増大するリスクの軽減に役立てられる。
この記事は Matias Madou博士（CTO兼共同創業者）Secure Code Warriorによる寄稿です。