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

セキュリティは、クリティカルな機能を含むすべてのアプリケーションにおいて重要な要素です。これは、悪意のある人物による攻撃からデータベースを保護するという単純なものから、適格リードをプラットフォームにインポートする前に不正利用対策を適用する複雑なものまであります。

セキュリティはソフトウェア開発ライフサイクル (SDLC) のすべてのフェーズで適用されるため、ソフトウェアの要件を実装する際に開発者の念頭に常におかれる必要がありますこの記事では、セキュア SDLC を構築する方法について検討しています。これにより、本番環境でセキュリティ問題が発生する前に、要件に関する注意事項を把握できます。

対策に力を入れることで、セキュリティ問題は本番環境の導入以前に、SDLC パイプラインで対応することができます。これにより、アプリでセキュリティの脆弱性が見つかるリスクが低減され、発見された時の影響が最小限に抑えられます。

セキュア SDLC の目的は、ペネトレーションテストなどの従来のセキュリティチェックを完全に排除することではなく、開発者の責任範囲にセキュリティを含め、最初から安全なアプリケーションを構築できるようにすることです。

セキュア SDLC が重要となる理由

セキュア SDLC が重要になるのは、アプリケーションセキュリティが重要だからです。製品をまずリリースし、その後にパッチを開発してバグに対応する時代は終わりました。開発者はプロセスの各段階において、潜在的なセキュリティの懸念について認識しておく必要があります。それには、これまで必要とされていなかった方法でセキュリティを SDLC に統合することが求められます。誰でもソースコードにアクセスできる可能性があるため、潜在的な脆弱性を考慮してコーディングする必要があります。そのため、アプリケーションがハッカーやその他の悪意あるユーザーによる攻撃を受けないようにするには、堅牢で安全な SDLC プロセスを使用することが重要です。

これまでの SDLC プラクティス

ソフトウェア開発ライフサイクル (SDLC) は、ソフトウェアアプリケーションがどのように構築されるかを説明するものです。通常、次のようなフェーズで行われます。

• 要件の収集

• 設計を導くための要件の分析

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

• 新機能の開発 (要件を満たすコードの記述)

• 新機能の検証 (要件を満たしているかどうかの確認)

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

• リリース後の機能のメンテナンスと進化

SDLC の 7 つのフェーズ

ウォーターフォールモデルは、これらの SDLC フェーズの基礎を築いた、最も古く最もよく知られている SDLC 方法論の一つです。1970 年に開発されたこれらのフェーズは、現在でもほとんど変わっていませんが、ソフトウェアエンジニアリングのプラクティスが大きく変化し、ソフトウェアの開発方法が再定義されました。

従来、ソフトウェアは高度に専門化したアプリケーションのために記述され、ウォーターフォール手法で開発されたソフトウェアプログラムはリリースまでに数年かかることも多くありました。現在のプラクティスでは、優れた機能を持つソフトウェアアプリケーションの開発を続ける一方で、イノベーションのペースを上げることに重点を置いています。企業はウォーターフォール方式から移行し、ほとんどの企業が 2001 年に最初に公開されたアジャイル SDLC のいずれかの形式を採用しています。

アジャイル開発では、大規模なモノリシックリリースを複数のミニリリースに分割することが推奨されています。各リリースは 2 ～ 3 週間のスプリントに分割して、アプリケーションの開発・検証を自動化しています。これにより、企業はイテレーションがすばやくできます。アジャイル開発では、ウォーターフォール型のアプリケーションによくある不定期でモノリシックな導入の代わりに、新機能のリリースを 1 日数回にわたって行い、ソフトウェアを一度にすべて開発するのではなく、段階的に開発します。

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

ところで、これらのアプリケーションのセキュリティについてはどうでしょうか。1970 年当時、ほとんどのハッキングはアプリケーションを実行しているマシンの端末に物理的にアクセスして行われていました。また、相互接続されているマシンは非常に少なかったため、外部のアクターがアプリケーションセキュリティに影響を及ぼすリスクも少なかったのです。ソフトウェア開発の新しい方法論が数年にわたって実践される一方で、セキュリティが SDLC の中で脚光を浴びることはめったにありませんでした。

