DevSecOps とは?

DevSecOps とは、開発のあらゆるフェーズにセキュリティの実践を組み込むことで、CI/CD パイプラインを遅延させることなく脆弱性を早い段階で確実に解決するものです。

DevSecOps では、セキュリティのテストと実践をソフトウェア開発プロセスに組み込むことの重要性が強調されています。 早い段階でセキュリティに対応することで、セキュリティ脆弱性のリスクを負うことなく迅速なデリバリーを実現できます。

CI サーバーを使用する理由

DevSecOps は、DevOps 手法に基づくソフトウェア開発手法です。 「DevOps」が「開発(Development)」と「運用(Operations)」を組み合わせているように、「DevSecOps」も開発、セキュリティ、運用を組み合わせた造語です。 「Security(セキュリティ)」を追加することにより、セキュリティの考慮事項をソフトウェア開発ライフサイクルのすべての段階に組み込むことの重要性が強調されています。

DevSecOps の 3 要素

DevSecOps の狙いは、チームがセキュリティ脆弱性のないコードベースを維持しながら、ソフトウェアをより迅速かつ効率的にデリバリーできるようにすることです。 この戦略により、組織とユーザーの両方をサイバー攻撃から保護することができます。

DevSecOps と DevOps の違い

DevOps 手法はソフトウェアの品質を改善してバグを減らしながら、デリバリーを高速化することを目的としています。 DevOps はアジャイルムーブメントに根ざしており、ソフトウェア開発とデリバリーにおける従来のウォーターフォール型手法の問題を解決するために編み出されました。

DevOps は数年間かかる可能性のある設計、開発、統合、テスト、およびリリースを線形的に進めるプロセスではなく、チームがこれらのサイクルを通して作業を迅速かつ頻繫に進めることを奨励するものです。 これを実現するため、DevOps ではデリバリー時間を短縮して迅速なフィードバックを提供することで、継続的な改善の好循環を作り出す堅牢な自動 CI/CD プロセスが推奨されています。

DevSecOps は DevOps との違いはどこにあるのでしょうか? 実際、DevOps はセキュリティを除外することをまったく意図していません。 しかし、DevOps ムーブメントによって開発チームと運営チームの間に壁がなくなったとしても、情報セキュリティチームは他のチームから切り離されていることが一般的です。 DevSecOps という言葉は、SecDevOps、DevOpsSec、Rugged DevOps などの他の呼称も含め、この状況を解決する目的で使用されるようになりました。

「DevSecOps」という呼称を使用することで、ソフトウェア開発とデプロイのプロセスにセキュリティを考慮することをチームに促しています。 これには以下の内容が含まれます。

  • セキュリティの考慮事項に対する共通の理解と責任の文化を浸透させる。
  • CI/CD パイプラインの自動テストの部分にセキュリティチェックを組み込む。
  • すべての依存関係や CI/CD パイプライン自体を含め、ソフトウェアサプライチェーンの安全を確保する。
DevSecOps の実践

「シフトレフト」テストでバグをより迅速かつ簡単に発見して修正できるようになるのと同様に、セキュリティの実践も開発プロセスの早い段階で着手する方が組み込みやすく、効果的になります。

DevSecOps が重要な理由

ソフトウェアが持つセキュリティ脆弱性の潜在的な影響は、どれだけ誇張してもし過ぎることはありません。

ソフトウェアのセキュリティ侵害により、金銭的損害や評判の損失だけでなく、社内文書や顧客の個人情報といった膨大な量の機密データが漏洩する結果にもなっています。 適用される司法管轄によっては、ユーザーデータの漏洩を理由に多額の罰金だけでなく、法的責任も課される場合があります。

それにもかかわらず、ソフトウェアセキュリティに対する従来の手法では、セキュリティは資産ではなく、むしろ障害のように感じられることがあります。 セキュリティ監査や報告によって進捗が遅れた場合、最新の機能をユーザーの手元に届けられなくなるからです。 しかし、ソフトウェア開発ライフサイクル(SDLC)のセキュリティの重要性を軽んじた場合、次のサイバー攻撃で大々的に報道されてしまう恐れがあります。

