セキュアソフトウェア開発ライフサイクル（SSDLC）

重要な機能を備えたアプリケーションでは、セキュリティが重要な要素となります。悪意ある攻撃者からデータベースを保護するようなシンプルな対策から、プラットフォームに取り込む前に条件を満たした見込み顧客に不正検知処理を適用するような複雑な対策まで、さまざまです。

SDLCの各フェーズ

ソフトウェア開発ライフサイクル（SDLC）は、ソフトウェアアプリケーションの構築方法を示すものです。通常、次のフェーズで構成されます。

• 要件の収集

• 設計の指針とするための要件の分析

• 要件に基づく新機能の設計

• 新機能の開発（要件を満たすコードの作成）

• 新機能のテストと検証—要件を満たしていることを確認

• 新しいプロジェクトのデプロイ

リリース後の機能の保守と進化

SDLCの7つのフェーズ

SDLCの手法：

アジャイル開発：

アジャイルSDLC開発では、大規模で一枚岩のリリースを、2〜3週間のスプリントで実施する複数の小規模なリリースに分割し、自動化を活用してアプリケーションを構築・検証します。これにより、企業はより迅速に反復開発を進められます。ウォーターフォール型アプリケーションに見られる、頻度の低い大規模なデプロイとは異なり、アジャイル開発では1日に複数回新機能をリリースし、ソフトウェアを一度に完成させるのではなく段階的に構築することがよくあります。

ウォーターフォール開発：

ウォーターフォール型のSDLCモデルは、初期に登場した、最もよく知られているSDLC手法の一つであり、SDLCの各フェーズの基礎となりました。1970年に開発されたこのフェーズは、現在も大部分が変わっていませんが、ソフトウェアエンジニアリングの実践には大きな変化があり、ソフトウェアの作成方法は再定義されてきました。

セキュアSDLCが重要な理由

セキュリティはSDLCのあらゆるフェーズに関わるものであり、開発者がソフトウェアの要件を実装する際には、常に念頭に置く必要があります。専任の取り組みと適切なSDLCセキュリティソリューションがあれば、本番環境へのデプロイ前に、SDLCパイプラインでセキュリティ上の問題に対処できます。これにより、アプリでセキュリティ脆弱性が見つかるリスクを抑え、問題が発見された場合の影響も最小限に抑えられます。

セキュアSDLCの目的は、ペネトレーションテストなど従来のセキュリティチェックを完全になくすことではありません。むしろ、開発者の責任範囲にセキュリティを組み込み、開発者が最初から安全なアプリケーションを構築できるようにすることです。

SDLCとアプリケーションセキュリティ

 SDLCのこの段階で発見された問題の修正には、プロセスの早い段階で修正する場合と比べて最大100倍のコストがかかることがあります 

SDLCの早い段階でセキュリティ対策を取り入れることで、開発者は潜在的なセキュリティ問題を事前に特定して対処でき、開発プロセスの後半で脆弱性を修正するコストを大幅に削減できます。 

セキュアソフトウェア開発ライフサイクルのプロセスとは？

SDLCにセキュリティを組み込むと、ソフトウェア開発プロセスのすべてのフェーズに影響します。セキュリティ上の問題がデプロイ済みのアプリケーションに現れるまで待つより、はるかに効率的で、コストも抑えられます。セキュアソフトウェア開発ライフサイクルのプロセスでは、SDLCの各フェーズにセキュリティを組み込みます。

SDLCのあらゆるフェーズにセキュリティを組み込むには、まず全員がその意識を持つことが大切です。一方、セキュリティ上の考慮事項や関連タスクは、SDLCのフェーズによって大きく異なります。

セキュアソフトウェア開発ライフサイクルの5つのフェーズ