こうしてアプリケーションセキュリティは、アプリケーションサポートに特化した IT セキュリティ部門の担当となり、アプリケーションのテストは、リリース後にしか行われていませんでした。このテストは本番環境で、1 年ごとに行われることがほとんどでした。残念ながら、これは潜在的な脆弱性が「野放し」の状態になることを意味しており、発見して対策を取るまでに数週間から数か月間もハッカーが悪用できる状態でした。その結果、ほとんどの企業は本番テストを補完するため、リリース前のセキュリティテストも実施するようになりました。この補完テストはリリースのクリティカルパスに配置され、アプリケーションのコードを本番環境に実装する前にセキュリティチェックに合格することが求められました。

多くの場合、このセキュリティテストのステップには数週間かかり、リリースサイクルを長期化させるだけでなく、さらに悪いことに、その結果を予測することは完全に不可能でした。セキュリティテストで数件の脆弱性が発見された場合、数日間で修正できることもあれば、数十件から数百件の脆弱性が発見されることもあります。発見された脆弱性を修正するには、コンポーネント全体を置き換えるような大幅なコード変更が必要なこともあり、その場合、アプリケーション要件とセキュリティテストの両方で再検証が必要になります。

アプリケーション開発者はこの作業に数週間も手を取られるため、リリースの納期を守ることが難しくなり、納期の遅延が度重なる場合もあります。このため、組織内で多くの摩擦が生じ、企業はリスクを「承認」して脆弱性のあるアプリケーションをリリースするか、納期目標の期待を裏切るかという、いずれも好ましくない選択肢のいずれかを選ばざるを得なくなり、ときには両者を選ぶ場合もあります。さらに悪いことに、SDLC のこの段階で発見された問題の修正には、プロセスの早い段階で修正するよりも 100 倍以上のコストがかかります(これについてはのちほど詳しく説明します)。

時代とともに技術革新が加速し、ソフトウェアのリリース頻度が増加するにつれて、これらの問題はすべて悪化するばかりです。このため、ソフトウェア開発プロセスにおけるアプリケーションセキュリティの役割が再認識され、セキュア SDLC の構築に至ったという経緯があります。

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

SDLC セキュリティの実装は、ソフトウェア開発プロセスのすべてのフェーズに影響します。安全なデリバリーを重視したマインドセットが求められ、要件の収集や開発のフェーズで問題が発見された場合に問題提起を行います。これは、導入したアプリケーションでセキュリティの問題が明らかになるのを待つよりもはるかに効率的で、コストもかかりません。セキュアソフトウェア開発ライフサイクルプロセスでは、SDLC の各フェーズのコンポーネントとしてセキュリティが組み込まれています。

SDLC のすべてのフェーズにセキュリティを組み込むことは、最優先事項として全員が持つべきマインドセットですが、セキュリティの考慮事項と関係する作業は、実際には SDLC のフェーズによって大きく異なります。

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

SDLC の各フェーズは、アプリケーション全体のセキュリティに貢献しなければなりません。これは、SDLC のフェーズごとに異なる方法で行われますが、重要な注意事項が一つあります。ソフトウェア開発ライフサイクルのセキュリティは、チーム全体の最優先事項である必要があるということです。メンバーシップ更新ポータルを開発するチームのセキュアソフトウェア開発ライフサイクルの例について見てみましょう。

フェーズ 1: 要件

この初期のフェーズでは、さまざまな利害関係者から新機能の要件が収集されます。新しいリリースのために収集される機能要件について、セキュリティ上の検討事項を確認することが重要です。

• 機能要件の例:ユーザーがメンバーシップを更新する前に連絡先情報を確認できるようにする。

• セキュリティに関する検討事項の例\: ユーザーは自分の連絡先情報のみを表示でき、他の人の連絡先情報は表示できないようにする。