このような脆弱性を突いた攻撃はニュースの見出しを飾ってきましたが、その原因はいたってありきたりなものです。 脆弱性は人がコードを作成し、人がミスを犯すために存在します。 このようなミスは過去に他人が犯したものであることもあり、(どこを調査すべきか知っていれば)簡単に発見できます。 ただし、過去にはなかった要因が組み合わさって生じている新しいタイプのミスである場合もあります。

さらに自体を複雑化しているのは、ほぼすべてのソフトウェアにオープンソースか独自の依存関係が組み込まれているため、サードパーティのコードに脆弱性が含まれないことを保証できないということです。 そのため、ソフトウェアサプライチェーンの安全を確保することは、独自ソースコードのセキュリティを評価するのと同じくらい重要となります。

では、SDLC にどのようにセキュリティを組み込めばよいのでしょうか。 DevSecOps の手法では、より高速かつ安定したリリースを実現したのと同じ原則が適用されます。セキュリティ対策を前倒しすることで、早い段階で頻繁に対処することができます。

シフトレフトテスト

一見すると、CI/CD プロセスにステージを追加し、セキュリティチームによるソフトウェアのテストとレビューを可能にするだけでセキュリティ対策を前倒しできるように思えるかもしれません。

手動セキュリティテスト(後述します)を実施する余地はあっても、セキュリティ要件への取り組みを CI/CD プロセスの最後のステップに限定すると、次のいくつかの理由で迅速かつ定期的なフィードバックのメリットを逃すことになります。

  • 手動テストの実行には時間がかかるため、デプロイを遅らせたり、セキュリティテストをリリースの一部に限定して行ったりする必要があります。
  • セキュリティの問題が発見された頃には関連するコードを書いた担当者が他の作業に移っているために、修正や推奨事項の実現が難しくなります。
  • 最後に付け加えると、セキュリティテストをプロセスの 1 つのステップに限定すると、セキュリティチームと組織の他のチームの間に排他的な感情が生じます。 これでは両者とも便利で安全なソフトウェアをリリースする目標を達成できません。
CI/CD プロセスにどのようにセキュリティテストを組み込むのか?

シフトレフトセキュリティテストの実施方法

では、セキュリティのシフトレフトアプローチとは実際に何を意味するのでしょうか? どの状況にでも当てはまるようなソリューションはありませんが、SDLC全体にセキュリティを統合するには、次のようなツールと手法を使用できます。

セキュリティ担当者を任命する

共同責任のカルチャは重要ですが、開発チームにソフトウェアセキュリティの全責任があることを伝えるだけでは不十分です。 最新の攻撃ベクトルとマルウェアの発展状況を理解するのは本業の傍らで行えることではなく、すべての人が同じレベルの専門知識を備えられると期待してはいけません。

他の人を指導してベストプラクティスを共有できるセキュリティ担当者を多分野にわたる知識を備えたチームに加えることで、理解を深めて、セキュリティ専門家とのコラボレーションのカルチャを促進することができます。

セキュリティを設計の制約とする

理想を言えば、セキュリティはコードを書く前に考慮すべきです。 ユーザーストーリーに組み込み、バックログのレビュー会議で検討し、スプリントを計画する際に議論する必要があります。 新機能への取り組み方を決める際には、新機能から生じる可能性のあるリスクやそれらを緩和する術について検討する時間を持つようにしましょう。

STRIDEなどの脅威モデリングの戦略を採り入れたり、OWASPといったツールの早見表を使用したりすると、新しいスキルを習得しながら、順調に進めることができます。 設計の段階でセキュリティを考慮すれば、すべてを見逃さずに済むというわけではありませんが、DevSecOpsカルチャを促進するには良い出発点と言えます。

