セキュリティソリューション導入 / 
運用支援 / 監視サービス
脅威トレンド

SBDの基本方針

前出のガイドラインには、SBDの実施にあたり、単に表面的なセキュリティ対策を施すだけではなく、SBDの根底にある考え方（基本方針）を理解することの重要性が説かれています。
ここではガイドラインに沿ってSBDの基本方針について説明します。

SBDの実践

独立行政法人情報処理推進機構（IPA）が発行している「セキュリティ・バイ・デザイン導入指南書」では、OWASP SAMM 2.0をベースにSBDの実践方法が具体的に紹介されています。
SAMM（Software Assurance Maturity Model）は、ソフトウェアセキュリティ対策のための戦略の策定・実施を支援するフレームワークです。
SAMMは５つのビジネス機能に対して成熟度を定義していますが、「設計（Design）」にフォーカスして上流工程で実施すべき「脅威分析」「セキュリティ要件」「セキュリティアーキテクチャー」の取り組みについて解説しています。

• 1脅威分析

  ソフトウェアが直面する脅威や想定される攻撃を明らかにし、どの程度のリスクが発生するかを分析します。

• 2セキュリティ要件

  ソフトウェア自体のセキュアな動作を定義します。システムの要件には一般的に機能要件と可用性、保守性、性能などの非機能要件がありますが、セキュリティ要件はシステムを安全に運用するために必要な目標を定義する非機能要件です。

• 3セキュリティアーキテクチャー

  SAMMではフレームワークやデザインパターンを利用することを推奨しています。これは、スクラッチで作った新規のソースコードよりも、広く普及している信頼されたプラットフォームやライブラリの方が信頼できるという考え方に基づいています。

セキュリティ・バイ・デザインとDevSecOps（デブセックオプス）

SBDと似た考え方にDevSecOpsがあります。DevSecOpsはDevOps（デブオプス）にセキュリティ要素を組み込んだ進化形です。
DevOpsは、Development（開発）とOperations（運用）を組み合わせた言葉で、ソフトウェア開発ライフサイクルにおける開発チームと運用チームの連携を強化し、迅速かつ高品質なソフトウェアリリースを実現するための手法や文化です。
DevOpsでは、開発と運用のサイロ化を解消し、コラボレーションを促進させ、その結果としてソフトウェアのリリースサイクルを短縮しつつ、ソフトウェアの品質を安定させることを目的にしています。
その目的を達成するために、自動化のためのツールやプロセスを活用し、継続的インテグレーション（CI：Continuous Integration）や継続的デリバリー（CD：Continuous Delivery）を実践します。
つまり、DevSecOpsとは、開発（Development）、セキュリティ（Security）、運用（Operations）を統合し、システムのライフサイクル全体を通してセキュリティを継続的に確保するアプローチのことです。
DevSecOpsでは、セキュリティを「全員の責任」と位置づけ、自動化ツールやプロセスを活用して、迅速かつ安全なシステム開発・運用を実現します。SBDの考え方をDevSecOpsのプロセスに組み込むことで、より効率的かつ効果的なセキュリティ対策が可能になります。