1. 背景

セキュア・バイ・デザインは、システムの企画・設計段階からセキュリティ要件を組み込む考え方である。

主な目的は以下のとおり。

• 開発後半での手戻りを削減する

• 脆弱性の作り込みを未然に防止する

• リリース後の修正コストを抑制する

• セキュリティを開発プロセスの一部として定着させる

この考え方は以前から提唱されてきたが、多くの開発現場では十分に定着していない。

2. セキュア・バイ・デザインの導入が進まなかった要因

導入が進まなかった主な要因は、以下の3点である。

2.1 セキュリティ人材の不足

すべての開発案件にセキュリティ専門家を継続的に配置することは難しい。

具体的には、以下の問題がある。

• セキュリティ専門家の人数が限られている

• 専門家の対応が重要案件やリリース前レビューに集中する

• 開発チームが必要な時点で専門家に相談できない

• 開発者や設計者のセキュリティ知識にばらつきがある

• 各開発チームが自律的に脅威分析やリスク判断を行うことが難しい

この結果、セキュリティ専門家は多数の案件をスポット的に支援する形となり、企画から実装まで継続的に関与しにくい。

2.2 セキュリティ活動に必要な工数の不足

セキュア・バイ・デザインを実践するには、開発工程ごとに複数のセキュリティ活動を実施する必要がある。

主な活動は以下のとおり。

• 要件定義時のリスク分析

• 脅威モデリング

• セキュリティ要件の定義

• アーキテクチャレビュー

• 設計レビュー

• セキュアコーディングの確認

• ソースコードや設定値の確認

• セキュリティ要件の実装確認

これらの活動には、専門家と開発者の双方の時間が必要となる。

開発現場では、納期、機能、コストが優先されることが多く、セキュリティ活動が追加作業として扱われやすい。

その結果、以下の対応が生じる。

• セキュリティレビューが省略される

• レビュー対象が重要機能のみに限定される

• セキュリティ対応が開発後半に先送りされる

• リリース直前の脆弱性診断に依存する

• 発見された問題の修正が困難になる

2.3 セキュリティ要件を設計・実装へ変換する専門性の不足

セキュリティ方針や基準は、一般的かつ抽象的な内容で記載されることが多い。

一方、開発現場では、それらを個別システムの設計や実装に変換する必要がある。

変換対象には以下が含まれる。

• システムアーキテクチャ

• データ構造

• データフロー

• API

• 認証

• 認可

• 暗号化

• ログ

• クラウド設定

• ネットワーク設定

• ソースコード

この変換には、セキュリティと開発技術の双方に関する知識が必要である。

さらに、案件ごとに以下の判断も求められる。

• どの脅威を優先するか

• どの対策を必須とするか

• どのリスクを許容するか

• どの対策をどの工程で実施するか

• どの担当者が判断責任を負うか

このため、チェックリストや共通基準を整備しても、個別案件への適用段階で判断が止まりやすい。

3. 従来の開発現場で生じていた問題

人材、工数、専門性の制約により、セキュリティ活動は以下の形態に偏りやすかった。

• セキュリティ専門部署によるスポットレビュー

• 開発終盤の脆弱性診断

• リリース前のチェックリスト確認

• 問題発見後の修正対応

この運用では、設計段階でリスクを低減するよりも、完成後に問題を発見して修正する対応が中心となる。

その結果、セキュア・バイ・デザインは理念として認識されても、日常の開発プロセスには十分に組み込まれなかった。

4. 生成AIが制約を緩和する可能性

近年の生成AIは、設計文書、アーキテクチャ情報、ソースコード、設定情報などを横断的に処理できるようになっている。

生成AIを開発工程に組み込むことで、以下の支援が可能になる。

4.1 開発者への即時支援

• セキュアコーディング方法を提示する

• コード上の問題候補を指摘する

• 修正案を提示する

• 使用している技術に応じた注意点を説明する

• 開発者からの質問に随時回答する

