この記事はマイケル・コテ（Michael Coté）が執筆したブログの翻訳版です。
これまで私は、DevSecOps と従来の DevOps の違いに明確な答えを出せずにいましたが、この 1 年ほどでようやく考えがまとまってきたように思います。簡潔に言うと、DevOps の考え方のもと、多くの自動化とプロセス変更によって運用上の課題を開発により近づけることで、より円滑にソフトウェアのデリバリを行うことができる、ということです。私の考える DevSecOps と DevOps の違い、そして DevSecOps だけが持つ特長は以下の 3 つです。
- セキュアなソフトウェア サプライチェーン：これは、「このソフトウェアを構築／デプロイするために使われたすべてのコンポーネントを把握しており、それらのコンポーネントには信頼がおける」ということを表すしゃれた言い方です。また、近年起こっているような、悪意のあるコードを持ちこもうとする第三者に対して抵抗力のある、信頼性の高いCI/CD パイプライン自体もこれに含まれます。
- 業務文化とコラボレーションの改善：開発者とセキュリティ担当者の間の協力と理解を深めます。多くのガバナンスの実践と同様、セキュリティの領域でも統治する側（セキュリティ担当者）と統治される側（開発者）の関係は通常、友好的とはいえません。開発者からみればセキュリティ担当者は「ノー」ばかり言う制御不能な支配者であり、セキュリティ担当者からみれば開発者は知識の足りないプログラマに見えがちですが、このような関係性からは何も生まれません。DevOps と同様に、「業務文化」をより有益なものに変えることが DevSecOps の役割です。
- 自動化とガードレール：セキュリティ ポリシーの適用を自動化し、デフォルトとテンプレートを提供することで、開発者が最初からセキュアなコードとアプリケーション構成をできるだけ簡単に書くことができるようにします。従来、開発者がセキュアなコードを書いているかどうかの検証は手作業で行われ、ミスも起こりやすいプロセスでした。しかし、優れたプラットフォームがあれば、ほとんどの作業を自動化できます。
もちろん、これら 1 つひとつが DevOps から派生した新しい合成語「DevSecOps」に値するほど斬新かつ重要なものであるか深く掘り下げることもできますが、そんな時間がない方は、以下の記事をお読みください。
DevSecOps はセキュアなソフトウェア サプライチェーンを DevOps に統合
シンプルなサプライチェーン
近年、「セキュアなソフトウェア サプライチェーン」という考え方が、DevSecOps の基盤となってきています。セキュアなソフトウェア サプライチェーンは「サプライチェーン」から始まる語ではありますが、「パイプラインの構築」の名称を変えただけです。上の図は単純化した例です。パイプラインは、ソフトウェアのコンパイル、統合、テスト、最終リリースに至るまで、さまざまなアクティビティで構成されています。それでは、セキュアなソフトウェアサプライチェーンを構成する 3 つの要素について見ていきましょう。
インプットと依存関係の管理
第 1 に「ソフトウェア サプライチェーン」とは、アプリケーションを構築／デプロイするために必要なすべてのインプットを指すと考えるべきでしょう。これらのインプットは開発者が書いたコードから始まり、アプリケーションのライフサイクルを通じて使用される構成、アプリケーションが依存するサードパーティのフレームワーク、ライブラリ、その他のサービス（テキスト メッセージの送信など）、アプリケーションを作成するためのその他の要素で構成されています。開発者は、これまで以上にオープンソースやサードパーティのサービスに依存しています。つまり自社のサプライチェーンもサードパーティのコードを検証し、信頼性を確認する必要があります。
サードパーティのコードに依存すると、すぐに推移的な依存関係の問題が発生します。たとえば、ログ収集フレームワークに依存するフォント レンダリング ライブラリを使用する PDF 生成ライブラリを使う場合を考えてみましょう。ログ収集フレームワークにセキュリティ上の問題があると、PDF 生成ライブラリやフォント レンダリング ライブラリがセキュアかつ検証済みで、信頼できるものであっても、セキュリティ上の問題が発生してしまいます。実際、最近起きた Log4j のセキュリティ問題は、まさにこのようなものでした。
DevOps の考え方における大きなイノベーションの 1 つは、アプリケーションをデプロイして実行するために必要な構成をコードとしても扱うことです。アプリケーションの開発、テスト、デプロイ、本番環境での管理にはさまざまなグループが関わっているため、アプリケーションのライフサイクルを通じてこの構成を見失ってしまうことはよくあります。しかし DevSecOps の考え方ではあってはならないことで、構成は追跡／保護すべき主要なインプットなのです。
構築
第 2 に、ソフトウェア サプライチェーンは「継続的インテグレーション」として知られるアプリケーションの構築と検証に使用される構築プロセスです。これは、数十年にわたって確立されてきたプラクティスとツールのセットです。DevSecOps の考え方において、構築フェーズではポリシーを実施したり、ソフトウェアのさまざまなコンポーネントを入れ替えたりすることがあります。たとえばセキュリティの問題が発生したとき、高度なセキュア ソフトウェア サプライチェーンでは開発者の手を煩わせることなくオペレーティング システムやフレームワークのパッチを適用してアプリケーションを再構築できます。これはまさに金融機関のウェルズ・ファーゴなどが行っていることで、本番環境に素早くパッチを当てるだけでなく、週に数回、本番環境全体を再構築してマルウェアを一掃することが可能です。
セキュアなデリバリ
第 3 に、一般的にソフトウェア サプライチェーンは継続的デリバリ（CD）という別のパートで構成されています。これにより、アプリケーション ビルドの本番環境へのリリースを自動化できます。（継続的デリバリと継続的デプロイの間には区別がありますが、語彙上の些細な違いでしかなく、カクテルパーティを終わらせて部屋を片付けたいときの格好の話題にはなりそうです）。
セキュアなサプライチェーンの「セキュア」とは、コード、設定、サードパーティのフレームワークやサービスといった入力がセキュアで、セキュリティ ポリシーに従っているかを確認することです。主にインプットが思った通りのものであるかどうか、悪意を持った人がアプリケーションにマルウェアを組み込んでいないかを追跡／検証します。下の図は、サプライチェーンのセキュリティ上の問題点を示しています。
ソフトウェアサプライチェーンにおける攻撃のベクトル
セキュアなソフトウェア サプライチェーンではもちろん、これらの問題やその他のセキュリティ課題を防ぐことを目指しています。
DevSecOps による業務文化とコラボレーションの改善
「セキュリティは今や全員の責任である」という言葉は、DevSecOps の議論においてよく聞かれる言葉です。適切なツールとプロセスを導入すれば、その原則に従うことは可能ですが、人々の行動や互いの業務のやり方を変えていくことも必要です。つまり DevSecOps の適用に伴って組織内のセキュリティ文化を変えることです。これがナーバスな問題になるのは、「文化」を変えることは非常に難しいためです。
まず、「文化」とは何でしょうか？幸いなことに、DevOps 派はアプリケーション デリバリというコンテキストのもとで「文化」を定義することに力を注いできました。私の同僚であるハンナ・フォクスウェル（Hannah Foxwell）は、最近、DevOps 文化のフレームワークがどのようにセキュリティに適用されるかをカタログ化しました。
ここでは詳しく説明しませんので、詳しくはハンナの記事をお読みください。代わりに私が指摘したいのは、セキュリティを継続的に進化する製品として考えるという、大きな発想の転換です。セキュリティをプロジェクト ベースの監査や事後的なインシデント対応として考えるのではなく、DevSecOps 担当者が開発者を顧客とみなし、セキュリティ プロセスを開発者が使用するために作成／提供する製品と考えるのです。これがセキュリティに対する製品管理のアプローチです。
製品管理のアプローチをセキュリティにも当てはめてみると、焦点はコンプライアンスの強制ではなく、開発者が正しい行動を最も簡単に行えるようにすることです。これこそが、DevSecOps のツールや自動化コンポーネントが極めて重要である理由なのです。製品管理の手法は広く理解され、何十年にもわたって実証されているため、DevSecOps であらためてやり方を再構築する必要はありません。一例としてVMware が「製品としてのプラットフォーム」と呼んでいる、従来の運用プロセスを製品主導のアプローチに転換するコンセプトをご覧ください。
製品管理のアプローチをセキュリティに適用すると、DevOps 文化についての話では共感や優しさ、そして単純に「もっと人と話すこと」にこだわる理由をもっと理解できるようになるはずです。良い人間であることはもちろん重要ですが、これらのツールもDevOpsのための重要なツールなのです。有能な製品管理者は、製品を使う人々が何を必要としているか、その人々が製品を使って何をしているか、そしてその活動がどのように組織の目標と結びついているかを明確に把握しています。彼らは顧客の「心の中に入り込む」ことができるのです。DevSecOps 製品管理者のゴールは、セキュアなアプリケーションの作成と提供をもっと簡単にすることです。そして、「セキュリティのことを何も知らない開発者たち」を目の敵にするのではなく、開発者たちがセキュリティの分野で活躍できるような製品を作ることです。
このような製品指向のセキュリティに対するマインドセットは、DevSecOps の話題の中でよく使われるフレーズの 1 つ「シフトレフト」について考えを深めるのに役立ちます。一見すると、「シフトレフト」とは、セキュアなコードを書くこと、コンプライアンスを確保すること、統制することについて、開発者にもっと責任を持たせることを意味するように思えるかもしれません。開発者がよりセキュアなコードを書くようにすることも DevSecOps の一部である、という点については私も同意なのですが、開発者がセキュリティ タスクの大部分を処理するとなると、アプリケーション開発者には負担が大くなり過ぎてしまいます。むしろ「シフトレフト」とは、セキュリティ活動とポリシーの実施を開発者の近くに移し、開発者を「顧客」として扱い、セキュアなアプリケーションを構築するために必要なガードレール、プラットフォーム、ツールを構築することを意味する、と考えています。次に、これらのツールやプラットフォームについて説明します。
DevSecOps による検証の自動化とガードレールの設定
DevSecOps で検証の自動化を実現
セキュアなソフトウェア サプライチェーンであらゆるデータを追跡することで、セキュリティ チームがソフトウェアをチェックし、リリースするために必要な検証およびガバナンスの大部分を自動化できます。このような検証作業は何年も前から手作業、ほとんどは E メールや Excel シートで行われてきたため、時間がかかる上にミスも起こりやすい、とにかく厄介な作業でした。日次または週次でソフトウェアのデプロイを開始したいと考えている企業にとって、手作業のセキュリティチェックは考えられません。開発とセキュリティなどの異なる部門間で打ち合わせのスケジュールを組むだけでも相当時間がかかるでしょう。
DevSecOps でパイプライン構築を自動化すれば、ガバナンス徹底の負荷軽減につながります。たとえば、部品表（BoM）の作成やコンテナ イメージへの署名が簡単にできるようになります。また、そのすべてをリポジトリに保存し、バージョン管理に追加することもできます。セキュリティ担当者は、セキュリティのベストプラクティスをテンプレート化したスターター アプリケーションの設計と構成を作成できます。
これらの作業の自動化は、Kubernetes の核となるインフラの標準化によって容易に行えます。Kubernetes の主な目標の 1 つが、コンテナのライフサイクル、ネットワーキングの設定とポリシーの強制、ランタイムのカスタマイズのための共通標準を定義することです。コンテナで実行されるステートレス コンポーネントを用いたアプリケーション開発モデルによって、Kubernetes からアプリケーションの望ましい状態を強制的に適用できます。この場合の「望ましい状態」とは本番環境におけるアプリケーションとインフラの構成を指します。保存やバージョン管理も可能です。システムの現在の状態を知るだけで、多くの本番システムが絡まり合ってしまうような状態から大きくステップアップできます。
Kubernetes が実行する設定強制によってセキュリティも向上します。構成エラーが発生した場合、Kubernetes は通常アプリケーションを強制終了してから、セキュアで信頼性の高い状態に再展開できるためです。もちろんこれですべての問題が解決するわけではありませんが、本番環境のクリーンアップが容易になり、パッチのデプロイもより迅速になります。また、定期的に本番環境のすべてをゼロから再展開（リペイブ）すれば、攻撃を受けやすい時間を短縮できます。このパターンを取り入れ、たとえばウェルズ・ファーゴは週に何度も本番環境を再構築し、1 週間を通して多数のパッチを導入しています。
DevSecOpsはガードレールを通じてセキュリティを強化
セキュリティ担当者がプラットフォームの活用によって得られる 2 つ目の機能は、開発者が正しい行動を取りやすくするためのガードレールの設置です。ここでいう「ガードレール」は、セキュアなアプリケーションの基本テンプレートを提供し、コードおよびイメージスキャン ツールをサプライチェーンに組み込んで、セキュアなコードとフレームワークを強制適用することを指します。
プラットフォームに組み込むことができるセキュリティ機能のもう1つの例が、ログ収集です。ほとんどの場合、ログの収集方法はアプリケーション チームごとに異なり、独自の形式と慣行があります。同じ方式に従うチームもあるかもしれませんが、何千人もの開発者がいる企業のセキュリティ担当者に立ちはだかるのは、多種多様なログ収集文化です。そこで統合プラットフォームがあれば、ログの作成、保存、取得の方法を標準化できます。これによりセキュリティ担当者が各アプリケーションのログ収集方式を学習して適応させたり、エラーを検索するための巧妙な正規表現を考え出したり、そもそもログの収集方法を探し出すのに時間を費やす必要はなくなります。
ゼロトラスト ネットワーキングは、開発者向けの製品としてのセキュリティ プラットフォームに組み込むべきもう 1 つの主要な機能セットです。ほとんどのアプリケーション設計は、ネットワーク上の他のコンポーネントやサービスとの通信に大きく依存しています。従来、これらの接続が概ね安全だとされていたのは、ネットワークがセキュアであると考えられていたためです。しかし開発者がネットワーク上でより多くのサードパーティのサービスを使用するようになった現在は、あまり現実的な考え方ではなくなってきています。したがって、開発者が接続に TLS を要求しているか確認する必要があります。
ここまでは、セキュリティの標準化のほんの手始めに過ぎません。プラットフォームに対する DevSecOps のアプローチにより、以下のような管理領域も標準化できます。
- イメージへの署名
- データの分類
- 秘密情報の管理
- 入出力の検証
- その他
このトピックにはさらに多くのやり方があり、自動化とガードレールの設置方法は、社内プラットフォームの構築方法によって異なります。Kubernetes ベースのプラットフォームでこれらを使用する例については、デヴィッド・ゼンジアン（David Zendzian）の動画をご覧ください。また、アディブ・サイカリ（Adib Saikali）の著書『Securing Cloud Applications』もチェックしてみてください。
DevOps から DevSecOps への移行
さて、ここからが厄介なところですが、ここまで説明したすべてを実践に移すという過程に入ります。適切なツールを導入し、セキュアなサプライチェーンを構築して自動化し、セキュリティ製品管理者を雇えばよい、と言うだけなら簡単ですが、それだけでは不十分です。それでも必要な要素は網羅しており、黒魔術的な知識は不要です。シンプルな秘訣は、実際に行動して継続することです。ただし、習慣を変えるのは難しいので、次の 4 つのステップから始めてみましょう。
目標を理解する
ここまでの説明で、「よりセキュアであること」以上の目標についてご理解いただけたかと思います。それでも、CISO や他のセキュリティ専門家の提言通りに、機能とセキュリティ ポリシーの間のトレードオフ、リスク管理戦略と計画、セキュリティに対する継続的な脅威を理解することから始めるとよいでしょう。セキュリティは、単なるバグ退治やハッカー以上のものです。DevSecOps のコンテキストでセキュリティをより深く理解し、現在構築しているソフトウェアとそれらを活用しているビジネスに対する目標に基づいて展開しなくてはなりません。
現在のDevOps プラクティスを監査する
DevSecOps を実践するための最初のステップは、すでに実行している活動を評価することです。通常、アプリケーション、セキュリティ、運用などの各チームに適切な仕事をしているか、ベストプラクティスに従っているか、その他の役立つ活動をしているか尋ねると、答えはもちろん「イエス」です。大規模な組織で働く人々は求められる成果を上げることは得意ですし、何らかの活動は行うはずです。そこで、この評価ステップにおける注目ポイントは、各チームの人々が企業に求められる新しい成果、つまり DevSecOps の目標を達成しているかを評価することです。
エンドツーエンド プロセスのマッピング
この評価ステップは、ソフトウェアを公開するまでの完全なエンドツーエンドのライフサイクルを確認することから始めなくてはなりません。既存のアプリケーションに新しい機能を追加するという仮説のケースを想定し、アイデア出しからコーディング、セキュリティ確保、デプロイ、本番稼動、そして最終的にその機能を実際に使用する人に至るまで、必要なことをすべてホワイトボードに書き出してみましょう。各活動にかかる時間と、各活動の間にかかる時間をメモしてください。各活動の間にかかる時間は待機時間であり、あるグループから別のグループに責任を引き継ぐことによって発生します。たとえば、セキュリティ コンプライアンスや監査などです。
変革の実行
プロセス全体をマッピングすることで、ほとんどの組織に存在する個別最適化を解消できます。通常、各チームは最適化されていますが、エンドツーエンドのライフサイクル全体における引き継ぎと調整は、（技術者たちが使う言葉で言うとすると）「イケてない」ことが多いのです。エンドツーエンドの流れを把握して「リリース サイクルを高速化し、より多くのセキュリティ管理とポリシーを導入するには、各段階のセキュリティ ツールとプロセスをどのように改善すればよいか」という問いから始めましょう。
もちろん、ツールや自動化の部分に関しては VMware がお手伝いします。まず、DevSecOps を実践するためのラーニング パスをチェックしてください。次に、正しい行動を最も簡単に行うためのVMware Tanzu Application Platform をご覧ください。Tanzu supply chain choreographer（Cartographer ベース）を使用してセキュアなソフトウェア サプライチェーンを作成し、Tanzu Application Platform の開発者ポータル（Backstage ベース）を使用してアプリケーション開発者とセキュリティ スタッフ間のコラボレーション強化に着手できます。ガードレールも含めてすぐに使える優れたセキュアなソフトウェア サプライチェーンが用意されています。それらをカスタマイズして自社に最適な形にすることは可能ですし、もちろんそうすべきです。こちらのライアン・ベイカー（Ryan Baker）のデモで、多くの例をご紹介しています。
その他の DevSecOps リソース
私は DevSecOps の複雑さを網羅した概要やリストを作りたかったわけではなく、シンプルで基本的な理解を示したかっただけです。もちろん掘り下げれば、もっと多くのことを知ることができます。DevSecOps の実践段階にある企業には、以下をお勧めします。
- 「Creating a Culture of DevSecOps」：Hannah Foxwellは、DevSecOpsに沿った文化の変革について詳しく説明します。
- 「DevSecOps: Integrating Security with Software Development」：DevSecOps を開発者のインナーループと Kubernetes に組み込むこと
- 「Secure Your Software Supply Chain with New VMware Tanzu Application Platform Capabilities」：ティファニー・ジョーダン（Tiffany Jordan）とタジン・プロッガ（Tazin Progga）が、セキュアなソフトウェア サプライチェーンの概念について深く考察しています。
- DevSecOps for Dummies：組織に DevSecOps のプラクティスを導入するためのわかりやすいガイドです。
皆様のご検討をお祈りします。
執筆者について
Michael Coté は VMware Tanzu のアドボケート チームに所属しています。詳しくは @cote をご覧ください。
