DevSecOps のメリットとは
一般的には、開発からデプロイに至るプロセスが高速化するほど、セキュリティの問題が起こりやすくなると考えられています。実際、開発のアジャイル化、高速化、機能の高度化が進むにつれて「セキュリティ面に問題はないのか？」「プロジェクトのセキュリティを強化するにはどうしたらよいだろう」といった不安がわきあがってきます。
DevOps が業界に浸透する過程において、セキュリティはずっと置き去りにされており、今ようやく改善が見られるようになったばかりです。アジャイル開発と高頻度のコード デプロイによって、アプリの脆弱性が連鎖する結果にもつながっています。大半の DevOps スタックでは、セキュリティよりも機能性とスピードが優先されており、セキュリティ チェックは進行を遅らせる原因にもなるため、徹底的に行うことはあまり奨励されていません。しかし、2018 年にブリティッシュ エアウェイズが起こしたセキュリティ違反が大規模な情報流出事件につながったことから、DevOps 手法を改善し、できるだけ多くのセキュリティ チェックを導入することの重要性が明らかになりました。特に、この事件によってブリティッシュ エアウェイズが支払うことになった代償の大きさ (GDPR 違反の罰金額は約 2 億 3,000 万ドル) に目を向けると、セキュリティの重要さがよくわかります。
DevOps 対 DevSecOps
開発と運用が融合するのは自然な流れです。開発チームと運用チームは「機能性の高いアプリをできるだけ早く顧客に提供する」という同じ目標を掲げています。その目標を達成するうえで、セキュリティは厄介な障害物と見なされがちです。たしかに、監査やテストのような時間のかかるプロセスを必要とするセキュリティは、リリースを遅らせ、DevOps プロセスを阻害する要因に思えます。そうすると、セキュリティをソフトウェア開発ライフサイクル (SDLC) に欠かせない補完的な要素としてではなく「障害物」と認識してしまうのも無理はありません。ここで「DevOps 対 DevSecOps」という弁証法的な対立が生まれるわけです。しかし昨今、SDLC でセキュリティの「シフト レフト」を行わないと DevOps 時代を生き抜けないという事実に、多くのセキュリティ担当者が気付き始めています。SDLC の早い段階でセキュリティに取り組むことで、アジャイル開発の障害が少なくなります。DevOps にセキュリティを組み込めば、開発プロセスに多少の遅れは発生するものの、市場投入までの時間は短縮され、会社の利益の拡大にもつながるでしょう。
そう考えると、DevOps と DevSecOps は必ずしも対立するものでないことがわかってきます。
一見対立しているように見えるものの、両者に矛盾はありません。セキュリティを確保することの重要性は既に共通認識となっており、そのためには開発、運用、セキュリティの早期組み込みの相乗効果を高める方法が有効です。セキュリティをワークフローの重要な要素に据えることは、必ずしも DevOps を否定することではなく、古いシステムを進化させることであると言えます。
それでは、DevOps から DevSecOps にスムーズに移行するにはどうしたらよいでしょうか。
いくつかのルールとベストプラクティスを紹介していきます。
ルール 1: 使いやすいツールと自動化を活用する
DevOps 手法にセキュリティを組み込もうとすると「スピード」と「セキュリティ意識の欠如」という 2 つの問題にぶつかります。したがって、DevOps から DevSecOps に移行するときは、そのプロセスが開発者にとってスムーズで簡単なものかどうかを考慮する必要があります。開発ライフサイクルにスムーズにセキュリティを組み込みたいなら、誤検出、使いにくいセキュリティツール、冗長なコードレビューといった面倒な作業で開発者を悩ませないことが重要です。また、セキュリティはワークフローのなるべく初期段階で自動化します。そうすることで、セキュリティの問題を早期に検出できます。そして何より、脆弱性の問題を修正するのは開発者であるため、開発者が適切な修正方法を知っているか、信頼できるガイダンスを所有していることを確認しておく必要があります。
さて、その最初のステップとして何を行えばよいのでしょうか。
開発者がセキュアなアプリケーションを簡単にすばやくデプロイできるような体制を整えることが必要です。そのために、開発者にとってわかりやすく直観的なツールを用意し、セキュリティ テストプロセスを自動化します。
ここで便利なのがアプリケーション セキュリティ テスト (AST) ツールです。AST の主な種類としては D(dynamic)AST と S(static)AST の 2 つがあります。SAST ツールはコードの脆弱性をスキャンし、DAST ツールは機能するようになったアプリケーションをスキャンします。DAST ツールは、ハッカーのようにアプリケーションを攻撃してセキュリティ上の問題を検出します。このため、脆弱性に関する実質的なエビデンスをより多く報告できます。ワークフローの早い段階でコードをスキャンする SAST スキャナーのほうが適切に思われるかもしれませんが、実は SAST スキャナーは誤検出や関連性のない報告がかなり多く、開発者の手を煩わすことがあります。これに対し DAST は、結果が明瞭で、特に脆弱性についてよくわかるようになっているので、開発者はリスクの重大さをすぐに把握できます。優れた DAST スキャナーは、複数のプラグインや、CircleCI のような人気の CI ツールと統合するための強力な API も備えています。たとえば Probely は、見つかった問題の修正方法を示すカスタム ガイダンスを提供してくれます。
DevOps から DevSecOps への移行の足がかりとしては、DAST スキャナーがお勧めです。DAST スキャナーは脆弱性のスキャンが容易でセキュリティリスクも把握しやすいため、開発者のストレスが軽減されます。さらに、CI/CD パイプラインとのシームレスな統合も可能です。
ルール 2: 優先順位を付ける
DevSecOps で重要なのはスピードであり、スピードを確保するには優先順位付けがカギとなります。既に確立されている DevOps 手法にセキュリティを組み込むとき、自動化やスピードを損なうようなことがあってはいけません。そのための優先順位付けです。アプリケーションと脆弱性をリスクにマッピングします。たとえば、顧客の機密情報を扱うアプリケーションなら、セキュリティをより重視する必要があります。さらに、脆弱性のコンテキストをビジネスまたは会社への潜在的なリスクにマッピングします。そのとき、リスクスコアが高い脆弱性を優先しましょう。DAST スキャナーの 1 つ、Probely はこの処理を自動的に行います。脆弱性をランキングし、コンテキストを考慮して 3 つのカテゴリ (高、中、低) に分類するのです。
優先順位を付けると、重要なポイントにフォーカスしやすくなるため、開発者の負担が軽減され、Dev-Sec の相乗効果が生まれます。
ルール 3: デモンストレーションを見せて教育する
社内にセキュリティを導入するとき、DevSecOps 手法を組み込み、ルールを設定し、それに従うようユーザーに呼びかけるだけでは不十分です。DevSecOps は単なる手続きというより企業文化に近いものであり、組織構築や意思決定の方針にも直結します。まずは、開発者などの従業員を対象に、セキュリティについて教育するところから始めましょう。手始めに、この Web アプリケーション セキュリティ チェックリストを提供します。開発者や社内スタッフは、セキュリティの重要性を理解していないことが多く、さまざまなリスクを過小評価してしまいがちです。適切な教育のためには、プロセスとリスクのデモンストレーションを見せることをお勧めします。
開発者を対象にセキュアなコーディングとセキュリティ意識について教育するだけでなく、セキュリティを企業文化として採用することも重要です。DAST ツールで検出した脆弱性やセキュリティホールのエビデンスは、技術スタッフだけでなく、全社規模でデモンストレーションする必要があります。技術スタッフと一般ユーザーの両方を標的に、巧妙に作られた偽のフィッシング攻撃やソーシャル エンジニアリング攻撃を仕掛けることで、視覚性やエンゲージメントも高まります。だからこそ、セキュリティに関する教育と認知向上が不可欠なのです。まず、模擬のフィッシング攻撃を仕掛けて、フィッシング攻撃がどのような影響を及ぼし得るかデモンストレーションするところから始めましょう。悪意のあるメールを送信し、そこに含まれるリンクをクリックして機密データを漏えいさせてしまう従業員がどのくらいいるか確認します。そうすることで、どのような攻撃によるリスクがあるのか紹介しつつ、社内の非テクニカルユーザーを教育することができます。
ボーナス ルール: ルールは破られるもの
DevOps と DevSecOps の利点は、既存のルールを曲げたり、自分でルールを作ったりできる点です。会社に合わないルールがあっても、逃げ道が見つかるので心配はいりません。DevSecOps 手法はニーズに応じて自由に変更できます。いろいろなツールを試して、侵入テストやバグ バウンティを実施したり、ネットワークセキュリティに時間と予算を投資したりすることが自社に適しているかどうか検討してください。標準的なセキュリティ ルールの「正しい使い方」が存在するわけではないのです。
最適な DAST ツールを探す
優れた DAST ツールや脆弱性スキャナーは多数ありますが、どれを利用するのが一番良いでしょうか。その答えはご自身の好み、予算、会社の規模によって異なりますが、一般には、スピード、CI ツールや他のアプリケーションとの統合のしやすさ、強力な API が用意されているかどうか、開発者向けの直観的な UI が備わっており、検出された脆弱性について適切な情報 (修正方法、エビデンス、説明) を提供できるかどうかを考慮して決定するのがよいでしょう。CircleCI ユーザーは、対応する Orb が公開されている DAST ツールを使用すれば、CircleCI ワークフローにスムーズにセキュリティを組み込めるのでお勧めです。
たとえば Probely なら、Probely の Orb を使用して、Web アプリケーションから 1,000 以上の脆弱性を検出できるうえ、上記のすべての機能を備えています。Probely は直観的で、適切な情報を提供してくれる点が、開発者に高く評価されています。脆弱性のエビデンスに加え、アプリの構築に使用した言語やテクノロジーを検出し、それに基づいて、脆弱性を修正する方法を提示してくれる点は大きなメリットです。
この記事は、DevSecOps に関するシリーズ記事の一部です。同シリーズの他の記事は、以下のリンクからご覧いただけます。
