DevSecOpsとは？ CDでのその役割

DevSecOpsは、ソフトウェア開発ライフサイクル（SDLC）にセキュリティを統合することを重視しています。セキュリティをチームのカルチャ、プロセス、およびツールに組み込むことでサイロ化することを防止し、迅速なデリバリーによってセキュリティの脆弱性が疎かにならないようにすることができます。

DevOpsの理解

セキュリティ側の話に踏み込む前に、DevOpsについて少し説明しましょう。

アジャイルソフトウェア開発と緊密なつながりのあるDevOpsは、すべての人が価値の高い、正常に動作するソフトウェアをユーザーに効率的に提供するという共通の目標を持った、ソフトウェア開発とオペレーションの間にコラボレーションのカルチャを作り出すことを目的としています。これを実現するために、DevOpsは、デリバリー時間を短縮し、迅速なフィードバックを提供することで、継続的な改善のサイクルを作り出す、堅牢な自動プロセスを促進しています。

これまでのところは順調に進んでいるにしても、電車に乗り込もうと走っているときと同じように、ソフトウェアのデリバリープロセスを高速化しようとしている際は、何か重要なものを取り残していないか確認することが推奨されます。残念ながら、これまで取り残されてきたものはセキュリティであることがほとんどだったため、これを解消するのがDevSecOpsの狙いとなっています。

DevOpsセキュリティ

ソフトウェアに含まれるセキュリティの脆弱性が持つ潜在的な影響は大袈裟には語れません。

経済的な損害や評判の悪化だけではありません。ソフトウェアのセキュリティ侵害により、社内文書からリリース前の製品、そしてパスワードを含む顧客の個人情報まで、大量の機密データが漏洩してきました。管轄によっては、ユーザーデータが漏洩してしまえば、多額の罰金だけでなく、法的責任も課されてしまいます。

このようなことにも関わらず、開発チームはセキュリティをアセットではなく、邪魔者扱いすることがほとんどでした。セキュリティ監査やレポートによって進行が遅れ、最新の斬新な機能をユーザーの手元に送れなくなるからです。しかし、その考え方は攻撃者には好都合であり、SDLCにおけるセキュリティの重要性を無視すれば、次のワナクライやハートブリードを生み出すリスクが高まります。

こういった悪用はニュースの大見出しを飾ってきましたが、その根源はいたってありきたりなものです。脆弱性は、人がコードを作成し、人がミスを犯すため存在します。こういったミスには、以前にほかの人が犯したものであるため、見つける場所がわかっていれば簡単に特定することができるものもあれば、以前にはなかった要素の組み合わせの結果、起こるミスもあります。

ただでさえ複雑であるにも関わらず、ほぼすべてのソフトウェアには、オープンソースか独自のものであるかにかかわらず、以前関係が統合されており、サードパーティのコードに脆弱性が含まれないことを保証することはできません。

では、SDLCにどのようにセキュリティを組み込めばよいのでしょうか。 DevSecOpsは、コラボレーション、共同責任、および自動化できるあらゆるものを自動化するという、リリースの高速化と安定化と同じ原理をセキュリティ実践にも適用する手法です。

セキュリティをプロセスの左側に移動する

ウォーターフォール式開発プロセスは、要件の収集から始まり、デザイン、ビルド、インテグレーション、テストフェーズを経て、通常、開始から数か月から数年後にようやくリリースするという直線的な開発アプローチです。

テストフェーズには通常、長期にわたる品質保証、セキュリティ監査、および承認テストという手動プロセスが伴います。「丸投げする」という冷笑的に表現されるプロセスでは、製品はある機能組織から次の機能組織にハンドオフされ、それぞれが長々としたレポートを作成しなくてはなりません。

これらのステージの1つは情報セキュリティまたはinfosecに割り当てられており、セキュリティレポートを作成し、結果や推奨事項に関する詳細なリストを提供します。このリストではコードベースへの変更を要求されることが多く、変更が終われば、ソフトウェアをもう一度そのステージに戻し、すべてが期待通りに実装されていること（またはされていないこと）を確認しなければなりません。このように長々としたプロセスであれば、リリースのたびに盛大にお祝いすることがあっても不思議ではありません。

アジャイルソフトウェア開発、DevOpsムーブメント、そしてクラウドコンピューティングの出現により、このアプローチが大きく変化しました。競争は厳しく、スピードが要となっています。ユーザーのニーズを解決せず、ずぐにバグを修正しなければ、ユーザーは他のプロバイダーへと気移りしてしまうでしょう。多くの組織では、CI/CDパイプラインをオペレーションの礎として、定期的に価値を提供し、迅速に修正をロールアウトできることが当たり前となってきています。

DevSecOpsという言葉からもわかるように、DevOpsにはセキュリティを除外する意図はまったくありませんでした。

残念なことに、現実は、開発チームとオペレーションチームで境界線が引かれ、情報セキュリティチームはサイロ化されたままであることが一般的でした。これを解消するために、DevSecOpsや、SecDevOps、DevOpsSec、Rugged DevOpsなどの他の言い方が用いられるようになったのです。

DevSecOpsでは、始めからセキュリティを組み込むことの重要性を強調しています。セキュリティに対する理解と責任を共有するカルチャを強化し、CI/CDパイプラインの自動テストの領域にセキュリティチェックを組み込むのです。オペレーションと同様に、製品が完成した後でセキュリティを据え付けるよりも、セキュリティを左側に移動して、セキュリティ要件とベストプラクティスを統合する方が簡単だという考えです。

