安全なソフトウェア開発ライフサイクルとは

ソフトウェア開発は従来、計画、コード、テスト、デプロイという直線的なプロセスに従います。何十年もの間、セキュリティーが考慮されるのはテスト段階、つまりすでに何千行ものコードが記述された後のことでした。

SSDLCは、初日からソフトウェア開発ライフサイクル（SDLC）のすべてのフェーズにセキュリティーを埋め込むことで、従来のアプローチに挑戦します。SSDLCは多くの場合、要件、分析、計画、設計、開発、ドキュメンテーション、テスト、デプロイメント、保守の9つのフェーズで構成されます。

チームは、機能要件とともにセキュリティ上の懸念を議論することから始め、開発者は検証済みのインプットと認証標準を使用して安全なコードを記述します。テストはリリース前だけでなく継続的に実施され、多くの場合、自動コード・レビューが行われます。

この「シフトレフト」アプローチ、つまりセキュリティーを開発プロセスの早い段階に移すことは、組織がソフトウェアを構築する方法を変革するのに役立ちます。テスト中に「これは安全だろうか？」と考えるのではなく、チームはコードの最初の行を書く前に、「どうすればこれを安全にできるか？」と問います。

たとえば、銀行のアプリケーションについて考えてみましょう。従来の開発では、リリース前のテスト中にSQLインジェクションの脆弱性が発見される可能性があり、開発者は数百のファイルにわたるデータベースのやり取りを書き直す必要があります。SSDLCでは、設計、ビルド、テスト全体でセキュリティー・チェックが実行されるため、チームはその脆弱性を早期に発見できる可能性がはるかに高くなります。

最近のデータは、この事前対応型のアプローチが重要である理由を示しています。最近のサプライチェーンのセキュリティー調査によると、ソフトウェア・サプライチェーン攻撃はわずか3年間で1300％増加しました。¹

SSDLCは、脆弱性を早期に検出し、修正が最も簡単でコストも最小限で済む段階で対処することで、組織をこうしたサイバー攻撃やその他の攻撃から保護するのに役立ちます。また、一般データ保護規則（GDPR）や医療保険の相互運用性と説明責任に関する法律（HIPAA）などの規制へのコンプライアンス維持にも役立ちます。

通常、SSDLCフェーズは9つあります。これらはSDLCモデルに密接に準拠していますが、各フェーズにセキュリティーに関する考慮事項も組み込まれています。

• 要件
• 分析
• 計画
• デザイン
• 開発
• 資料
• テスト
• 導入
• 保守

チームは完成したソフトウェアの機能について議論し、機能要件とセキュリティ要件を初日から定義し、たとえば機密データ・フィールドの 暗号化の実装やロールベース・アクセス制御（RBAC）の確立などを明確にします。この議論では、潜在的なセキュリティー・リスクやGDPRのデータ保護基準などのコンプライアンス要件のレビューが含まれます。

組織は、潜在的な脆弱性を定量化し、脅威のランドスケープをマッピングし、最善の想定ではなく最悪のシナリオを想定して計画を立てます。たとえば、医療アプリは、患者のデータ侵害、ランサムウェア攻撃、内部脅威のリスクを分析し、各々への対応を計画することができます。

セキュリティー・チームと利害関係者は、役割を確立し、リソースを割り当て、潜在的なビジネスへの影響に基づいて許容できるベースラインを定義します。この計画により、開発期限を守りながら、リスクの高い脆弱性を優先順位付けすることができます。また、コーディングを開始する前に、セキュリティー・ツールやトレーニングの予算を立てることができます。

設計フェーズには、脅威モデリング（計画されたアーキテクチャーにおける潜在的なセキュリティーが抱える脆弱性の体系的な分析）が含まれます。この実践により、コストのかかる後付けではなく、最適なプラットフォームから理想的なUIに至るまで、安全な設計がシステムの青写真に組み込まれるようになります。

開発者は、Open Web Application Security Project（OWASP）などの組織によって確立された安全なコーディング標準に基づいて、安全なコーディング手法を適用します。これらの標準には、すべてのインプットの検証、認証技術の実装、適切なAPI呼び出しの使用、リポジトリーのスキャン、エラーの安全な処理などが含まれます。

開発者は、多くの場合、問題を早期に発見するために、セキュリティー・プラグインを備えた統合開発環境（IDE）を使用します。

チームは、セキュリティー・リスクを軽減するためにソフトウェアの依存関係を評価し、開発中にセキュリティー・テストを開始します。たとえば、決済処理モジュールは、統合後ではなく、構築中にセキュリティー・テストを受けます。

チームは、監査、コンプライアンス・チェック、セキュリティー・レビューのためのセキュリティー制御とプロセスを文書化し、迅速なインシデント対応と継続的な規制コンプライアンスを実現します。

テストは、コード・レビューとセキュリティー・テストを組み合わせたものです。チームは、デプロイメント前に機能とセキュリティーの両方を検証します。

テストには、プログラムを実行せずにソースコードを解析する静的アプリケーション・セキュリティー・テスト（SAST）などの静的解析や、実行中にアプリケーションをテストする 動的アプリケーション・セキュリティー・テスト（DAST）が含まれます。