SDLCの各フェーズで、アプリケーション全体のセキュリティに貢献する必要があります。その方法はフェーズごとに異なりますが、重要なのは、ソフトウェア開発ライフサイクルのセキュリティをチーム全員が常に意識することです。会員更新ポータルを開発するチームを例に、セキュアソフトウェア開発ライフサイクルを見ていきましょう。

フェーズ1：要件

この初期段階では、さまざまなステークホルダーから新機能の要件を収集します。新しいリリースに向けて機能要件を集める際に、セキュリティ上の考慮事項を特定することが重要です。

• 機能要件の例：ユーザーは、会員資格を更新する前に連絡先情報を確認できる必要がある。

• セキュリティ上の考慮事項の例：ユーザーには自分自身の連絡先情報だけが表示され、他のユーザーの情報は表示されないようにする。

フェーズ2：設計

このフェーズでは、対象となる要件を、実際のアプリケーション上でどのように実現するかを示す計画に落とし込みます。通常、機能要件では実現すべきことを記述し、セキュリティ要件では実行してはならないことに重点を置きます。

• 機能設計の例：ページはデータベースのCUSTOMER_INFOテーブルからユーザーの氏名、メールアドレス、電話番号、住所を取得し、画面に表示する。

• セキュリティ上の懸念事項の例：データベースから情報を取得する前に、ユーザーが有効なセッショントークンを持っていることを確認する。トークンがない場合は、ユーザーをログインページにリダイレクトする。

フェーズ3：開発

設計を実装して形にする段階では、セキュリティの観点から、コードが適切に記述されているかどうかが重要になります。通常、セキュアコーディングガイドラインが定められており、コードレビューでガイドラインが正しく守られているかを確認します。コードレビューは手動で行うことも、静的アプリケーションセキュリティテスト（SAST）を使って自動化することもできます。

とはいえ、現代のアプリケーションの多くはゼロから作られるわけではないため、開発者は自分で書くコードだけを気にしていればよいわけではありません。開発者は通常、無償のオープンソースコンポーネントが提供する既存の機能を利用し、新機能や価値をできるだけ早く組織に提供します。実際、現在デプロイされているアプリケーションの90%以上は、こうしたオープンソースコンポーネントで構成されています。ソフトウェア構成分析（SCA）ツールは通常、こうしたオープンソースコンポーネントをチェックします。

この場合、セキュアコーディングガイドラインには次のような内容が含まれます。

• パラメーター化された読み取り専用のSQLクエリを使用してデータベースからデータを読み取り、悪意ある目的でクエリを乗っ取られる可能性を最小限に抑える

• データを処理する前に、ユーザー入力を検証する

• データベースからユーザーに返すデータをすべてサニタイズする

• オープンソースライブラリを使用する前に、脆弱性がないか確認する

フェーズ4：検証

検証フェーズでは、アプリケーションが当初の設計と要件を満たしていることを確認するため、徹底的なテストを行います。さまざまな技術を使った自動セキュリティテストを導入するのにも適した段階です。テストに合格しない限り、アプリケーションはデプロイされません。このフェーズでは、検証とリリースを管理するために、CI/CDパイプラインなどの自動化ツールをよく利用します。

このフェーズの検証には、次のようなものが含まれます。

• アプリケーションの重要な処理経路を確認する自動テスト

• アプリケーションの基盤となる機能の正しさを検証する、ユニットテストの自動実行

• 本番環境で使用するアプリケーションシークレットを動的に差し替える自動デプロイツール

フェーズ5：保守と進化

アプリケーションはリリースして終わりではありません。見落とされていた脆弱性が、リリースから長い時間が経ってから見つかることもあります。こうした脆弱性は、開発者が記述したコードに含まれている場合もありますが、アプリケーションを構成するオープンソースコンポーネントに見つかるケースが増えています。その結果、アプリケーションの保守担当者が本番環境で発見する「ゼロデイ」—これまで知られていなかった脆弱性が増加しています。

