システム開発の現場において、リリース直前の脆弱性診断で致命的な欠陥が見つかり、リリース延期や大規模な手戻りが発生した経験はないでしょうか。あるいは、運用開始後にセキュリティインシデントが発生し、その対応に追われる日々を過ごしていないでしょうか。
現代のサイバーセキュリティにおいて、システムが出来上がってから鍵をかけるような「境界防御」や「後付けの対策」だけでは、高度化する脅威や迅速なビジネス展開のスピードに対応しきれなくなっています。そこで必須となる知識が、「セキュリティバイデザイン（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）のような実装起因の脆弱性は、設計時の方針（プレースホルダやエスケープの統一など）に加え、後述のセキュアコーディングやSAST/DASTで潰していきます。
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
シフトレフト：コスト削減と品質向上の鍵
後工程ほど増える修正コスト
「シフトレフト（Shift Left）」とは、セキュリティ対策やテストの実施時期を、開発工程のタイムライン上で、できるだけ上流工程に移動させる考え方です。
開発プロセスの後半でバグや脆弱性が見つかるほど手戻りの範囲が広がり、その修正コストは大きく膨らみます。リリース後に発覚した場合のコストには、修正作業そのもののコストに加え、サービス停止による機会損失、顧客への損害賠償、ブランドイメージの毀損といった社会的コストが含まれます。
ゲートキーパー型からガードレール型へ
従来のセキュリティは、リリースの直前に設けられた関所（ゲートキーパー）として機能していました。「ここを通らなければリリースさせない」というスタンスは、開発スピードを重視する現代のアジャイル開発とは相性が悪く、開発チームとセキュリティチームの対立を生む原因となっていました。
シフトレフトのアプローチでは、セキュリティチームは「関所」ではなく「ガードレール」を提供します。開発者がガードレール（安全なフレームワーク、自動化されたチェックツール、ガイドライン）に沿って走る限り、自然と安全なコードを書きやすい環境を整備するのです。これにより、開発スピードを落とすことなく、高いセキュリティレベルを維持しやすくなります。
ただし、DevSecOpsは危険なリリースを素通りさせるという意味ではありません。リリース直前の手動審査だけに依存せず上流から支援したうえで、重大な脆弱性などのリスクが見つかれば、パイプラインに組み込んだ自動のセキュリティゲート等でリリースを止めます。
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の組み合わせで行われることが多いため、非常に重要なプロセスです。Apache Log4jの脆弱性（Log4Shell、CVE-2021-44228）のように、利用中のライブラリに既知の脆弱性が公表された際、影響を受けるアプリケーションを素早く特定できます。
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パッケージやライブラリの脆弱性をスキャンします。また、信頼できるレジストリからのみイメージをプルするように制御します。
情報処理安全確保支援士試験における出題ポイントと対策
情報処理安全確保支援士試験の科目B（旧午後、記述式）では、セキュリティバイデザインやDevSecOpsに関連する論点が、次のような事例の中で問われることがあります（例：令和7年度春期 午後（現・科目B）問1はサプライチェーンリスク管理を題材としています）。設問1(1)の解答例は「企画・設計工程からセキュリティ対策を組み込むという考え方」で、まさにセキュリティバイデザインを答えさせる設問でした。
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インジェクション。これを防ぐ根本的解決として最も推奨されるのが「プレースホルダ（バインド機構）の利用」です（IPAは、SQL文を文字列連結で組み立てる場合にリテラルを正しく構成する＝適切にエスケープすることも根本的解決に挙げていますが、漏れが起きにくいプレースホルダが推奨されます）。
文字列連結でSQL文を組み立てるのではなく、データベースエンジン側にあらかじめSQLの構造を伝え、変数を後から割り当てることで、入力値がSQLコマンドとして解釈されることを防ぎます。O/Rマッパーを使用する場合も、内部でプレースホルダが使われているかを確認する必要があります。
セッション管理の不備と対策
HTTPはステートレスなプロトコルであるため、WebアプリではセッションIDを用いて状態管理を行います。このセッションIDが推測可能であったり、奪取されたりすると、なりすまし（セッションハイジャック）が発生します。
セッション管理のベストプラクティス：
- セッションIDの生成：推測不可能な乱数を使用する（自作せず、言語やフレームワーク標準の機能を使う）
- Cookieの属性設定：
Secure属性：HTTPS通信時のみCookieを送信させるHttpOnly属性：JavaScriptからCookieを読めなくし、XSSが起きた際にセッションIDを読み取られる被害を抑える（XSS自体は防げない）SameSite属性：クロスサイトのリクエストでCookieを送るかどうかを制限する（Strict／Lax）。CSRF（クロスサイトリクエストフォージェリ）対策の補助になる
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で通知 → チケット管理システムにインシデントを起票
ここまでを自動化することで、セキュリティ担当者は「判断が必要な高度な分析」に集中することができ、検知から対応完了までの時間を大幅に短縮できます。
セキュリティ負債との戦い方
新しく作るシステムならセキュリティバイデザインを適用しやすいですが、多くの現場では「既に稼働している、継ぎ接ぎだらけのレガシーシステム」を抱えており、そこには未対応の脆弱性や不適切な設定といったセキュリティ負債が蓄積しています。
負債の可視化と優先順位付け
既存システムのセキュリティレベルを上げるには、まず「現状を知る」ことから始まります。
セキュリティ負債への対処手順：
- 資産台帳の整備：どこに何があるか（サーバー、ソフトウェア、データ）を把握する
- 脆弱性スキャンの実施：DASTツールやプラットフォーム診断を行い、リスクを洗い出す
- トリアージ（優先順位付け）：全ての脆弱性を一度に直すことは不可能です。CVSS（共通脆弱性評価システム。現在はv3.1とv4.0が併用されています）のスコアや、そのサーバーがインターネットに公開されているか、重要データを扱っているかなどを基準に、対応順位を決めます
段階的なモダナイゼーション
レガシーシステムを一気にリプレースするのはリスクが高すぎます。そこで、「ストラングラーフィグパターン（Strangler Fig Application）」などの手法を用い、機能を少しずつマイクロサービスとして切り出し、新しい基盤（クラウドやコンテナ）に移行させていきます。
新しく切り出した部分には最初からDevSecOpsのパイプラインを適用することで、徐々にシステム全体の健全性を高めていく戦略が有効です。クラウド移行やシステム更改を題材にした科目B（旧午後）の事例問題を読む際にも、こうした段階的な移行とセキュリティ対策の考え方が役立ちます。
セキュリティメトリクスの重要性
DevSecOpsを組織に定着させるには、セキュリティ活動の効果を可視化し、経営層を含めた関係者に説明できることが重要です。そのために活用されるのがセキュリティメトリクス（指標）です。
主要なセキュリティメトリクス
プロセスメトリクス：
- 自社コードへの混入（依存関係では脆弱性情報の公開）から検出されるまでの平均時間（MTTD：Mean Time To Detect）および検出から修正完了までの平均時間（MTTR：Mean Time To Remediate）
- CI/CDパイプラインでの自動テストカバレッジ率
- セキュアコーディング研修の受講率
成果メトリクス：
- 本番環境での脆弱性発見件数の推移
- セキュリティインシデント発生件数
- ペネトレーションテストでの検出脆弱性数
これらの指標を定期的にトラッキングすることで、DevSecOpsの取り組みがどれだけ効果を上げているかを客観的に評価できます。また、改善が必要な領域を早期に特定し、リソースを適切に配分することが可能になります。
コンプライアンスとの統合
セキュリティバイデザインとDevSecOpsは、単なる技術的な取り組みではなく、法規制やコンプライアンス要求への対応という側面も持ちます。
GDPR、個人情報保護法への対応
欧州のGDPR（一般データ保護規則）は第25条で「データ保護バイデザイン及びバイデフォルト（Data protection by design and by default）」を管理者の義務として定めており、システム設計段階からプライバシーを考慮する「Privacy by Design」の考え方を法的要求にしています。日本の個人情報保護法には同様の明文規定はありませんが、安全管理措置（第23条）などを満たすうえで、設計段階からの配慮が欠かせない点は共通です。これはセキュリティバイデザインと表裏一体の概念です。
具体的な対応例：
- 個人データの最小化：必要最小限のデータのみを収集する設計
- データ保持期間の設定：不要になったデータを自動的に削除する仕組み
- アクセスログの記録：誰がいつどのデータにアクセスしたかを追跡可能にする
金融業界のセキュリティ基準
金融機関ではFISC（公益財団法人金融情報システムセンター）の「金融機関等コンピュータシステムの安全対策基準・解説書」が、クレジットカード情報を扱う事業者ではPCI DSS（クレジットカード業界のセキュリティ基準。現行版はv4.0.1）への準拠が求められます。PCI DSSの要件6（安全なシステムとソフトウェアの開発と保守）のように、これらの基準には安全な開発に関する要求も含まれており、DevSecOpsのパイプラインに組み込むチェック項目を検討する際の拠り所になります。
試験対策としても、PCI DSSのような業界基準の名称と目的は押さえておきましょう。セキュリティバイデザインのアプローチは、こうしたコンプライアンス要求にも効率的に対応できる手法です。
理解度チェック：手戻りを最小化するDevSecOps実践 練習問題
本記事で解説した「セキュリティバイデザイン」や「DevSecOps」は、概念を理解するだけでなく、具体的な手法やツールと結びつけて覚えることが重要です。 以下の練習問題を通じて、知識が正しく定着しているか確認しましょう。解説には「なぜその選択肢が正解なのか（あるいは不正解なのか）」という理由も詳しく記載していますので、実務や試験で使える知識として活用してください。
まとめ：安全は「機能」ではなく「品質」である
セキュリティバイデザインとDevSecOpsは、単なるバズワードではなく、現代のソフトウェア開発において必須の生存戦略です。
セキュリティバイデザインは、「後から直す」という非効率な習慣を断ち切り、企画・要件定義・設計といった上流工程で安全性を担保することで、プロジェクト全体のリスクとコストを大きく削減します。
DevSecOpsは、それを自動化と文化によって継続的なものにし、ビジネスのスピードを落とさずに安全なサービスを提供し続けるためのエンジンとなります。
情報処理安全確保支援士試験においても、これらの概念は単なる用語暗記ではなく、「なぜそれが必要なのか」「導入することでどのようなメリット・デメリットがあるのか」という深い理解が問われます。
合格を目指す皆さんは、ぜひ「自分がCTOやセキュリティアーキテクトだったら、どうやって組織にセキュリティを浸透させるか？」という視点を持って学習を進めてください。その視点こそが、合格への近道であり、実務で活躍するための最強の武器となるはずです。
次は、DevSecOpsの文脈でますます重要性を増している「サプライチェーン攻撃とOSSの脆弱性管理」の記事で、現代のアプリケーション開発において避けて通れないOSSのリスクと、その適切な管理手法を学んでいきましょう。
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
