システム開発の現場において、リリース直前の脆弱性診断で致命的な欠陥が見つかり、リリース延期や大規模な手戻りが発生した経験はないでしょうか。あるいは、運用開始後にセキュリティインシデントが発生し、その対応に追われる日々を過ごしていないでしょうか。
現代のサイバーセキュリティにおいて、システムが出来上がってから鍵をかけるような「境界防御」や「後付けの対策」だけでは、高度化する脅威や迅速なビジネス展開のスピードに対応しきれなくなっています。そこで必須となる知識が、「セキュリティバイデザイン（Security by Design）」と「DevSecOps」です。
本記事では、企画・設計段階からセキュリティを組み込むための思考法と、それを開発プロセスに統合して自動化するDevSecOpsについて、その概念から具体的な導入手法、試験で問われるポイントまでを網羅的に解説します。これらを理解することは、単に試験に合格するためだけでなく、安全で信頼性の高いシステムアーキテクトとしての必須スキルとなります。
セキュリティバイデザイン：手戻りを防ぐ「上流」からの防御
セキュリティバイデザインとは
セキュリティバイデザイン（Security by Design）とは、情報セキュリティをシステムの企画・設計段階から確保するための方策です。IPA（独立行政法人情報処理推進機構）も「情報セキュリティバイデザインガイドライン」を公開しており、我が国のシステム開発におけるデファクトスタンダードとなりつつあります。
従来のウォーターフォール型開発では、要件定義、設計、実装、テストが終わった後の「運用テスト」や「受入テスト」のフェーズで初めてセキュリティ診断（脆弱性診断）を行うケースが散見されました。しかし、この段階でアーキテクチャに起因する重大な欠陥が発覚した場合、設計からやり直す必要が生じます。この手戻りコストは、設計段階で修正する場合に比べて数十倍から数百倍に膨れ上がるとされています。
セキュリティバイデザインは、この手戻りを防ぐため、「後付け」ではなく「作り込み」としてセキュリティを実装するアプローチです。
企画・要件定義フェーズでのセキュリティ対策
セキュリティバイデザインの第一歩は、要件定義です。ここでは、システムが守るべき情報資産を特定し、その重要度（機密性・完全性・可用性）に応じたセキュリティレベルを定義します。
要件定義で検討すべき項目：
- 守るべき資産の洗い出し：顧客情報、決済情報、技術ノウハウなど、漏洩や改ざんが許されないデータを特定します
- 脅威の想定：誰が（外部の攻撃者、内部の不正者）、どのような目的で攻撃してくるかを想定します
- セキュリティ要件の策定：パスワードの複雑さ要件、多要素認証の導入、ログの保存期間、バックアップ頻度などを機能要件および非機能要件として明文化します
この段階で「どのような認証方式を採用するか」「データはどのレベルで暗号化するか」を決定しておくことで、後の工程でのブレを防ぐことができます。
設計フェーズでの脅威分析（Threat Modeling）
設計段階では、作成したアーキテクチャに対して「脅威分析（Threat Modeling）」を行います。これは、攻撃者の視点に立ち、システムのどこに弱点があるかを机上でシミュレーションするプロセスです。
代表的な手法としてマイクロソフトが提唱するSTRIDEモデルがあります。
STRIDEの6つの脅威分類：
- S (Spoofing：なりすまし)：認証機能の不備を突く
- T (Tampering：改ざん)：データの整合性を損なう
- R (Repudiation：否認)：ログ不足により「誰がやったか」を追跡できない
- I (Information Disclosure：情報漏洩)：暗号化不備やアクセス制御ミス
- D (Denial of Service：サービス拒否)：DoS攻撃への耐性不足
- E (Elevation of Privilege：特権昇格)：一般ユーザーが管理者権限を奪取する
設計書レビューの段階でSTRIDEに基づいたチェックを行うことで、SQLインジェクションやクロスサイトスクリプティング（XSS）といった脆弱性が入り込む余地を、コーディング前に極小化することが可能になります。
シフトレフト：コスト削減と品質向上の鍵
修正コストの指数関数的増加
「シフトレフト（Shift Left）」とは、セキュリティ対策やテストの実施時期を、開発工程のタイムライン上で、できるだけ上流工程に移動させる考え方です。
開発プロセスの後半でバグや脆弱性が見つかるほど、その修正コストは指数関数的に増大します。リリース後に発覚した脆弱性の修正コストは、設計段階での修正に比べて100倍以上かかるというデータもあります。これには、修正作業そのもののコストに加え、サービス停止による機会損失、顧客への損害賠償、ブランドイメージの毀損といった社会的コストが含まれます。
ゲートキーパー型からガードレール型へ
従来のセキュリティは、リリースの直前に設けられた関所（ゲートキーパー）として機能していました。「ここを通らなければリリースさせない」というスタンスは、開発スピードを重視する現代のアジャイル開発とは相性が悪く、開発チームとセキュリティチームの対立を生む原因となっていました。
シフトレフトのアプローチでは、セキュリティチームは「関所」ではなく「ガードレール」を提供します。開発者がガードレール（安全なフレームワーク、自動化されたチェックツール、ガイドライン）に沿って走る限り、自然と安全なコードが書ける環境を整備するのです。これにより、開発スピードを落とすことなく、高いセキュリティレベルを維持することが可能になります。
DevSecOps：開発と運用の融合にセキュリティを統合する
DevOpsの限界とSecの必要性
DevOpsは、開発（Development）と運用（Operations）が連携し、ビジネス価値を迅速にユーザーへ届けるための文化および手法です。頻繁なリリース、自動化されたテスト、継続的な改善が特徴ですが、ここに「セキュリティ」の観点が欠けていると、高速で脆弱なシステムを量産することになりかねません。
そこで生まれたのがDevSecOpsです。DevOpsの無限ループの中に「Security」を統合し、開発・セキュリティ・運用の三者が責任を共有します。スローガンは「Security is everyone's responsibility（セキュリティは全員の責任）」です。
CI/CDパイプラインへのセキュリティ実装
DevSecOpsを実現する技術的な中核は、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインへのセキュリティ検査の自動組み込みです。人間が手動でチェックを行っていては、1日に何度もリリースを行うようなスピード感には対応できません。
パイプラインに組み込む主要ツール
1. SAST（Static Application Security Testing：静的解析）
ソースコードをコンパイル前、あるいはビルド時に解析し、脆弱なコードパターン（例：安全でない関数の使用、ハードコードされたパスワード）を検出します。
- メリット：実行環境が不要で、開発の早い段階（コミット時など）で発見できる
- デメリット：誤検知（False Positive）が多く、実際の動作環境に依存する脆弱性は発見しにくい
2. SCA（Software Composition Analysis：ソフトウェア構成分析）
利用しているオープンソースソフトウェア（OSS）やライブラリに既知の脆弱性（CVE）が含まれていないかを確認します。現代のアプリケーション開発はOSSの組み合わせで行われることが多いため、非常に重要なプロセスです。Log4jのようなライブラリの脆弱性を即座に検知できます。
3. DAST（Dynamic Application Security Testing：動的解析）
テスト環境で実際にアプリケーションを稼働させ、外部から疑似攻撃を行うことで脆弱性を検出します。
- メリット：実際の稼働状態でのみ現れる脆弱性や、設定ミスを発見できる。誤検知が比較的少ない
- デメリット：実行環境が必要であり、スキャンに時間がかかるため、毎回のビルドで実施するのは難しい場合がある
4. IAST（Interactive Application Security Testing：対話型解析）
SASTとDASTのメリットを組み合わせた手法です。アプリケーション内部にエージェントを組み込み、実行時の挙動を監視しながら脆弱性を分析します。
コンテナセキュリティとIaC
DevSecOpsの文脈では、アプリケーションコードだけでなく、インフラストラクチャのセキュリティも重要です。
IaC（Infrastructure as Code）スキャン
TerraformやCloudFormationなどのインフラ構成コードを解析し、S3バケットの公開設定ミスや、過剰な権限付与などをデプロイ前に検知します。
コンテナイメージスキャン
Dockerイメージに含まれるOSパッケージやライブラリの脆弱性をスキャンします。また、信頼できるレジストリからのみイメージをプルするように制御します。
SC試験における出題ポイントと対策
情報処理安全確保支援士試験において、セキュリティバイデザインとDevSecOpsは午後試験（記述式）で頻出のテーマです。特に以下のようなシチュエーションで問われます。
1. サプライチェーンリスクとOSS管理
「開発したWebアプリで使用しているライブラリに脆弱性が見つかった」というシナリオです。ここでは、SCAツールの導入や、SBOM（Software Bill of Materials：ソフトウェア部品表）の管理が正解の鍵となります。OSSのバージョン管理、脆弱性情報の収集フロー（JVNやNVDの活用）についての理解が問われます。
2. アジャイル開発におけるセキュリティ
「開発スピードを優先したいが、セキュリティも担保したい」というジレンマに対する解決策を問われます。CI/CDパイプラインにSAST/DASTを組み込むことや、開発者へのセキュリティ教育、セキュアコーディング規約の策定などが解答要素になります。
3. クラウドシフトと責任共有モデル
AWSやAzureなどのクラウドサービスを利用する場合、クラウド事業者が提供するセキュリティ機能（マネージドWAFやIAM）を設計段階でどう組み込むかが問われます。「クラウドなら安全」と過信せず、責任共有モデルに基づき、利用者側で設定すべきアクセス制御や暗号化を設計段階で定義できているかがポイントです。
組織論としてのDevSecOps
DevSecOpsの導入は、ツールを入れるだけでは完了しません。最も難しいのは「組織文化の変革」です。
サイロの破壊
開発（Dev）、運用（Ops）、セキュリティ（Sec）がそれぞれのサイロ（縦割り組織）に閉じこもっていては機能しません。開発者は「機能を作れば終わり」、セキュリティ担当は「ダメ出しをするだけ」という関係性を打破し、共通のチャットツール（SlackやTeams）でリアルタイムに連携し、問題を早期に解決する文化が必要です。
セキュリティチャンピオンの育成
セキュリティチームの人員は常に不足しがちです。そこで、各開発チームの中に「セキュリティチャンピオン」と呼ばれる、セキュリティに強い関心を持つ開発者を任命し、彼らを橋渡し役として育成する手法が注目されています。彼らがチーム内でのレビューや相談役を担うことで、セキュリティチームの負荷を下げつつ、現場のセキュリティレベルを底上げできます。
セキュアコーディングの具体的実践
セキュリティバイデザインを実装レベルに落とし込む際、避けて通れないのが「セキュアコーディング」です。設計段階でいくら素晴らしいセキュリティ要件を定義しても、実装者が脆弱なコードを書いてしまえば全てが水泡に帰します。
入力値検証（バリデーション）の鉄則
「全ての入力値は悪意があると思え」。これがセキュアコーディングの第一原則です。
Webアプリケーションにおいて、クライアントサイド（JavaScriptなど）でのバリデーションは、ユーザビリティ向上には役立ちますが、セキュリティ対策としては不十分です。攻撃者はブラウザの検証を容易にバイパスしてHTTPリクエストを送信できるからです。したがって、必ずサーバーサイドでの厳格な入力チェックが必要です。
検証方式の選択：
- ホワイトリスト方式：許可する文字種、長さ、形式を定義し、それに合致するものだけを受け入れる
- ブラックリスト方式：危険な文字列（例：
<script>）を拒否する（※抜け穴ができやすいため、ホワイトリスト方式が推奨）
SQLインジェクションの根絶
IPAの「安全なウェブサイトの作り方」でも長年トップに挙げられるSQLインジェクション。これを防ぐ唯一かつ絶対の解は「プレースホルダ（バインド機構）の利用」です。
文字列連結でSQL文を組み立てるのではなく、データベースエンジン側にあらかじめSQLの構造を伝え、変数を後から割り当てることで、入力値がSQLコマンドとして解釈されることを防ぎます。O/Rマッパーを使用する場合も、内部でプレースホルダが使われているかを確認する必要があります。
セッション管理の不備と対策
HTTPはステートレスなプロトコルであるため、WebアプリではセッションIDを用いて状態管理を行います。このセッションIDが推測可能であったり、奪取されたりすると、なりすまし（セッションハイジャック）が発生します。
セッション管理のベストプラクティス：
- セッションIDの生成：推測不可能な乱数を使用する（自作せず、言語やフレームワーク標準の機能を使う）
- Cookieの属性設定：
Secure属性：HTTPS通信時のみCookieを送信させるHttpOnly属性：JavaScriptからのCookieアクセスを禁止し、XSSによるセッションID盗難を防ぐSameSite属性：CSRF（クロスサイトリクエストフォージェリ）対策として、他サイトからのリクエスト時にCookieを送らない設定を行う
DevSecOpsにおける可観測性（Observability）
DevSecOpsは「リリースして終わり」ではありません。運用フェーズ（Ops）における監視も重要なセキュリティ活動です。従来の「死活監視」や「リソース監視」に加え、「セキュリティ可観測性（Security Observability）」が求められます。
ログ管理とSIEM
システムが出力する膨大なログは、攻撃の予兆や痕跡を知るための重要な手がかりです。しかし、ログがサーバーごとに散在していては、横断的な分析ができません。
DevSecOps環境では、アプリケーションログ、Webサーバーログ、DBログ、ネットワーク機器のログをリアルタイムに集約し、相関分析を行うSIEM（Security Information and Event Management）の活用が有効です。
例えば、「短期間に複数回のログイン失敗（認証ログ）」があり、その直後に「データベースからの大量データ抽出（DBログ）」が発生した場合、SIEMはこれを「パスワードクラックに成功し、情報を持ち出した可能性が高い」としてアラートを発報します。
SOARによる対応の自動化
さらに進んだ組織では、SOAR（Security Orchestration, Automation and Response）を導入しています。これは、SIEMが検知したアラートに対し、あらかじめ定義した手順（Playbook）に従って自動対応を行う仕組みです。
SOAR自動対応の例：
不審なIPアドレスからのアクセスを検知 → ファイアウォールでそのIPを自動ブロック → 管理者にSlackで通知 → チケット管理システムにインシデントを起票
ここまでを自動化することで、セキュリティ担当者は「判断が必要な高度な分析」に集中することができ、対応速度（MTTR：Mean Time To Response）を劇的に短縮できます。
セキュリティ負債との戦い方
新しく作るシステムならセキュリティバイデザインを適用しやすいですが、多くの現場では「既に稼働している、継ぎ接ぎだらけのレガシーシステム」、すなわちセキュリティ負債を抱えています。
負債の可視化と優先順位付け
既存システムのセキュリティレベルを上げるには、まず「現状を知る」ことから始まります。
セキュリティ負債への対処手順：
- 資産台帳の整備：どこに何があるか（サーバー、ソフトウェア、データ）を把握する
- 脆弱性スキャンの実施：DASTツールやプラットフォーム診断を行い、リスクを洗い出す
- トリアージ（優先順位付け）：全ての脆弱性を一度に直すことは不可能です。CVSS（共通脆弱性評価システム）のスコアや、そのサーバーがインターネットに公開されているか、重要データを扱っているかなどを基準に、対応順位を決めます
段階的なモダナイゼーション
レガシーシステムを一気にリプレースするのはリスクが高すぎます。そこで、「ストラングラーパターン（Strangler Pattern）」などの手法を用い、機能を少しずつマイクロサービスとして切り出し、新しい基盤（クラウドやコンテナ）に移行させていきます。
新しく切り出した部分には最初からDevSecOpsのパイプラインを適用することで、徐々にシステム全体の健全性を高めていく戦略が有効です。これは、SC試験の午後問題で「レガシーシステムのクラウド移行とセキュリティ対策」というテーマで出題されるシナリオとも合致します。
セキュリティメトリクスの重要性
DevSecOpsを組織に定着させるには、セキュリティ活動の効果を可視化し、経営層を含めた関係者に説明できることが重要です。そのために活用されるのがセキュリティメトリクス（指標）です。
主要なセキュリティメトリクス
プロセスメトリクス：
- 脆弱性の検出から修正までの平均時間（MTTD：Mean Time To Detect、MTTR：Mean Time To Remediate）
- CI/CDパイプラインでの自動テストカバレッジ率
- セキュアコーディング研修の受講率
成果メトリクス：
- 本番環境での脆弱性発見件数の推移
- セキュリティインシデント発生件数
- ペネトレーションテストでの検出脆弱性数
これらの指標を定期的にトラッキングすることで、DevSecOpsの取り組みがどれだけ効果を上げているかを客観的に評価できます。また、改善が必要な領域を早期に特定し、リソースを適切に配分することが可能になります。
コンプライアンスとの統合
セキュリティバイデザインとDevSecOpsは、単なる技術的な取り組みではなく、法規制やコンプライアンス要求への対応という側面も持ちます。
GDPR、個人情報保護法への対応
欧州のGDPR（一般データ保護規則）や日本の個人情報保護法では、システム設計段階からプライバシーを考慮する「Privacy by Design」が求められています。これはセキュリティバイデザインと表裏一体の概念です。
具体的な対応例：
- 個人データの最小化：必要最小限のデータのみを収集する設計
- データ保持期間の設定：不要になったデータを自動的に削除する仕組み
- アクセスログの記録：誰がいつどのデータにアクセスしたかを追跡可能にする
金融業界のセキュリティ基準
金融機関では、FISC（金融情報システムセンター）の安全対策基準や、PCI DSS（クレジットカード業界のセキュリティ基準）への準拠が求められます。これらの基準は、DevSecOpsのパイプラインに組み込むべきチェック項目を明確に示しています。
SC試験では、「特定の業界規制に準拠したシステム開発を行う場合、どのようなセキュリティ対策が必要か」という形で出題されることがあります。セキュリティバイデザインのアプローチは、こうしたコンプライアンス要求にも効率的に対応できる手法です。
理解度チェック：手戻りゼロを実現するDevSecOps実践 練習問題
本記事で解説した「セキュリティバイデザイン」や「DevSecOps」は、概念を理解するだけでなく、具体的な手法やツールと結びつけて覚えることが重要です。 以下の練習問題を通じて、知識が正しく定着しているか確認しましょう。解説には「なぜその選択肢が正解なのか（あるいは不正解なのか）」という理由も詳しく記載していますので、実務や試験で使える知識として活用してください。
まとめ：安全は「機能」ではなく「品質」である
セキュリティバイデザインとDevSecOpsは、単なるバズワードではなく、現代のソフトウェア開発において必須の生存戦略です。
セキュリティバイデザインは、「後から直す」という非効率な習慣を断ち切り、設計という最上流工程で安全性を担保することで、プロジェクト全体のリスクとコストを劇的に削減します。
DevSecOpsは、それを自動化と文化によって継続的なものにし、ビジネスのスピードを落とさずに安全なサービスを提供し続けるためのエンジンとなります。
情報処理安全確保支援士試験においても、これらの概念は単なる用語暗記ではなく、「なぜそれが必要なのか」「導入することでどのようなメリット・デメリットがあるのか」という深い理解が問われます。
合格を目指す皆さんは、ぜひ「自分がCTOやセキュリティアーキテクトだったら、どうやって組織にセキュリティを浸透させるか？」という視点を持って学習を進めてください。その視点こそが、合格への近道であり、実務で活躍するための最強の武器となるはずです。
次回の記事では、DevSecOpsの文脈でますます重要性を増している「サプライチェーン攻撃とOSSの脆弱性管理」について解説します。現代のアプリケーション開発において避けて通れないOSSのリスクと、その適切な管理手法を学んでいきましょう。