DevSecOpsにSecを配備する: コードとしてのセキュリティ

まだ取り組んだことがなければ、セキュリティを左側に移動するというのは、CI/CDパイプラインのステージとして、セキュリティチームがソフトウェアをテストできるようにするだけだと考えがちです。

後の方で説明するように、手動によるセキュリティテストが発生する場面はあるにせよ、セキュリティ要件への取り組みをパイプラインの最後に制限するのであれば、ソフトウェアを丸投げしてレポートが返ってくるのを待つのと、ほとんど変わりません。

これでは、推奨事項を実装するには時間が掛かりすぎるため、それらが無視されてしまうか、課題の解消とリスクの評価が行われる間、プロセス全体が凍り付いて、無期限でリリースが遅延してしまうことになる可能性が十分にあります。いずれにせよ、この仕組みでは、「セキュリティ側」と「ほかのチーム側」という分け隔てのある考え方が生まれてしまい、どちら側でも、使い勝手の良い安全なソフトウェアを生み出しにくくなってしまいます。

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

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

共同責任のカルチャは重要ですが、開発チームにソフトウェアセキュリティの全責任があることを伝えるだけでは不十分です。最新の攻撃ベクトルとマルウェアの発展状況を理解するのは本業の傍らで行えることではなく、すべての人が同じレベルの専門知識を備えられると期待してはいけません。他の人を指導してベストプラクティスを共有できるセキュリティ担当者を多分野にわたる知識を備えたチームに加えることで、理解を深めて、セキュリティ専門家とのコラボレーションのカルチャを促進することができます。

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

開発者が、製作しているソフトウェアのセキュリティに対する責任を共有できるようにするには、コードを作成する前にセキュリティを検討するようにする必要があります。ユーザーストーリーに組み込み、バックログのレビュー会議で検討し、スプリントを計画する際に議論する必要があります。新機能への取り組み方を決める際には、新機能から生じる可能性のあるリスクやそれらを緩和する術について検討する時間を持つようにしましょう。

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

自動セキュリティテストをパイプラインに組み込む

自動化は、DevOpsの中心的な考え方です。タスクの進行を加速化し、一貫して実行されていることを確保するだけでなく、もっと創作的な仕事に人材を利用できるようになります。定期的かつ頻繁に、ユーザーにソフトウェアを提供したいのであれば、自動セキュリティテストをパイプラインに組み込むのは絶対といえます。

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

専門知識を備えた補助ツールを使用する

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

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

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

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

依存関係をチェックする

ソフトウェア構成またはコンポーネント分析（SCA）は自動セキュリティテストの一種で、プロセスの早期に実行できます。前述のとおり、実質的にすべてのコードベースには、オープンソースライブラリやその他のコンポーネントが統合されているため、脆弱性が紛れてしまうことがあります。

SCAツールは、開発者が導入した依存関係だけでなく、サプライチェーン全体に存在する依存関係をクロールします。特に、プロジェクトに新しい依存関係が頻繁に追加されることを考えれば、コンピューターに任せるのが最適な作業です。

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

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

レッドチームの概念は戦争ゲームに始まったもので、攻撃シミュレーションにおいて、味方のメンバーに敵を演じるように指示し、自分の防御と戦略に潜む弱点を特定することを目的としています。ソフトウェア開発でも、これと同じアプローチを使うと高い効果を得られます。侵入テストまたは倫理的ハッキングを装って行われることもあります。

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

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

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

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

バグを修正する責任は、セキュリティ担当者だけではなく、チーム全体にあります。このアプローチを取れば、チーム内に知識や専門知識を蓄積し、そのスキルを次のプロジェクトで活かせられるようになります。

本番を監視する

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

まとめ

セキュリティを左に移動するということは、SDLCのすべてのステージでセキュリティをチーム全体の考慮事項することを指します。 DevOpsの実践を適用すると、そのライフサイクルは頻繁に繰り返され、ソフトウェアがどのように動作しているのか、また実世界でどのように使用されているのかに関するフィードバックを定期的に得られるようになります。 CI/CDパイプラインにセキュリティを組み込むと、アプリケーションのセキュリティに関するフィードバックも定期的に得られるようになるため、ほかの機能と同様に、セキュリティの改善も行えるようになります。

既知の脆弱性をチェックし、それに対する保護を適用すれば、既知の攻撃に対して無防備のままであるのではなく、少なくとも、攻撃者に対処できるソフトウェアを得ることができます。新しい脆弱性はすべてバグとして扱い、優先して修正とテストを行うことで、将来的にソフトウェアをより堅牢なものに仕上げることができるようになります。

結局のところ、DevOps、つまりDevSecOpsは、迅速で頻繁に行われるソフトウェアのデリバリーを実現するツールやプロセスと同じカルチャなのです。これを可能にするのは、最終的には人です。セキュリティをSDLCに組み込むのであれば、非難の対象を絞るのではなく、共同責任のカルチャを作ることが鍵となります。スプリントの計画中、コードレビュー時、手動テストの実行時、ライブシステムで公開中であろうと、いつでもセキュリティに関する懸念を誰もが提示し、それに耳を傾けることが必要です。また、セキュリティとそれを実装することの重要性を認識する役割は、すべての人に与えられているのです。