フェーズ 2:設計

このフェーズでは、対象範囲内の要件を実際のアプリケーションでどうするか、というプランに変換します。ここでの機能要件には一般に何が起こるべきかを記述する一方で、セキュリティ要件としては一般に何が起こってはならないかに注意を向けます。

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

• セキュリティの問題の例: データベースから情報を取得する前に、ユーザーが有効なセッショントークンを持っていることを確認する必要がある。存在しない場合、ユーザーはログインページにリダイレクトされる。

フェーズ 3: 開発

設計を実装して形になる段階になると、通常、セキュリティの観点からコードが適切に記述されていることを確認することに関心が移ります。通常なら、セキュアコーディングガイドラインが確立されており、これらのガイドラインが正しく守られているかどうかをダブルチェックするコードレビューも行われています。これらのコードレビューは手動で行うことも、静的アプリケーションセキュリティテスト (SAST) などのテクノロジーを活用して自動化することもできます。

とはいえ、最新のアプリケーション開発者は自分が記述したコードだけ気にしていればよいというわけにはいきません。最新のアプリケーションの大半はゼロから記述されたものではなく、既存の機能に依存しているからです。つまり、組織でできるだけ早く価値を実現するため、通常は無料のオープンソースコンポーネントを活用して、新機能を開発しています。実際、最近デプロイされたアプリケーションの 90% 以上は、オープンソースコンポーネントで構成されています。オープンソースコンポーネントは通常、ソフトウェアコンポジション解析 (SCA) ツールを利用してチェックされます。

この場合、セキュアコーディングガイドラインとして以下のものが考えられます。

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

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

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

• オープンソースライブラリを使用する前に脆弱性をチェックする

フェーズ 4: 検証

検証フェーズでは、徹底的なテストサイクルを実施し、アプリケーションが当初の設計と要件を満たしていることを確認します。この段階では、さまざまなテクノロジーを活用した自動化されたセキュリティテストを導入できます。これらのテストに合格しない限り、アプリケーションはデプロイされません。このフェーズには、多くの場合、検証とリリースを制御するための CI/CD パイプラインなどの自動化ツールが含まれます。

このフェーズでの検証は、以下のようなものが考えられます。

• アプリケーションのクリティカルパスを表現する自動化テスト

• アプリケーションの正確さを検証するアプリケーション単体テストの自動実行

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

フェーズ 5: メンテナンスと進化

アプリケーションをリリースしたら終わりというわけではありません。実際、見逃していた脆弱性が、アプリケーションのリリース後かなり時間が経ってから見つかることもあります。こうした脆弱性は、開発者が記述したコードにある場合もありますが、多くはアプリケーションを構成するオープンソースのコンポーネントに見つかっています。そのため、アプリケーションのメンテナンス担当者が本番環境で発見する、これまで見つかっていなかった「ゼロデイ脆弱性」の数が増加しています。

これらの脆弱性には、開発チームがパッチを適用する必要があります。このプロセスでは、アプリケーション機能の大幅な書き換えが必要になる場合があります。この段階では、ホワイトハッカーが実施した外部の侵入テストや「脆弱性報奨金制度」として知られる一般公開プログラムなど、他のソースから脆弱性が発見される場合もあります。このような本番環境の問題への対応は、将来のリリースで計画的に対応する必要があります。

SSDLC の利点

セキュア SDLC は、SDLC のできるだけ早い段階でセキュリティチェックを統合することを意味する「シフトレフト」構想の究極的な例です。

統合は開発チームが適切にリリースを計画する際に役立ち、リリースのタイムラインに影響を与える可能性のある問題を見つけて対処しやすくなります。これは、アプリケーションを本番環境にデプロイしてから不具合が見つかるよりもはるかに良いことです。つまり、SSDLC によってリリースを計画的に進めることができます。