開発チームはこうした脆弱性にパッチを適用する必要があります。場合によっては、アプリケーションの機能を大幅に書き直さなければならないこともあります。この段階で発見される脆弱性は、倫理的なハッカーによる外部ペネトレーションテストや、一般から「バグバウンティ」プログラムを通じて寄せられる報告など、他の情報源から見つかることもあります。本番環境で発生した問題への対処を計画し、今後のリリースに組み込む必要があります。

SSDLCのメリット

セキュアSDLCの主なメリットは次のとおりです。

• データ侵害のリスクを低減 

• アプリケーションのレジリエンスを向上 

• ユーザーからの信頼と安心感を高める 

• 修正コストを削減

セキュアSDLCは、SDLCのできるだけ早い段階でセキュリティチェックを組み込む「シフトレフト」の取り組みを体現するものです。

こうすることで、開発チームはリリース計画を適切に立てられ、リリースのスケジュールに影響する問題を早期に発見して対処しやすくなります。アプリケーションを本番環境にデプロイした後に予期せぬ問題が発覚するよりも、はるかに望ましい方法です。そのため、SSDLCはリリースを予定どおりに進めるのに役立ちます。

さらに、SSDLCでは開発チーム自らがセキュリティ対策を主導します。そのため、後から別のチームがバグを修正するのではなく、ソフトウェアを開発した領域の専門家が問題を修正できます。開発者がアプリケーション全体の品質に責任を持つようになり、より安全なアプリケーションを本番環境にデプロイできるようになります。

SDLCプロセスにセキュリティテストを追加するのは手間もコストもかかるように思えるかもしれません。しかし、現在ではその多くが自動化されています。これは特に、開発運用、つまりDevOpsに当てはまります（詳しくは後述します）。セキュアSDLC環境では、DevOpsチームとアプリケーションの機能を実装するエンジニアが頻繁に連携する必要があり、その連携をSDLC自体に組み込むことが重要です。

プロセスの早い段階で問題を修正すれば、開発チームはアプリケーションの総所有コストを削減できます。下のグラフに示すように、SDLCの後半で問題が見つかると、修正に必要な開発コストが100倍に増える場合があります。

IBM Systems Science Institute：不具合修正にかかる相対コスト、2010年

上の図2が示すように、セキュアSDLCへの移行により、開発チームは安全なアプリケーションをより迅速に構築できます。そのため、組織にとって価値ある投資となる可能性があります。

SSDLCを確実に実現するには

セキュアSDLCを実現するには、アプリケーションの動作と、開発者が要件をアプリケーションコードに変換する方法に注目する必要があります。アプリケーションの開発中は、チーム全員が常にセキュリティを意識することが大切です。そのためには、チームの文化を変え、ソフトウェア開発の各段階に自動化されたプロセスやチェックを取り入れる必要があるかもしれません。

アプリケーションでSSDLCを確実に実現できるかどうかは、SDLCのセキュリティに取り組むソフトウェア開発チームの強みと弱みに大きく左右されます。そのため、セキュアSDLCのプロセスを一つに定めるのは困難です。

セキュアSDLCの導入には、既存プロセスの変更、新しいツールの導入、そして何より複数チームにわたる文化の変革が伴います。そのため、適切に機能するセキュアSDLCを実現するまでの道のりは組織ごとに異なり、同じ組織内でも事業部門によって異なることがあります。

セキュアSDLCの5つのベストプラクティス

1. 開発者を教育する

セキュアSDLCは、次のような複数の関連施策と密接に結びついています。

• セキュアコーディングガイドラインを作成する

• 開発者にセキュリティ意識向上とセキュアコーディングのトレーニングを提供する

• 本番環境で発見された問題にどれだけ早く対処する必要があるか（修正SLAとも呼ばれます）について、明確な期待値を設定する

効果的なSSDLCの導入に、これらすべてが必要なわけではありません。しかし、ジグソーパズルのように、全体像を把握するには十分なピースを組み合わせる必要があります。

