Table of Contents

    SDLCとは

    SDLCの定義

    ソフトウェア開発ライフサイクル（SDLC）とは、可能な限り最短の生産期間で、高品質、低コストのソフトウェアの生産を可能にする構造化されたプロセスです。SDLCの目標は、あらゆるお客様の期待や需要を満たし、それを上回るような優れたソフトウェアを開発することです。SDLCは、それぞれが独自のプロセスと成果物を網羅するステージまたはフェーズが含まれる詳細な計画を定義し、概要を示します。SDLCに準拠することで、開発速度が向上し、代替の生産方法に関連するプロジェクトのリスクとコストが最小限に抑えられます（i）。

    SDLCが生まれた経緯

    1950年代と1960年代に、コンピュータ・サイエンスは急速に進歩しました。この急速な進歩は、生産フレームワークの台頭をもたらし、最終的には今日の私たちが知るところのSDLCにまで成長しました。

    1950年代以前、コンピューティングはSDLCのようなきめ細かいアプローチを必要とするほど精巧ではありませんでした。プログラミングの複雑さと規模が大きくなるにつれて、構造化プログラミングの概念が生まれました。時間の経過とともに、構造化プログラミングにはより戦術的な開発モデルが必要となり、SDLCの台頭をもたらしました（ii）。 

    SDLCが重要な理由と SDLCを実装する利点

    • アクティビティと成果物を定義する標準化されたフレームワークを提供する
    • プロジェクトの計画、見積もり、およびスケジューリングをサポートする
    • プロジェクトの追跡と管理を容易にする
    • 開発プロセスに関与するすべての利害関係者に対するライフサイクルのあらゆる側面の可視性を向上させる
    • 開発のスピードを上げる
    • 顧客関係を向上させる
    • プロジェクトのリスクを低減する
    • プロジェクト管理の費用と全体的な生産コストを削減する

    SDLCにおけるセキュリティの役割

    SDLCの当初の概念と開発では、テスト・フェーズの一部として実行される、個別の単一タスクとしてセキュリティ・アクティビティのみに対処しました。この事後アプローチの欠点は、プロセスでの発見が遅すぎた、または場合によってはまったく発見されなかった、必然的に多くならざるを得なかった脆弱性またはバグでした。現在では、SDLCを成功させるにはセキュリティが重要であり、SDLC全体でセキュリティ・アクティビティを統合することで、より信頼性の高いソフトウェアを作成できることが認識されています。SDLCの早期フェーズにセキュリティのプラクティスと対策を組み込むことで、脆弱性を早期に発見して低減し、それに伴う全体的な時間を最小限に抑え、ライフサイクル後半でのコストのかかる修正を削減します。

    「baking-in（織り込み済み）」セキュリティのこの考えは、現在のソフトウェア業界で広く認識され導入されている概念である「セキュアSDLC」をもたらしています。セキュアSDLCは、ソフトウェア開発のすべてのフェーズでセキュリティ評価とプラクティスを実施することによって実現されます。

    最新のアプリケーション・セキュリティ・テスト・ツールを使用すると、SDLC全体にセキュリティを簡単に統合できます。「セキュアSDLC」の概念に従い、ペネトレーション・テスト、脅威モデリング、コード・レビュー、アーキテクチャ解析などのセキュリティ保証アクティビティを開発プロジェクトに欠かせない要素として組み込むことが重要です。     

    セキュアSDLCアプローチを目指すことには主に以下の利点があります。

    • セキュリティが継続的な課題になることによるソフトウェア・セキュリティの向上  
    • セキュリティ課題に対するステークホルダーの意識向上
    • システムの欠陥を早期発見
    • 問題の早期発見・解決によるコスト削減
    • 組織に内在するビジネス・リスク全体の低減

    SDLCのしくみ

    SDLCのステージ/フェーズとは

    計画フェーズ

    計画フェーズには、プロジェクトおよび製品管理のすべての側面が含まれます。これには通常、リソースの割り当て、容量の計画、プロジェクトのスケジューリング、コストの見積もり、およびプロビジョニングが含まれます。

    計画フェーズでは、開発チームはプロジェクトに関与する利害関係者（顧客、営業チーム、社内外の専門家、開発者）から意見を集めます。この意見は、目的のソフトウェアを作成するための要件の詳細な定義に統合されます。チームはまた、プロジェクトの要件を満たすために必要なリソースを決定し、関連するコストを推測します。

    このステージでは、期待事項も明確に定義されます。チームは、ソフトウェアに何が求められるかだけでなく、何が求められていないかも特定します。このフェーズで生成される具体的な成果物には、プロジェクトの計画、推定コスト、予測スケジュール、および調達ニーズが挙げられます。 

    コーディング・フェーズ

    コーディング・フェーズには、統合開発環境でのシステム設計が含まれます。また、複数タイプの機器に対する静的コード解析とコード・レビューも含まれます。

    ビルド・フェーズ

    ビルド・フェーズでは、以前に特定されたコード要件を取得し、それらを使用して実際にソフトウェアのビルドを開始します。

    テスト・フェーズ

    このフェーズでは、作成されたソフトウェアの評価が行われます。テスト・チームは、開発された製品を評価して、「計画」フェーズで指定された要件を満たしているかどうかを評価します。 

    評価には、機能テスト（単体テスト、コード品質テスト、統合テスト、システム・テスト、セキュリティ・テスト、パフォーマンス・テスト、受け入れテストなど）および非機能テストの実績が含まれます。不具合が見つかった場合、開発チームに通知します。検証された（実際の）不具合が解決され、ソフトウェアの最新バージョンが作成されます。

    すべてのテストが定期的かつ確実に実行されるようにするための最良の方法は、自動テストを実装することです。継続的な統合ツールがこのニーズをサポートします。

    リリース・フェーズ

    リリース・フェーズでは、チームによるさまざまな環境へのリリースのパッケージ化、管理、およびデプロイが行われます。

    デプロイ・フェーズ

    デプロイ・フェーズでは、ソフトウェアが運用環境に正式にリリースされます。 

    運用フェーズ

    運用フェーズには、運用環境でのソフトウェアの使用が含まれます。

    監視フェーズ

    監視フェーズでは、ソフトウェアのさまざまな要素が監視されます。監視対象の要素には、システム全体のパフォーマンス、ユーザー・エクスペリエンス、新しい脆弱性、システムのバグまたはエラーの解析などが含まれる可能性があります。

    ブラック・ダックが提供する内容

    上記で述べたように、SDLCにとってセキュリティは重要です。ブラック・ダック製品により、既存の開発プロセスにセキュリティ・テストを追加できるため、SDLC全体のセキュリティが合理化されます。ブラック・ダックのソリューションは、組織全体にわたり、アプリケーション・ライフサイクルを通じて、セキュリティと品質リスクを包括的に管理することができます。

    ブラック・ダックは、SDLCの各フェーズに対してソリューションを提供しています。

    SDLC全体の包括的な製品とサービスの提供

    ブラック・ダックは、SDLC全体に統合できる製品とサービスを提供し、セキュアなコードを迅速にビルドできるようにサポートします。 

    • セキュア開発成熟度モデル（BSIMM） – 貴社のソフトウェア・セキュリティ・プログラムを他社のセキュリティ・プログラムおよび業界のベストプラクティスと照らして評価してベンチマーキングします。
    • マチュリティ・アクション・プラン（MAP） – ソフトウェア・セキュリティ態勢の確立または向上のための推奨事項を提示します。
    • ソフトウェア・テスト最適化 – 適切なレベルのセキュリティ・テストを設けるための優先順位付けを支援します。
    • アプリケーション・セキュリティ・コンサルティング・サービス – 専門家によるオンデマンドの支援を受けて、非常に困難なセキュリティおよびリスク管理対策に取り組みます。
    • セキュリティ・トレーニング/eラーニング – コーディング・スタンダードの基本の理解から、セキュアなコードをビルドするための高度なスキルの習得まで、お客様のニーズに対応する幅広い教育ソリューションをご用意しています。

    特定のSDLCニーズ向けの戦略的な製品とサービスの提供

    アーキテクチャ・リスク解析 – システム設計内の欠陥を特定することにより、セキュリティ態勢を改善し、セキュアな設計プラクティスを確実に実施します。

    • 計画フェーズのアクティビティ向け

    脅威モデリング – 潜在的なハッカーのエクスプロイトを調査して、アプリケーション設計の弱点を明らかにします。従来のテスト方法やコード・レビューでは見落としがちな設計上の欠陥を発見します。

    • 計画フェーズのアクティビティ向け

    Coverity SAST – ソースコードを解析し、組織のアプリケーションが攻撃されやすくなるセキュリティ脆弱性を検出します。開発中のコードのセキュリティと品質の欠陥に対処し、開発期間を短縮して全体的なセキュリティと品質を向上させます。

    • コードおよびビルド・フェーズのアクティビティ向け

    Seeker – アクティブ検証と機密データのトラッキング機能を備えた、業界初のWebベース・アプリケーション向けIASTソリューションを使用して、DevOpsパイプライン内のWebセキュリティ・テストを自動化します。IASTは、動的テスト（ランタイム・テスト）手法を用いて実行中のWebアプリケーションの脆弱性を発見します。

    • テストおよびリリース・フェーズのアクティビティ向け

    Defensics – サービスとプロトコルに関する不具合とゼロデイ脆弱性を特定します。Defensicsは、ソフトウェアのセキュリティ上の弱点を効果的かつ効率的に検出し修正を支援する包括的で多機能な自動ブラックボックス・ファジングツール（ファザー）です。  

    • テストおよびリリース・フェーズのアクティビティ向け

    Continuous Dynamic – アプリケーションの実行中に動的解析を行って、実行時の動作の問題を発見します。

    • デプロイ、運用、および監視フェーズのアクティビティ向け

    Black Duckソフトウェア・コンポジション解析 – アプリケーションやコンテナ内のオープンソース・ソフトウェアをセキュリティ保護し、管理します。Black Duckは、アプリケーションやコンテナに含まれるオープンソースおよびサードパーティーのコードから生じるセキュリティ、品質、ライセンス・コンプライアンス上のリスクを管理する包括的なソフトウェア・コンポジション解析（SCA）ソリューションです。

    Black Duckは、監視フェーズのアクティビティを通じてSDLCのコード・フェーズからサポートを提供します。

    • Black Duckをバグ・トラッカーと問題トラッカーに統合して、開発者がテストとリリース・フェーズの両方で見つかったオープンソースの問題を追跡および管理できるようにします。
    • ポリシー違反とセキュリティ・アラートに関連する自動化されたチケット作成は、チームが既に使用しているシステムの問題を管理して、解決までの時間を短縮し、テスト作業を効率的に管理するのに役立ちます。
    • チームは、アプリケーションが運用環境にデプロイされる前に、オープンソースのセキュリティ、ライセンス、または運用上の問題について最終スキャンを実行できます。
    • 高度な脆弱性修正ガイダンス、オープンソースのライセンス情報、およびポリシー管理を活用して、アプリケーションとコンテナのオープンソースのリスクを排除します。
    • 新しいオープンソースの脆弱性について運用環境のアプリケーションとコンテナを継続的に監視し、それらが機能するチームに警告して、潜在的なエクスプロイトが発生する前に問題に迅速にパッチを適用できるようにします。
    • Black Duckは、コーディング時に開発者IDEに直接統合して、オープンソース・コンポーネントの潜在的な問題にフラグを立て、パッケージ・マネージャとビルド・ツールに統合することで、オープンソースの依存関係の検出を自動化して、完全で正確なオープンソースの部品表（BoM）を確実なものとします。 

    マネージド・サービス – ブラック・ダックのマネージド・アプリケーション・セキュリティ・テストが貴社のアプリケーション・ポートフォリオ全体にわたってアプリケーション・セキュリティ・テストを効果的に実施するソリューションをご提供します。リスク管理の目標を達成するためのリソースやスキルが不足している場合は、オンデマンドのリソースと専門知識を利用して、アプリケーションのセキュリティ・テストを加速化および拡張します。

    マネージド・サービスは、監視フェーズのアクティビティを通じてSDLCのコード・フェーズからサポートを提供します。

    • マネージド動的アプリケーション・セキュリティ・テスト（DAST） – 効果的なDASTテストに必要なリソースが不足していても、ブラック・ダックのマネージドDASTを利用することで、社内でDASTを行う場合のコストや複雑さを伴わずに、いつでもWebアプリケーションを解析できます。
    • マネージド・ペネトレーション・テスト – シノプシスのマネージド・ペネトレーション・テストでは、ビジネス・ロジックに焦点を当てたさまざまなテスト・ツールと詳細なマニュアル・テストを活用して、実行中のWebアプリケーションやWebサービスの脆弱性を発見し、エクスプロイトを試みます。
    • マネージド・ペネトレーション・テスト – ブラック・ダックのマネージド・ペネトレーション・テストでは、ビジネス・ロジックに焦点を当てたさまざまなテスト・ツールと詳細なマニュアル・テストを活用して、実行中のWebアプリケーションやWebサービスの脆弱性を発見し、エクスプロイトを試みます。
    • マネージドSAST – ブラック・ダックのマネージドSASTをご利用ください。迅速かつコスト効果の高い方法で静的解析の実装とスケーリングを行い、ソースコードのセキュリティ脆弱性を体系的に検出して排除することができます。

    ペネトレーション・テスト – ペネトレーション・テスト解析は、サーバー側のアプリケーションやAPIに潜む悪用可能な脆弱性の検出および修正に役立ちます。ハッカーに見つかる前に、ビジネスに重大な影響をもたらす脆弱性を特定し、エクスプロイトによる攻撃を仕掛けることによってデータ漏洩のリスクを低減します。

    • 運用および監視フェーズのアクティビティ向け

    レッドチーム – ネットワーク、物理、ソーシャルのアタックサーフェスのセキュリティを確実にします。個々の脆弱性自体は些細に見えても、攻撃の経路の中で結合したとき、重大な損害をもたらす可能性があります。弊社のレッドチームは、システムへの実際の攻撃をモデリングし、攻撃に対してシステムがどの程度耐えられるかを評価します。

    • 運用および監視フェーズのアクティビティ向け

    SDLCのモデル/手法

    ウォーターフォール型

    ウォーターフォール型は最も古くからある、最もシンプルで構造化された手法です。各フェーズは前のフェーズの結果に依存し、すべてのフェーズが順次的に進行します。このモデルは体系化されており、各フェーズの終わりに有形の成果物を提示します。このモデルは柔軟性が求められる場合には適しません。フェーズ完了後に変更が許される余裕がほとんどなく、変更はソフトウェアのコスト、納期、品質に影響する可能性があります。

    アジャイル

    アジャイル手法では、毎回、前回のリリースから小規模な差分の変更を加えて継続的にリリースを繰り返し、 反復のたびに製品をテストします。アジャイル・モデルは、プロジェクトの問題を小さいうちに発見し、重大な問題に発展する前に対処できるという利点があります。また、開発の全工程を通じて事業のステークホルダーとの良好な関係を築き、フィードバックを得ることができます。

    リーン型

    ソフトウェア開発におけるリーン型手法は、リーン生産方式のプラクティスと原則に影響を受けています。リーン方式の原則は、作業プロセス・フローの向上と継続的な改善の文化の発展を奨励しています。リーン方式の7つの原則

    ムダをなくす

    知識を作り出す

    決定を遅らせる

    • 速く提供する
      • 人を尊重する
      • 品質を作り込む
      • 全体を最適化する

    反復型

    反復型プロセスでは、開発サイクルごとに未完成ながらもデプロイ可能なバージョンのソフトウェアを製造します。初回の反復ではソフトウェア要件のごく一部を実装し、以降のバージョンで要件の実装を徐々に追加していきます。最後の反復で要件を完成させます。

    スパイラル型

    スパイラル型開発モデルはプロジェクト固有のリスク・パターンに従って進められていきます。開発チームはプロジェクトを評価し、他のプロセス・モデルのどの要素を取り入れるかを決定します。 

    V字型

    V字型モデルでは、検証フェーズとバリデーション・フェーズが並行して実行されます。各検証フェーズはバリデーション・フェーズに関連付けられており、モデルはV字型で実行され、開発の各フェーズにはテストの関連付けられたフェーズがあります。

    SDLCのベストプラクティス

    SDLCに実装するための最も重要なベストプラクティスは、チーム全体にわたって効果的なコミュニケーションをとることです。調整を行えば行うほど、成功の可能性は高くなります。

    適切に実装されたSDLCの兆候には、次が含まれます。

    • 包括的なアプリケーション・セキュリティ・プログラムの適切なデプロイメント
    • コード品質のスタンダード
    • チーム間の効果的なコラボレーション
    • 合理化されたワークフロー
    • ライフサイクル全体にわたるチームの相互関与[iii]

    SDLCの一般的な誤りと課題

    SDLCの実装に悪影響を与える恐れのあるいくつかの落とし穴があります。おそらく最も問題となる誤りは、プロセスにおける顧客と利害関係者のニーズを適切に説明して、それに対応することができないことです。その結果、システム要件が誤解され、必然的に最終製品に満足してもらえません。

    さらに、SDLCの複雑さにより、プロジェクトが脱線したり、チームが詳細や要件を見失ったりすることがよくあります。パラメータと設計計画のすべての側面を厳密に順守しないと、プロジェクトは簡単に脱線する可能性があります（iv）。

    SDLCの将来

    より高速で新しい開発ライフサイクルの導入により、組織は古いSDLCモデル（ウォーターフォール型など）から離れつつあります。開発プロセスにおけるスピードと機敏性に対する要求がますます高まる中、自動化が重要な役割を果たしています。

    異種チーム間の境界が徐々になくなり、開発への合理化された同期アプローチが支持されるのに伴い、開発と運用はDevOps機能に統合されています。

    SDLCへの新しいアプローチは、アプリケーションをより迅速に提供する組織の能力を高める哲学とプラクティスを組み合わせたものであるDevOpsとして登場しました。SDLC手法がDevOps SDLCに移行するにつれて、セキュリティが果たす役割についても考慮する必要があります。セキュリティは、SDLCの個別の区分化されたステップではなくなりました。セキュアなソフトウェアがDevOpsのスピードで作成されるようにするため、セキュリティは現在、SDLC全体で重要なコンポーネントと見なされるようになっています。 

    今後数年間で間違いなく、組織は、SDLCにDevOpsアプローチを導入するだけでなく、セキュリティがSDLC全体に組み込まれる、より進化したDevOps手法を導入するようになります。この最新のソフトウェア開発モデルの成功を保証するために、組織はこの取り組みをサポートおよび強化するツールを戦略的に選択する必要があります。シノプシスは、アプリケーション・セキュリティ分野で実績のあるリーダーとして、この取り組みに最適に合わせた製品とサービスの包括的なスイートを提供しています。SDLCにおけるセキュリティの取り組みを強化する方法の詳細については、https://www.blackduck.com/ja-jp.htmlをご覧ください。

    [i] https://www.guru99.com/software-development-life-cycle-tutorial.html

    [ii] https://www.techopedia.com/definition/22193/software-development-life-cycle-sdlc

    [iii] https://www.veracode.com/blog/2015/09/sdlc-best-practices-5-ways-bridge-application-security-gap-sw

    [iv] https://www.blackduck.com/blog/devsecops-life-cycle.html