要約
- セキュアソフトウェア開発フレームワークは、非決定的なAIコード生成、大量のエージェントコード、および新たなアクティブな敵対的攻撃面に対応するために進化する必要があります。
- 今後のSSDFの更新では、AIモデルが自らの確率的な出力を信頼性を持って自己認証できないため、自動化された独立した検証レイヤーを義務付けるべきです。
- AI生成コードのレビューにおいては、人間のレビュー能力を超える自動化されたワークフローを処理するために、サプライチェーン管理を拡大する必要があります。
- 決定論的なAIコードレビュー、SCA、およびCI検証を組み合わせることで、ソフトウェアが出荷される前に一貫したコード品質とセキュリティの結果を保証します。
セキュアソフトウェア開発フレームワークは、開発者がコードを書く世界のために設計されました。その世界は急速に変化しており、更新はその変化を反映する必要があります。
Sonarは、毎日700万人のソフトウェア開発者が扱う7,500億行以上のコードを分析しています。私たちは、AIが実際にソフトウェアの品質とセキュリティにどのような影響を与えているかを最前線で目の当たりにしています。NISTがAI技術を網羅するためにSP 800-218 (SSDF)を改訂する場合、理論上の懸念ではなく、現在の本番コードベースに見られるパターンに基づいた知見を提供したいと考えています。
要約：SSDFの現在のフレームワークは、決定論的なツール、人間が処理可能な規模のコード量、および安全なコーディングプラクティスを遵守できるよう訓練可能なソフトウェア開発者を前提としています。これらの前提はAIには当てはまりません。改訂では、3つの構造的な問題に対処し、それを既存の制御項目に対する具体的な変更へと変換する必要があります。
3つの構造的問題
1. 非決定性は単なる癖ではなく、カテゴリーの変化である
SSDFの既存のコントロールは、ツールが決定論的に動作することを前提としています。同じコードに対して同じテストスイートを2回実行すれば、同じ結果が得られます。この前提は、フレームワークがコードの検証、レビュー、テストを考える方法の基礎となっています。
AIはこの前提を覆します。昨日、安全で正しいコードを生成したプロンプトが、今日も同じように動作する保証はありません。これは特定のモデルの制限ではなく、確率的システムの構造的な特性です。その結果は明白です。コード生成ツールは、自身の出力を自己認証することができません。決定論的で独立した検証レイヤーは、単なるオプションではなく、現在のSSDFが当然視している決定論的な動作という前提に対する、技術的に有効な唯一の代替手段なのです。
同じ論理は、コードレビューアとして使用されるAIにも当てはまります。LLMが自身の出力をレビューする際には、体系的なコード分析とは根本的に異なる一貫性の問題や、自己レビューにおける盲点が報告されています。AIベースのレビューは、決定論的検証を補完するものとしては有用ですが、その代替にはなりません。SSDFはこの点を明確に述べるべきです。
2. 開発者によるレビューはエージェントの出力規模に対応できない
AIが生成したプルリクエストは、開発者が書いたものよりもはるかに大規模です。LLMによるパッチは、従来のツールよりも平均14倍多くのコードを変更し、エージェントワークフローはプロジェクトごとに追加される行数が3～5倍増加することと相関しています。すでに38％のソフトウェア開発者が、AI生成コードのレビューは開発者が書いたコードのレビューよりも労力がかかると報告しています。そして、Microsoftの研究は、多くの人が直感的に知っていることを裏付けています：
コードレビューの品質は、対象ファイル数が約20ファイルを超えると急激に低下します。これは、エージェントによるPRが通常、桁違いに超えてしまう閾値です。
これは人員の問題ではありません。これは、人間の速度でのコード生成を前提としたプログラミングフレームワークと、AIがチームがスプリントでリリースする量よりも多くのコードを午後のうちに生成できてしまうという現実との間の構造的な不一致です。ピアレビューを主要な品質ゲートとして想定するSSDFコントロールは、自動化されたコード検証ツールを明示的に考慮する必要があります。そのツールはレビューの補完ではなく、レビューを実行可能にするメカニズムなのです。
このボリュームの問題はサプライチェーンにも波及します。コードの生成速度が向上すると、単位時間あたりに導入される依存関係が増加します。AIを活用した脆弱性修正は、より多くのCVEを特定し、その結果としてより多くの更新やアップグレードを引き起こすことで、依存関係の変動をさらに加速させる可能性があります。言い換えれば、サプライチェーンリスクの中核となる課題はSSDF 1.0以来変わっていませんが、そのボリュームと速度は変化しています。既存のコントロール（PO.3、PS.3）は依然として適切なツールです。SSDFの更新は、AI主導の開発ペースに合わせて規模を拡大する必要があることを明確にしているに過ぎません。
3. AIは単なる信頼できないツールではなく、能動的な攻撃面である
最初の2つの問題は、AIが信頼できないことに関するものです。3つ目は、AIが悪用され得るということに関するものです。AIエージェントがコードリポジトリ、CI/CDシステム、およびデプロイメントパイプラインにアクセスできることで、SSDFが考慮していなかった敵対的な攻撃面が導入されます： プロンプトインジェクション（ファイル、チケット、APIレスポンスに隠された悪意のある指示により、エージェントに攻撃者が制御するアクションを実行させる）、セッションをまたぐメモリベースの権限昇格、およびセキュリティの微調整をすり抜けるように悪意を持って作成された入力を通じたバックドアの持続性。これらは単なる理論上の懸念ではなく、文書化された攻撃の分類です （AnthropicのAIエージェントのゼロトラスト、2026年5月参照）、エージェントシステムの制御は、この拡張された脅威モデルを反映すべきです。
特定のSSDF制御における意味
これら3つの構造的問題は、既存のSSDF言語のギャップに直接対応しています。更新が焦点を当てるべき箇所は以下の通りです：
PW.5（セキュアコーディングプラクティスに従ってソースコードを作成する）は、訓練可能な開発者を中心に設計されました。AIがコードを記述する場合、これは2つの異なる問題に分かれます。
第一に：コンテキストインジェクションが訓練に取って代わります。セキュアコーディングプラクティスは、生成前のコンテキストとしてAIエージェントに提供できます。ただし、これには意図的かつ構造化された取り組みが必要です。すなわち、アーキテクチャ上のルール、セキュリティ上の制約、および組織基準を、適切なタイミングでエージェントのプロンプトに組み込むことです。これは、組織が開発者を訓練する方法とは根本的に異なり、SSDFはこれをソフトウェア開発者訓練の類似例ではなく、独自の実装パスとして認識すべきです。
第二に：PW.7とPW.8は「推奨」から「必須」へと移行します。 よく構造化されたコンテキストの注入があったとしても、非決定性のため、生成ツールは与えられた基準に対する準拠を自己認証できません。したがって、AIが作成者である場合、コードレビュー（PW.7）とテスト（PW.8）は必須となります。
検証は多層的である必要があります。AIコードレビュー、SCA、またはCI検証といった異なる種類のレビューは、それぞれ他の方法ではカバーされない障害モードを網羅します。これは冗長性ではなく、生成速度において一貫性があり、監査可能で、再現可能な唯一の組み合わせです。
これは、ほとんどのソフトウェア開発者が依存しているセーフティネットが不十分であるため重要です。Sonar独自の調査（SonarQubeを使用して4,400件以上のAI生成コードの提出を分析）では、単体テストの合格がコードのセキュリティや品質と相関しないことが判明しました。同調査は、SSDFで明確に述べる価値のある広範なポイントを確認しています： 読みやすく、保守しやすいコードは、より安全である可能性が高いです。コード品質とセキュリティは別々の懸念事項ではなく、AIは両方を同時に、より緊急の課題としています。
コード検証のギャップは経験的に実証されています。Sonarのデータによると、検証されていないコーディングモデルは、分析対象となった100万行のコードごとに約1,200件のセキュリティ問題を発生させていることが示されています。ソフトウェア開発者の96％はAI生成コードを完全に信頼していませんが、コミット前に一貫して検証を行っているのはわずか48％に過ぎません（コード状態レポート）。SSDFの更新は、説得ではなく具体的な指針によってそのギャップを埋める機会となります。
NIST SSDFはEUサイバーレジリエンス法とどのように整合するか
SSDFの更新は、EUサイバーレジリエンス法の要件、特に脆弱性対応とセキュア開発の文書化に関して、意図的に整合を図る機会でもあります。SSDFに準拠する組織が、EU市場に出荷されるソフトウェアのために、重複したり矛盾したりするコンプライアンス作業を強いられるべきではありません。CRAの実施ガイダンスは積極的に策定されています。今すぐ整合性を組み込むことは、後で修正するよりもはるかに低コストです。
組織は出荷前にAI生成コードをどのように検証すべきか
これらすべての更新を通じて、組織の方針は、AIの使用状況を追跡することから、結果の検証へとシフトすべきです。使用状況の追跡（どのツールが、誰によって、いつ使用されたか）は基本ですが、EU AI法の対象となる組織にとっては十分ではありません。顧客が求めているのは、生成方法にかかわらず、コードが出荷前に定義されたセキュリティおよび品質基準を満たしていることを証明する結果保証です。
Sonarの「Guide-Verify-Solve」フレームワークは、生成前に適切なコンテキストを提供し、その後、決定論的な自動分析を適用して、的を絞った修正を可能にする方法を示しています。これが、結果検証が実際にどのように機能するかという例です。しかし、この原則は特定のフレームワークに依存するものではありません。どのような実装であれ、SSDFは、AIを活用した環境において、検証済みの結果が標準となることを確立する必要があります。