また、SSDLC の中核部分となるセキュリティへの取り組みは、開発チームが中心となって行っています。これにより、別のチームが後からバグを修正するのではなく、ソフトウェアを開発したドメインの専門家が問題を修正できます。開発者は自分のアプリケーションの全体的な品質に責任を持つことができ、安全なアプリケーションを本番環境に実装できます。

SDLC プロセスでセキュリティテストを行うことは、手間や費用がかかるように思えるかもしれませんが、現在その大部分は自動化されています。特に、開発オペレーションまたは DevOps についてはそう言えます (以下で詳しく説明します)。セキュア SDLC 環境では、DevOps とアプリケーションの機能を実装するエンジニアが緊密に連携する必要があり、この連携を SDLC に組み込む必要があります。

こうした問題を早期に解決することで、開発チームはアプリケーションのトータルコストを削減できます。下のグラフに示すように、SDLC の後半で問題を発見した場合、その問題を解決するために必要な開発コストは、100 倍にもなります。

IBM System 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.重大な問題から対処する

発見されたすべての脆弱性に対処するのではなく、最も重要な問題や修正可能な問題に重点を置きます。新しいアプリケーションや小規模なアプリケーションでは、存在するすべてのセキュリティ問題を修正できるかもしれませんが、古いアプリケーションや大規模なアプリケーションでは必ずしもそうできるとは限りません。また、トリアージ方式も有効です。これにより、セキュリティの問題が本番システムに入り込むのを防ぐだけでなく、既存の脆弱性について優先順位をつけ、時間をかけて対処することができます。

SDLC の保護のベストプラクティスのヒントについては、SDLC のベストプラクティスの完全なリストをご覧ください。

SSDLC と DevSecOps

SSDLC と DevSecOps の関係について話し合っておくことは重要です。両者は同じ意味で使われることがあり、混乱を招くことがあります。SSDLC と DevSecOps は密接に関連していますが、実際には補完的なプラクティスです。SSDLC と DevSecOps はいずれも、開発者が機能仕様を満たすためにコードの記述・テストを行うだけでなく、それ以上のことができるようにアプリケーションのオーナーシップを強化することを意図したものです。

セキュア SDLC はアプリケーションの設計・開発方法を重視しています。DevSecOps は各アプリケーションの本番環境のオーナーシップを従来の IT 部門から開発部門に移すことを目的としています。これにより、開発者は可能な限りビルド、テスト、リリースといった各プロセスの自動化に集中できます。

DevOps と DevSecOps は、ソフトウェア開発者の役割を再定義する革命の火付け役となりました。もちろん、これにはクラウドの変革など他の大きな変化も寄与しています。しかし、開発者の能力向上とセキュリティテストの迅速化は、ほとんどの現代企業の成功の鍵となっていますが、アプリケーションセキュリティを単なる自動化の課題と見なすのは間違いです。むしろ、開発プロセスの早い段階でセキュリティに対する意識して考慮できるよう、文化やプロセスの改革を推進することが重要です。この考え方は SSDLC と呼ぶか DevSecOps と呼ぶかにかかわらず、ソフトウェア開発ライフサイクルのすべての部分に浸透していなければなりません。

より安全な未来へ向けて

従来のように本番環境で脆弱性をテストする方法では、もはやアプリケーションの安全性確保には不十分です。ソフトウェア業界の進化に伴い、攻撃の種類も進化しています。安全なアプリケーションの実装と保守には、アプリケーション開発プロセスのすべてのステップでセキュリティを確保する必要があります。これは、要件収集の段階でセキュリティ動作について質問すること、セキュリティ指向マインドセットに基づいてチームの文化とプラクティスを調整すること、導入プロセスで自動検証を実装すること、そしてその他多数のプラクティスによりセキュア SDLC プロセスを開発することを意味しています。

SSDLC では、セキュリティリスクをシフトレフトして、メンテナンスフェーズから後戻りせずに、要件フェーズでセキュリティ問題の原因に対処できます。開発の各フェーズでセキュリティに重点を置くことで、結果的にアプリケーションの安全性を高めることができます。