STRIDE 脅威モデリング

自動テストの対象にセキュリティを含める

自動化は、DevOpsの中心的な考え方です。 タスクの進行が加速し、安定的に実行できるようになるため、より創造的な仕事に人材を投入できるようになります。 定期的かつ頻繁に、ユーザーにソフトウェアを提供したいのであれば、自動セキュリティテストをパイプラインに組み込むのは絶対といえます。

自動ユニットテスト、自動インテグレーションテスト、および自動エンドツーエンドテストを作成する際は、セキュリティ機能とほかの機能を同等に考える必要があります。 チームがデザインプロセスの一環として、セキュリティ要件をユーザーストーリーに組み込み、脅威モデルを検討してきたのであれば、セキュリティ機能を含めたテストを追加するのが当然です。

CI/CD プロセスにセキュリティテストツールを追加する

独自に作成するテストのほかに、コードの品質に確信を持つための助けとなるセキュリティテストツールが各種あります。 従来のセキュリティスキャンツールは自動 CI/CD パイプラインにはあまり適していませんでしたが、現在は自動化用に設計された CI/CD セキュリティテストツールを使用できるようになっています。 このようなツールは CI/CD パイプラインに組み込まれ、結果をダッシュボード経由で報告したり、バグ追跡ツールに直接送信したりできます。 すべての自動テストと同じように、できる限り迅速にフィードバックを提供できるよう、テストを構造化することができます。

静的アプリケーションセキュリティテスト(SAST)ツールは、静的コード解析を実施して、ソースコードにバッファーオーバーフローや SQL インジェクションといった既知のセキュリティ問題が潜んでいないかどうかをチェックします。 静的解析はソースコードに実行されるため、CI/CDパイプラインの早い段階で、変更がコミットされるとすぐに実行できます。

SASTツールは言語固有であり、IDEと統合して、作成しながら継続的にフィードバックを得たり、オンデマンドでテストを実行するオプションが備わっているものもあります。 SASTツールは、脆弱性を含む特定のコード行を開発者に示すことで、対象を絞ったガイダンスを提供するため、課題をより迅速に修正することができます。 ただし、誤検出が課題となることがあります。そのため、SAST結果が雑音になってしまわないように、特定のアラートをミュートしたり消したりできる必要があります。

CI/CD での SAST ツールの使用

動的アプリケーションセキュリティテスト(DAST)は SAST と切り離すことのできないものです。 このテストでは、実行中のアプリケーションにブラックボックステストを行い、クロスサイトスクリプティング、コマンドおよびSQLインジェクション、そして安全でないサーバー構成などの既知の脆弱性をチェックします。 DASTツールでは、アプリケーションがテスト環境に構築してデプロイされている必要があるため、通常、CI/CDパイプラインの後の方で使用されます。

ソフトウェアサプライチェーンの保護

サイバー攻撃の可能性は計り知れません。 悪意のある人物は多くの場合、広く使用されているソフトウェアにセキュリティ上の欠陥を見つけます。 そのような攻撃や同様の攻撃は、ソフトウェアサプライチェーンの安全を確保することの重要性を本質的に思い出させてくれます。

「ソフトウェアサプライチェーン」とは何を指すのでしょうか? 簡単に言えば、ソフトウェアの開発とデリバリーに関わるものすべてです。 すべてのソフトウェア開発には、再利用可能なコンポーネントやライブラリ、IDE、フレームワーク、ビルドツールに至るまで、他のソフトウェアが必要となります。 ソフトウェアサプライチェーンのセキュリティには、使用するソフトウェアのセキュリティの評価と、開発プロセスのセキュリティの確保が必要です。

前者はソフトウェア構成またはコンポーネント解析(SCA)ツールを使って評価できます。 SCAツールは、開発者が導入した依存関係だけでなく、サプライチェーン全体に存在する依存関係をクロールします。特に、プロジェクトに新しい依存関係が頻繁に追加されることを考えれば、コンピューターに任せるのが最適な作業です。