高度なテストには、コードに挑戦する倫理的ハッカー、データ・セキュリティーを検証するペネトレーション・テスト、APIを利用するシミュレーションなどが含まれます。ソフトウェア構成分析（SCA）を並列実行して、脆弱なオープンソースの依存関係やライセンスの問題を特定することもできます。

チームは、ソフトウェアをリリースする前に、 サーバー、構成、ミドルウェアなどのデプロイメント環境を安全に確保します。これは、誤った設定のインフラを通じて脆弱性が発生することを防ぐ上で役立ちます。

多くのチームは、実際の環境でコードがどのように動作するかを確認するために、ソフトウェアのテレメトリー（メトリクス、ログ、トレース）も収集します。OpenTelemetry（OTel）はCloud Native Computing Foundation（CNCF）によるオープンソース・プロジェクトで、ベンダーに依存しないメトリクス、ログ、トレースの収集と転送を可能にし、サービス、パイプライン、環境間で一貫したシグナルを確保する上で役立ちます。

継続的に監視することで、脅威や脆弱性を早期に検知できるため、ソフトウェア・ライフサイクル全体を通じて迅速な修復が可能になります。このフェーズは、ゼロデイ・エクスプロイトを防ぎ、新たに発見された脆弱性に対応するために特に重要です。

組織は通常、確立されたフレームワーク、すなわちセキュリティー・ベンチマーク、セキュリティー・ベスト・プラクティス、リスク・アセスメント・ツールを含む包括的な方法論によって、安全なソフトウェア開発ライフサイクルを開始します。最も一般的なフレームワークには次のものがあります。

米国国立標準技術研究所（NIST）は、Secure Software Development Framework（NIST SP 800-218）など、安全な開発に特化した政府支援型プラクティスとベンチマークを提供しています。

このフレームワークは、組織がすべての開発チームにわたってベースラインとなるセキュリティ要件を確立するのに役立ちます。他のフレームワークと比較すると、より規範的な連邦基準が提供されるため、多くの場合、官公庁・自治体の請負業者や規制対象の業種・業務にとって理想的です。連邦政府機関と連携する組織は、契約上の要件としてNIST基準を遵守しなければならないことがよくあります。

Open Web Application Security Project（OWASP）は、オープン・フレームワークであるSoftware Assurance Maturity Model（SAMM）を提供しています。

OWASP SAMMは、組織が既存のソフトウェア・セキュリティー慣行を評価し、特定のリスク・プロファイルに合わせた反復的な改善プログラムを構築するために役立ちます。

このため、厳格なコンプライアンス要件ではなく、柔軟な成熟度ベースのアプローチを求める組織に好まれる傾向にあります。たとえば、スタートアップ企業は、認証などの重要な領域での基本的なセキュリティー・プラクティスから始めて、チームと予算の拡大に応じて包括的なセキュリティー・テストに徐々に拡大できます。

OWASP DevSecOpsガイドラインは、統合されたセキュリティテストツール（SAST、 DAST、SCA（ソフトウェア構成分析）、IAST（インタラクティブ・アプリケーション・セキュリティー・テスト）を用いたパイプライン実装を詳細に示しています。このガイドラインに従うことで、開発ワークフローを中断することなく、既存の継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインにセキュリティー・テストを簡単に組み込むことができます。

結果として、リリース・サイクルを遅らせることなくセキュリティーを自動化したい組織は、OWASP DevSecOpsガイドラインを好む可能性があります（PCI DSSコンプライアンスを維持しながら毎日アップデートを展開するフィンテック企業など）。

多くの組織はDevOpsやDevSecOpsの実践を通じてSSDLCを実装しており、セキュリティー・テストを自動化し、CI/CDパイプラインに統合することで、開発を加速しつつセキュリティー基準を維持しています。DevSecOpsの手法を使用して、開発チームは安全な設計、構築、オペレーション、保守に加えて、アプリケーションのセキュリティーにも責任を負います。迅速に反復し、ボトルネックを回避するために、セキュリティー・テストには自動化が使用されることがよくあります。

SLSA（「サルサ」）は、ソフトウェア・サプライチェーンを保護するためのコミュニティー・フレームワークで、もともとGoogle社によって提案され、現在はOpenSSFが管理しています。

そのガイドラインは、組織が改ざんを防止し、アーティファクトの整合性を検証し、ビルド・プロセスと依存関係の検証を自動化する上で役立ちます。サプライチェーンのセキュリティーを最適化し、構成証明を確立したい組織は、ソフトウェアがビルド・プロセス中に改ざんされていないことを証明するためにSLSAを実装することもできます。たとえば、エンタープライズ・アプリケーションを配布しているソフトウェア・ベンダーは、自社のリリースが正規品で改ざんされていないことを顧客に証明する必要があります。

SSDLCは、組織にいくつかの重要なメリットをもたらします。

SSDLCの「シフトレフト」アプローチは、多くの場合、脆弱性への対処が最も容易かつコストが最も低いタイミング（デプロイメント後ではなく設計や開発中）で、組織が脆弱性を検知し、修正する上で役立ちます。