4.2 脅威分析と設計レビューの支援

• システム構成から脅威候補を抽出する

• データフロー上のリスクを整理する

• 認証・認可設計の不足を指摘する

• APIやクラウド設定の確認観点を提示する

• 脅威モデリングの初期案を作成する

• 設計レビュー項目を生成する

4.3 セキュリティ要件の具体化

• 社内規程やセキュリティ基準を読み込む

• システム特性に応じた要件へ変換する

• 要件を設計項目や実装項目へ分解する

• 要件と設計・実装の対応関係を整理する

• 要件の漏れや重複を確認する

4.4 セキュリティ活動の反復実行

• 設計変更の都度、レビューを実施する

• コード変更の都度、問題候補を確認する

• 開発工程全体で一貫した観点を適用する

• 多数の案件に対して同時に支援する

• 専門家が直接関与できない案件にも基本的な知見を提供する

5. 生成AIによって期待される変化

生成AIの活用により、以下の変化が期待される。

6. 生成AIの意義

生成AIの意義は、セキュア・バイ・デザインという考え方を新たに生み出すことではない。

生成AIは、これまで実行が難しかった以下の活動を、開発現場で継続的かつ反復的に実施するための手段となる。

• 専門家の知識を多数の案件へ展開する

• 開発者のセキュリティ判断を補助する

• 抽象的な基準を具体的な要件へ変換する

• 設計や実装の変更に応じてレビューする

• 工数上の理由で省略されていた確認を実行する

したがって、生成AIは、人材、工数、専門性の制約を緩和し、セキュア・バイ・デザインを日常の開発プロセスへ組み込むための実装基盤となり得る。

7. 生成AI活用の前提条件

生成AIの導入だけで、セキュア・バイ・デザインが自動的に実現するわけではない。

実務で利用するためには、以下の条件を整備する必要がある。

7.1 出力品質の管理

• AIの出力を事実として扱わない

• 誤検知と見逃しを前提に検証する

• 重要な判断には人による確認を入れる

• AIが判断した根拠を確認可能にする

7.2 システム固有情報の提供

• システム構成

• 利用技術

• データの重要度

• 想定利用者

• 外部接続

• 脅威モデル

• セキュリティ要件

• リスク許容度

生成AIへ十分な前提情報を与えなければ、一般論に基づく回答にとどまる可能性がある。

7.3 機密情報の管理

• ソースコードの入力可否を定める

• 設計文書の入力範囲を定める

• 入力データの保存条件を確認する

• 学習利用の有無を確認する

• アクセス権限を管理する

• ログと監査証跡を確保する

7.4 判断責任の明確化

• AIが提案する範囲を定義する

• 人が承認する範囲を定義する

• 開発者、セキュリティ担当者、システム責任者の役割を明確にする

• 残余リスクの受容者を明確にする

7.5 開発プロセスへの統合

• 要件定義

• 設計

• 実装

• テスト

• リリース

• 運用

• 変更管理

生成AIの利用ポイントを各工程に定義し、既存の開発標準、レビュー、承認、品質管理と接続する必要がある。

8. 結論

生成AIは、セキュア・バイ・デザインの実現を妨げてきた以下の制約を緩和する可能性がある。

1. セキュリティ専門家の人数が限られている

2. 開発工程でセキュリティ活動に割ける時間が不足している

3. セキュリティ方針を個別の設計・実装へ変換することが難しい

生成AIを開発工程に組み込むことで、専門知識の展開、要件の具体化、設計レビュー、実装確認を継続的に実施できる可能性がある。

生成AIの出力品質、機密情報管理、判断責任、人による検証、開発プロセスとの統合を整備することで、セキュア・バイ・デザインを理念から実務へ移行させる有力な手段となる。

生成AIへの入力用途をさらに重視する場合は、次段階として「前提」「課題」「因果」「期待効果」「制約」をJSONやYAMLに近い形式へ分解する方法も有効です。