セキュアSDLC 101

SDLCのフェーズについて、およびSDLCにセキュリティを組み込む方法、さらに既存のSDLCを次のレベルのセキュアSDLCへと進める方法について説明します。

デジタル・トランスフォーメーションがすべての業界セクターに広がり、今やあらゆる企業がソフトウェア・ビジネスに携わっています。顧客と直接取引する営業でも、業務の運用でも、市場での競争力の維持に必要なスピードと俊敏性を実現しながらソフトウェアの信頼性を高めることで、収益力を確保する必要があります。

しかし、ソフトウェア開発ライフサイクル（SDLC）にセキュリティを組み込むことに関しては多くの組織が立ち遅れています。多くの開発チームは依然としてセキュリティをボトルネック、つまり完成したはずのコードの手直しを強いられる問題と捉える傾向があり、その認識が便利な最新機能の市場への投入を阻害しています。

しかし、セキュリティが不十分なソフトウェアは、企業をますます大きなリスクにさらします。製品がハッカーによる悪用に対して無防備であれば、便利な最新機能があってもお客様やお客様の顧客は保護されません。高品質、高セキュリティ製品の市場への投入を阻止するのではなく実現できるようなセキュアなソフトウェア・プロセスを開発して、セキュリティを組み込む必要があります。

安全な事業運営のためのSDLCのセキュリティ

データ侵害やサプライチェーン攻撃に関する絶え間ない報告は、侵害されたソフトウェアが事業に壊滅的な影響を与える可能性があることを示しています。ソフトウェア・リスクがビジネス・リスクに直結するようになっている昨今では、リスクに優先順位を付けて予防的に管理する必要があります。リスクを管理し、組織のデジタル・トランスフォーメーション（DX）の取り組みから摩擦を取り除くためには、アプリケーション・セキュリティ・プログラムに「シフト・エブリウェア（工程のあらゆるタイミングへのシフト）」が求められます。そのためには、開発工程の終盤になってからセキュリティ対策に取り組むのではなく、セキュリティを一連のプロセスやツールに移行し、アプリケーション開発プロセスの全段階に組み込む必要があります。開発ツールチェーンとワークフローにシームレスに連携するツールやソリューションを使用すれば、セキュリティ・プログラムは最大限の効果を発揮します。

SDLCとは、組織がアプリケーションを開発するために用いる、方向付けから廃止までのプロセスを定義する確立されたフレームワークです。長年にわたり、ウォーターフォール型や反復型から、最近のアジャイルおよびCI/CDまで、多くのSDLCモデルが登場し、モデルが新しくなるたびにデプロイメントの速度と頻度が増す傾向がありました。

通常、SDLCには次のフェーズがあります。

• プランニングと要件定義
• アーキテクチャと設計
• テスト計画
• コーディング
• テストと結果
• リリースと保守

初期のSDLCシステムでは、テスト段階になってからセキュリティ関連のアクティビティを実行していたため 作業時間が制約され、安全でないコードが外部に出回ることが頻繁にありました。そこで、セキュリティ・アクティビティを開発に連携させるために「シフトレフト」プロセスが導入されるようになりましたが、その後、SDLCの概念はさらに進化し、「シフトレフト」からセキュリティ上の課題を開発の全段階に組み込む「シフトエブリウェア」の考え方へと発展していきました。

SDLCの後工程でバグが発見されると、修正コストが高くつきます。開発ライフサイクルの後工程でバグが発見された場合、開発者は自分が行っている作業を中断し、何週間も前に作成した可能性があるコードを見直す必要があります。さらに、バグが運用環境まで持ち込まれてから見つかると、コードはSDLCの最初に手戻りすることになります。この時点でドミノ効果が始まり、1つのバグ修正が連鎖的に波及して他のコードも変更する必要が生じます。そのため、バグの修正がSDLCの後工程まで持ち越されると、修正コストが増加するだけでなく、他のコードの変更にも遅れが生じて、コストがさらに増大する可能性があります。

セキュリティ・テストをSDLCの全段階に統合して脆弱性を早期に検出および軽減し、コーディングの段階からセキュリティを組み込むことで、はるかに大きな効果が得られ、時間もコストも削減されます。セキュリティ保証アクティビティには、設計段階のアーキテクチャ解析、コーディングとビルド段階のコード・レビュー、およびリリース前のペネトレーション・テストが含まれます。

セキュアSDLC手法には主に以下の利点があります。

• ソフトウェア・セキュリティの強化。
• セキュリティに関する考慮事項に対するステークホルダーの意識向上。
• コーディングを行う前に設計上の欠陥を早期検出。
• 欠陥の早期検出と解決によるコストの削減。
• 組織に内在する全体的なビジネス・リスクの低減。

セキュアSDLCの仕組み

一般的には、セキュアSDLCでは、セキュリティ・テストおよびその他のアクティビティを既存の開発プロセスに統合する必要があります。例としては、セキュリティ要件の作成と機能要件の作成を並行して行うことや、SDLCの設計フェーズでアーキテクチャ・リスク解析を行うことなどが挙げられます。

多くのセキュアSDLCモデルが使用されていますが、最もよく知られているものの1つにMicrosoft Security Development Lifecycle（MS SDL）があります。このモデルは、ソフトウェアのセキュリティを強化するために組織が採用できる12のプラクティスを示しています。米国国立標準技術研究所（NIST）から発表されたSecure Software Development Frameworkもあります。このフレームワークは、組織が既存のSDLCに統合できるセキュリティ関連プロセスに焦点を当てています。

どのように始めるか

開発者またはテスターは、セキュアSDLCへと移行し、組織のセキュリティを向上するために次のことを行うことができます。

• セキュア・コーディングのベストプラクティスと利用可能なセキュリティ・フレームワークについて学習し、同僚にも教える。
• 開始時にアーキテクチャ・リスク解析を実施する。
• テスト・ケースの計画/作成時にセキュリティを考慮する。
• 静的解析、動的解析、およびインタラクティブ・アプリケーション・セキュリティ・テストにコード・スキャン・ツールを使用する。

基本の域を超えて次に進むには

これらの基本的事項を超えて、管理者はより大きなインパクトを実現するために戦略的アプローチを考案する必要があります。完全なセキュアSDLCを一から実装することに関心がある意思決定者の方は、以下のことから始めてください。

• 現在組織に存在するアクティビティおよびポリシーとその有効性を特定するギャップ分析を行う。
• 現実的で達成可能な目標と成功指標の定義を定めることにより、ソフトウェア・セキュリティ・プログラム（SSP）またはソフトウェア・セキュリティ対策（SSI）を策定する。
• SSI内のセキュリティ・アクティビティのプロセスを形式化する。
• 開発者のセキュア・コーディング・トレーニングと適切なツールに投資する。
• 必要に応じて外部の支援を利用する。

やるべきこと

組織は既にセキュアSDLCに従っていますか？ まだ必ず 改善の余地があります。他の組織と比較してセキュリティ・プログラムを評価することができます。Building Security In Maturity Model（BSIMM）はその支援を行います。ここ10年にわたり、BSIMMは100社を超える組織で行われたセキュリティ・アクティビティを追跡してきました。組織もSDLCもそれぞれ異なるため、BSIMMは何をすべきかは提示しません。しかし、その観察モデルでは、独自の業種における他社の取り組み、つまり何が効果があったか、そして何が効果がなかったかがわかります。

この投稿は2016年1月21日に発表され、2022年11月21日に更新されました。