たとえば、設計段階のレビューにより、計画されたアーキテクチャーでは、セキュリティーで保護されていないAPIエンドポイントを通じて機密性の高い顧客データが公開されることが判明する場合があります。この問題を早期に検知することで、最初からより安全なアーキテクチャーを構築でき、データ侵害による被害の可能性や高コストを要するセキュリティー制御の事後改修を回避できます。

侵害が発生した際のコストの削減も可能になります。データ侵害のコストに関する調査によると、DevSecOpsアプローチ（SSDLCを含む）は、データ侵害コストを削減する最大の要因でした。このアプローチを採用した組織では、データ侵害1件あたりのコストが227,192米ドル削減されました。

SSDLCは、デプロイメント前にセキュリティー上の問題を特定することでシステムのダウンタイムを防ぐことができ、これにより緊急の修正を回避し、ソフトウェアの安定性を向上させる可能性があります。脅威モデリングやあらゆる段階での詳細なコード・レビューもこの安定性を高めることができます。

SSDLCは、CI/CDパイプラインを介した開発からデプロイメントまで、すべてのインフラストラクチャーとコードに触れる人々を含むソフトウェア・サプライチェーンの保護に役立ちます。リスク管理の実践（脅威モデリングや依存関係スキャンなど）と、サイバーセキュリティー制御（アクセス制限やコード署名など）を組み合わせ、ライフサイクル全体にわたる脆弱性を防止します。

たとえば、SSDLCは、組織がソフトウェア部品表（SBOM）を実装して、すべてのコンポーネントと依存関係を追跡する上で役立ちます。このアプローチにより、脆弱性がサードパーティのライブラリーで発見された場合に、脆弱性の特定と修復が容易になります。

SSDLCは、各開発フェーズにセキュリティ制御と文書化を組み込むことで、組織がコンプライアンスを維持するのに役立ちます。このプロセスは、一般データ保護規則（GDPR）、医療保険の相互運用性と説明責任に関する法律（HIPAA）およびCalifornia Consumer Privacy Act（CCPA）などの業界固有のセキュリティ基準を一貫して満たす必要がある組織にとって重要です。コンプライアンスの信頼性が高まれば、法的問題や罰金の可能性も減ります。

SSDLCを実装する場合、開発、オペレーション、セキュリティーの各チームは頻繁かつ緊密に協力し、ソフトウェア開発における複数の視点を明らかにする必要があります。こうした必要なコラボレーションにより、部門間のサイロを解消し、後でコストが高くなる可能性のあるセキュリティーの問題を回避することができます。

SSDLCの採用には多くのメリットがありますが、組織がSSDLCを採用するときに、いくつかの課題が発生する可能性があります。

市場投入までの時間を短縮したい利害関係者は、セキュリティー要件が開発スピードの障害であると考えることがよくあります。セキュリティー・テストを後の段階まで延期するよう要求される場合すらあります。

このアプローチは初期開発を加速させる可能性ができますが、デプロイメント後に脆弱性が明らかになると、多くの場合、より高コストな遅延につながります。

たとえば、設計時に脅威モデリングを省略すると、クリティカルな攻撃経路が無防備な状態になる可能性があります。体系的な脅威分析がなければ、チームは承認システム、データ・アクセス制御、またはサードパーティー・サービスとの連携におけるセキュリティー・ギャップを見逃す可能性があります。こうした脆弱性は、本番環境では修正にかかるコストが飛躍的に高くなります。

脅威を取り巻くランドスケープが進化し続けるにつれて、開発チームは最新のセキュリティー知識を維持する必要があります。セキュリティーの専門知識を持たない組織は、SSDLCを効果的に実装するために、より多くのトレーニング、専門家の採用、または外部コンサルタントが必要になる場合があります。

たとえば、セキュア・コーディングに慣れていない開発者は、静的解析ツールを使用するタイミングや結果の解釈方法を知らない可能性があります。適切なトレーニングがなければ、これらのツールがフラグを立てた重要な脆弱性が対処されないままになったり、誤検知を生成して開発時間を無駄にする可能性があります。経験豊富な開発者であっても、新たな脅威やセキュリティー対策の最新情報を常に把握するためには、多くの場合継続的な教育プログラムが必要となります。

複数の統合を伴う複雑なソフトウェア・アーキテクチャーでは、高度なセキュリティー・ツールやプロセスが必要になる場合があり、開発時間とコストが増加する可能性があります。たとえば、異なるデータ形式と通信プロトコルを使用するIoTデバイスを統合すると、チームが保護しなければならない他の攻撃対象領域が作成される可能性があります。

暗号化APIの実装を考えてみましょう。APIはさまざまなユースケースをサポートしながら、最小限のアクセス権限で動作する必要があります。一部のサービスでは、復号化権のない暗号化機能が必要な場合があります。このプロセスでは、アクセス制御、認証、トランスポート層セキュリティー（TLS）に関する慎重な計画が必要になる場合があるため、セキュリティーや機能性を損なうことなくチームが対処しなければならない各連携ポイントの複雑さが増します。