2. 要件を明確にする

何を作るにしても、理解しやすいものであるべきです。開発チームには、具体的な行動につなげやすい明確な要件が必要です。これは、すべてのセキュリティに関する助言、推奨事項、ガイドラインに当てはまります。テストで発見された脆弱性にも、すぐに対応できることが重要です。関係するすべての人、プロセス、ツールが、問題を指摘するだけでなく解決策を提示することが欠かせません。

3. 成長志向を持つ

SSDLCによって複数のチームの働き方や連携の仕方が変わるため、誰もが前向きな姿勢で取り組むことが大切です。また、セキュリティチームは、開発者が自らアプリケーションを安全にできるよう支援する姿勢を持つ必要があります。

4. 他の取り組みと連携させる

すでに確立されたアプリケーションやチームでは、クラウド移行やDevOpsの取り組み、あるいはセキュリティをより重視したその発展形であるDevSecOpsなど、ほかのモダナイゼーション施策と連携させることで、SSDLCの変更を導入しやすくなる場合があります。

5. 重要な問題から取り組む

発見されたすべての脆弱性に対処するのではなく、最も重要な問題と、実行可能な修正に集中しましょう。新しいアプリケーションや小規模なアプリケーションなら、すべてのセキュリティ問題を修正できるかもしれませんが、古く大規模な

アプリケーションでは、必ずしもそれが可能とは限りません。トリアージによる対応も有効です。セキュリティ上の問題が本番環境に持ち込まれないようにするだけでなく、既存の脆弱性を優先順位付けし、時間をかけて対処することにも重点を置きます。

SSDLCとDevSecOps

SSDLCとDevSecOpsは密接に関連していますが、実際には相互に補完するプラクティスです。どちらも、開発者が自身のアプリケーションに対する責任をより多く担えるよう支援し、機能仕様を満たすコードを書いてテストするだけにとどまらないことを目指します。

Secure SDLCはアプリケーションの設計と構築に重点を置きます。一方、DevSecOpsは、従来のITチームが担っていた各アプリケーションの本番環境に対する責任を、開発者に移すことを目指します。これにより開発者は、ビルド、テスト、リリースのプロセスを可能な限り自動化できるようになります。

DevOpsとDevSecOpsは、ソフトウェア開発者の役割を再定義する変革をもたらしました。もちろん、クラウド移行など、ほかの大きな変化もこの流れを後押ししています。開発者の権限を強化し、セキュリティテストを迅速化することは、現代の多くの組織にとって成功の鍵です。しかし、アプリケーションセキュリティを単なる自動化の課題と捉えるのは誤りです。その代わりに、開発の早い段階からセキュリティへの意識と配慮を高める、文化やプロセスの変革を推進することが重要です。SSDLCとDevSecOpsのどちらの呼び方をするかにかかわらず、こうした取り組みはソフトウェア開発ライフサイクルのあらゆる段階に浸透させる必要があります。

より安全な未来に向けて

本番環境で脆弱性をテストする従来の方法だけでは、もはやアプリケーションを安全に保つことはできません。ソフトウェア業界の進化とともに、攻撃の種類も変化してきました。アプリケーションを安全にデプロイし、維持するには、開発プロセスのすべての段階を保護する必要があります。つまり、要件の収集段階でセキュリティに関する行動について検討し、セキュリティを重視する意識が根付くようチームの文化やプラクティスを見直し、デプロイプロセスに自動検証を組み込むなど、さまざまな取り組みを組み合わせて安全なSDLCプロセスを実現します。

SSDLCにより、セキュリティリスクへの対応を前倒しし、保守段階で後戻りするのではなく、要件定義の段階でセキュリティ問題の根本原因に対処できます。SDLC導入のベストプラクティス（AIを活用する場合も含めて）に従い、開発のあらゆる段階でセキュリティに注力すれば、アプリケーションの安全性を大幅に高めることができます。