セキュア ソフトウェア開発ライフサイクル(セキュアSDLC)とは?
ソフトウェア開発ライフサイクル(SDLC)は、ソフトウェア システムを計画、実装、維持するためのプロセスであり、過去60年のほとんどの期間において何らかの形で存在してきました。しかし、その年数にもかかわらず(あるいは、おそらくそれが理由で)、SDLCではセキュリティが考慮されないことがよくあります。データ侵害やランサムウェアなどのサイバー脅威が存在するこの時代において、もはやセキュリティを後回しにすることはできません。
セキュリティへの取り組みがSDLC に追加されるオーバーヘッドであると認識されているにもかかわらず、現実には、侵害による影響が最初にそれを正しく行う努力よりもはるかに壊滅的となっている現状があります。とはいえ、ソフトウェアの構築というすでに複雑なビジネスに セキュリティを追加 するにはどうすればよいのでしょうか。ほとんどのことがそうであるように、必要なのは、その中のボトルネックではなく開発プロセスの一部にするためのベストプラクティスを戦略的に導入することです。
ソフトウェア セキュリティの取組の例
SDLC自体にセキュリティを組み込む方法へと進む前に、ソフトウェア組織内の「セキュリティ」の範疇に入る活動のタイプを理解することが重要です。ここで、多くの組織が何らかの形ですでに実装している(または実装を計画している)可能性のある活動をいくつかご紹介します。なお、ここでは、活動をすべて網羅するのではなく、ソフトウェアのセキュリティ向上に利用可能な活動タイプを例示することを主眼としていることにご注意ください。
スタティック分析
スタティック分析 は、欠陥や脆弱性がないかソース コードを自動的にスキャンするプロセスです。これは一般には、ソフトウェア プロジェクト内の安全でないコード( infrastructure as code (IaC) やアプリケーション コードなど)の既知のパターンを特定する自動化されたプロセスであり、こうしたコードがエンド ユーザーに公開される前に開発チームは問題を修正する機会が得られます。
セキュリティ スキャン
スタティック分析と同様、セキュリティ スキャンも一般に自動化されたプロセスであり、 脆弱性 や設定ミスがないかアプリケーション全体とその基礎となるインフラストラクチャをスキャンします。これは、クロスサイト スクリプティング分析、ポート スキャン、または コンテナ脆弱性のスキャン (ほんの一例)の形で導入できます。
コード レビュー
自動化されたスキャンは役に立ちますが、本番環境にリリースする前に任意のコードに対する第2の目が得られるのは、常に有益なことです。ほとんどの開発チームは欠陥およびその他の論理エラーを発見できるよう、すでにコード レビューを実施していますが、セキュリティに対する正しい考え方が整っていることで、コード レビューによる監督が適切に行われ、一般的でない脆弱性がコードベースにも持ち込まれないよう徹底できます。
侵入テスト
より集中的な活動である侵入テストを実行するには、会社の生産インフラのセキュリティをテストするためにサイバーセキュリティの専門家を採用する必要があります。侵入テストの実施者は、脆弱性分析から実際のエクスプロイトの実行までのあらゆることを実施でき、その過程において、セキュリティ テストのどのチェックポイントでも見過ごされたさまざまな課題の明確なレポートが結果として得られます。
バグ報奨金
侵入テストと似た(ただし同じではない)新たな活動であるバグ報奨金によって、ユーザーは自身で発見した脆弱性を報告するよう促されます(報告と引き換えに報奨金を提供)。バグ報奨金は、発見したセキュリティ上の問題の報告を促すことで、その問題を個人的利益のために悪用されることを防ぐ優れた方法です。
トレーニング
優れた教育の力を軽視してはなりません。サイバーセキュリティの世界は常に変化しており、10年前に有益だったアドバイスや知識のほとんどが役に立たなくなっています。それはまるで、今日知っていることが10年後にはあまり価値のないものになるようなものです。セキュリティのトレーニングは、最も一般的な発生源である人的ミスによる脆弱性を緩和するのに大いに役立つ可能性があります。
(セキュア)ソフトウェア開発ライフサイクル
ソフトウェア開発ライフサイクルにセキュリティを組み込むと、単純な積み重ねではなく複雑に絡み合わせたようになります。「セキュリティ フェーズ」はありませんが、むしろSDLCの既存のフェーズに含めることのできる(およびその必要のある)一連のベストプラクティスとツールがあります。セキュリティ チームに利害関係者を含めることから、自動化されたツールの使用および教育の推進に至るまで、To-Doリストにチェックを付けるための単なる別項目ではなくプロセスの進化としてセキュリティを扱うことで、持続可能性が高まるとともに(さらに重要ですが)価値あるものになります。
- 要件
SDLCの第1フェーズでは、何が問題で、セキュリティの要件が何であり、「完了」の定義がどのようなものであるのかを正確に定義する必要があります。この時点で、すべてのバグ報告、機能要求、脆弱性開示がチケットからプロジェクトに遷移します。セキュアSDLCの関連において、ここでの最大の問題が優先されます。セキュリティ組織のメンバーを準備プロセスに含めることによって、SDLCに入るすべての新しい機能または修正がセキュリティに与える影響を判断するためのコンテキストが十分に確保されます。
- 計画
問題を特定した後は、その解決策が何であるかを明らかにする必要があります。ここでは何を構築するかの決定が行われ、これには要件フェーズと同様に、計画フェーズにもセキュリティ チームからの入力とフィードバックが伴います。これによって、提案されている解決策を用いて、お客様にとって価値があるのと同じくらい安全な方法で問題が解決されるよう徹底します。
- 設計
セキュリティ要件が整ったら、指定された解決策をアプリケーション内でどのように達成するのかを明確にします。ソフトウェア アーキテクチャの観点から、これには一般に端から端まで解決策を指定する必要があります。影響を受けるのは何のシステムか。どのサービスが作成または変更されるか。ユーザーはこの機能をどのように操作するか。エンジニアリング チームの他のメンバーが設計をレビューおよび承認する必要があるのと同じように、潜在的な脆弱性を特定できるよう、セキュリティ チームによるレビューが必要です。これら最初の3つのフェーズにおいてコミュケーションが重要とされており、怠った場合、セキュリティ問題の特定が手遅れとなってしまうリスクがあります。
- 実装
構築に移りましょう。ここで、設計がコードに変換され、前述のセキュリティ対策が効果を発揮し始めます。スタティック分析は、すべてのコミットまたはプッシュで実行できる容易かつ安価なソリューションであり、開発チームは記述しているコードの状態についてほぼリアルタイムのフィードバックが得られます。
コードが完成し、コード レビュー プロセスがトリガーされたら、十分なトレーニングを受けたチームが論理的な課題と潜在的なセキュリティ上の問題の両方を警戒する必要があります。製品の品質と同じように、健全な組織にセキュリティを確保することはセキュリティ組織のチーム メンバーだけでなく、すべてのチーム メンバーの責任です。
- テストおよび導入
コードが記述され、それに続いてレビューされた後は、実際にコードを試してからリリースします。ここで、さらに堅牢なセキュリティ スキャン ツールが役に立ちます。これにより、アプリケーションのセキュリティのさらに詳細な分析が可能になります。利用可能な機能およびリソースの規模に応じて、手動によるセキュリティ テストを実行するのに適した段階でもあります。この方法で脆弱性が発見されるので、ソリューションを既存の自動化されたツール内に構築して将来の不具合の再発を予防することができます。
- メンテナンス
コードのリリースは「一度設定すれば、後は操作不要」な活動ではありません。最高の状態での動作を維持したい場合は、コードを発展させ、手入れをする必要があります。毎日、リソースが変化し、バグが発生し、脆弱性が発見されています。コード内の欠陥の特定と修復のためにメンテナンス フェーズが一般に使用されていますが、コードは脆弱性が発見されるポイントでもあります。
重要なのは、安全なコードが常に安全なままであると思い込まないことです。サプライチェーン リスクからゼロデイ エクスプロイトに至るまで、セキュリティ環境は絶えず変化しています。問題が発生したときにその問題を特定して応答するためのプロセスを構築することが、セキュアSDLCを実装するときの極めて重要なステップです。
- 最初に戻る
セキュアSDLCは直線ではなく円を描くプロセスであり、終わりに達すると、もう一度最初から再開します。テスト フェーズおよびメンテナンス フェーズで発見されたあらゆるバグ、改善、脆弱性をもとにそれ自体の要件フェーズが開始します。一般的に、安全なソフトウェア開発は継続的改善の絶え間ないサイクルなのです。
結論: 新たな段階へ
組織がすでに従っているセキュリティをSDLCに組み込む方法は無数にあります。同時に、セキュアSDLCの取組みを次の段階へと引き上げることのできる強固な仕様が多数あります。ソフトウェア開発プロセスへのセキュリティの組込みを開始すると、後に続くリソースはインスピレーションと指針を探すのに非常に適した場となります。
OWASP SAMM
OWASP Software Assurance Maturity Model は、元のOWASP Comprehensive, Lightweight Application Security Process (CLASP)の後継です。ソフトウェア開発プロセスにセキュリティ対策を組み込むための明確な指針をもたらす強固なモデルであり、組織の適切なリスク プロファイルに合わせてセキュリティ対策を構築することを重視しています。
NIST SSDF
NIST Secure Software Development Framework (SSDF)は、セキュリティに関心のある組織からの確立されたベストプラクティスに基づく、基礎となる一連の安全なソフトウェア開発の実践です(OWASPを含む)。NIST SSDFはSDLCを以下の4つのカテゴリに分類しています。それぞれのカテゴリーが、組織のソフトウェアのセキュリティ対策向上を目的としています。
- 組織の準備: 組織レベルで、および個々の開発チームまたはプロジェクト内で安全なソフトウェア開発を実行するために、人材、プロセス、テクノロジを確実に準備します。
- ソフトウェアの保護: ソフトウェアのすべてのコンポーネントを改ざんおよび不正アクセスから保護します。
- 十分に安全なソフトウェアの開発: セキュリティ脆弱性を最小限に抑えた十分に安全なソフトウェアを開発し、リリースします。
- 脆弱性への対応: リリースするソフトウェアに残存する脆弱性を特定し、適切に対応します。特定した脆弱性に対処するとともに、類似の脆弱性が今後発生しないよう予防します。