ソフトウェアサプライチェーン

SCAツールはCI/CDパイプラインの一環として自動的に実行するだけでなく、中にはその場でフィードバックを提供できるようにIDEプラグインとして提供されているものもあります。 静的セキュリティテストと動的セキュリティテストと同様、SCAテストの対象もツールが認識している脆弱性に限定されるため、選択したツールが持つ新しい攻撃の情報を定期的に更新し、製品と組織に関連性のある部分がテスト対象となるようにする必要があります。

レッドチーム演習を組み込む

レッドチームの概念は戦争ゲームに始まったもので、攻撃シミュレーションにおいて、味方のメンバーに敵を演じるように指示し、自分の防御と戦略に潜む弱点を特定することを目的としています。 これと同じ手法はソフトウェア開発でも導入され(時には侵入テストや倫理的ハッキングを装う形で)、予期せぬ新たな脆弱性を発見するのに大いに効果を発揮してきました。

レッドチーム演習が効果的に行われるには、テスト対象のシステムの開発にレッドチームが関与することはできません。 探索的テストと同様に、レッドチーム演習にはテスターが既存の枠にとらわれずに考えて、意図されていない方法でソフトウェアを使用できなければなりません。

レッドチームはステージング環境(できる限り本番環境に似たものが理想)とライブの本番システムのどちらでも作業できます。 ライブの本番環境を使用する場合は、ソフトウェアの障害モードかユーザー(と経営幹部)の忍耐力が非常に高いことを確信しておく必要があるでしょう。

すべての脆弱性をバグとして扱う

DevSecOpsのアプローチでは、全ての人がソフトウェアのセキュリティに対する責任を負うことになります。 そのため、セキュリティの課題を「通常の」バグとは別の課題として考えるのはやめましょう。 システムで検出されたあらゆる障害や脆弱性は、ほかの課題と同じバックログに入力し、優先する必要があります。

セキュリティチャンピオンだけでなく、チーム全体で脆弱性の解決に取り組むと良いでしょう。 そうすることで、セキュリティの知識や専門知識を積み、現在のコードベースや今後のプロジェクトにそれらのスキルを活かすことができます。

本番を監視

これまでに見たSDLCのすべてのステージであらゆる取り組みを行っても、ハッカーがライブシステムの弱点を見つけ出すリスクはなくなりません。 それでも、組織とユーザーの両方を保護するには、ファイアウォールや監視ツールに投資する価値があります。 これらの最新の防御として追加されたランタイムアプリケーション自己保護(RASP)ツールは、不審な動作を自動的に検出してブロックすることができます。

まとめ

  • DevOps 手法には、ビルド対象を改善し、変更をより迅速にリリースできるように設計された通常のフィードバックループが含まれます。
  • セキュリティ対策を早期に実践するということは、SDLC のすべてのステージでセキュリティをチーム全体の考慮事項とすることを指します。
  • CI/CDパイプラインにセキュリティを組み込むと、アプリケーションのセキュリティに関するフィードバックも定期的に得られるようになるため、ほかの機能と同様に、セキュリティの改善も行えるようになります。
  • ソフトウェアサプライチェーンのセキュリティを確保することは、アプリケーションコードを保護するのと同様に大切です。 既知の脆弱性をチェックし、それに対する保護を適用すれば、既知の攻撃に対して無防備のままであるのではなく、少なくとも、攻撃者に対処できるソフトウェアを得ることができます。
  • 新しい脆弱性はすべてバグとして扱い、優先して修正とテストを行うことで、将来的にソフトウェアをより堅牢なものに仕上げることができるようになります。
  • DevOps と DevSecOps はツールやプロセスだけでなく、文化も重視しています。 セキュリティをソフトウェア開発プロセスに組み込むには、責任を共有する文化が必要です。