Mercari Advent Calendar 2020 の15日目は、メルカリ Product Security チームの Gloria Chow がお送りします。

こんにちは、Product Securityチームの@gloriaです。以前、オープンソースとして公開しているTestdeckという、マイクロサービスの自動化テストのための社内ツールについて記事を書きました。

今回は、2020年のAdvent Calendarの記事として、DevSecOpsについてお話をしたいと思います。近年、耳にする機会の多い話題の一つなので既にご存じの方もいらっしゃるかもしれませんが、DevSecOpsの基本的なコンセプト、注目されている理由、よくあるチャレンジとメルカリにおけるDevSecOpsの実践事例を紹介したいと思います。

DevSecOpsとは?

まず、以前から提唱されているDevOpsについて振り返りたいと思います。DevOpsはDevelopment（開発とテスト）とOperations（デプロイメントとモニタリング）を組み合わせた組織文化で、4つのコンセプトで構成されています。Continuous Integration（継続的インテグレーション）、 Continuous Testing（継続的テスト）、Continuous Delivery（継続的デリバリ）、とContinuous Monitoring（継続的モニタリング）です。

従来、開発者は与えられた要件に沿って機能を開発することに責任を持ち、テストはQA、残りはOperations（運用部隊）に任せるといったフローをとっていました。しかしながら、DevOps組織では、開発者は開発だけではなく、テスト、デプロイメントとモニタリングにも責任を持ちます。

DevOps組織ならではの特徴が「Shift-Left Testing（シフトレフト・テスト）」です。開発者は、単体テストなどの自動テストを通じて、自分たちの書いたコードのテストに対して責任を持つようになります。その結果、DevOps以前のように開発とテスト（QA）フェーズが分かれることなく、ソフトウェア開発サイクル（SDLC）の開発フェーズの中に、多くのテストが組み込まれることになります。そうすると、バグをより早い段階で見つけたり直したりすることができ、リリースの直前にテストを始めるより効率的だと言われています。

さて、DevSecOpsの話に戻ります。DevSecOpsでは、名前の通りDevOpsにセキュリティが融合され、5つ目のコンセプトであるContinuous Security（継続的セキュリティ）が追加されます。つまり、以前のようにセキュリティエンジニアが全開発を終えてからセキュリティテストなどを行うというプロセスを取らず、開発プロセスの全ての段階で行われるわけです。セキュリティはSDLCの全ての段階と、アプリケーションからインフラストラクチャ（コンテナ、サーバー、ネットワーク）まで、全てに関わります。

DevOpsと同じように、DevSecOpsチームの開発者は、自分の書いたコードのセキュリティ品質に責任を持ち、セキュアコーディングやセキュリティテストなどの一般的なセキュリティ活動も積極的にこなします。DevOpsのプロセスにセキュリティツールを統合することは「Security as Code (SaC)」と呼ばれていて、開発プロセスに悪影響を及ばさずに自動的なセキュリティチェック、セキュリティテスト、およびセキュリティスキャンを追加する目的で行われます。自動化によって、SDLCの中に常に存在する機能として、継続的かつ容易にセキュリティの強化を実施することができます。

なぜDevSecOpsは注目されているのか？

以下では近年DevSecOpsを志向する組織が増えている3つの理由を説明します。

より短いリリースサイクルとリリースの高速化

DevOpsチームのテストは開発フェーズに実施されるので、バグも早い段階で見つかります。テストはリリースの直前に一気に行われるのではなく、SDLCの各フェーズで行われます。セキュリティも同じように、従来はペネトレーションテストなどのセキュリティ活動は最後のフェーズで行われていましたが、DevSecOpsでは各フェーズで行われるようになりました。

DevSecOpsにより、QAとセキュリティのボトルネックを排除できる2つの理由があります：

1. リリース直前に大きいバグや脆弱性が見つかり、早急に直さないといけない事態に陥る可能性を減らすことができます。伝統的なウォーターフォールとアジャイルによる開発スタイルでは、QAとセキュリティがリリースの直前に大きなバグや脆弱性を見つけるため、リリースのブロッカーに見られがちですが、DevSecOpsでは早い段階で問題を見つけて修正することができます。

2. 開発者はQAとセキュリティの作業が終わるまで待たなくても良くなります。コードを最も理解している人は開発者のはずなので、コードを書きながらテストも書く（もしくは、テスト駆動開発（TDD）で最初にテストを書く）というのは、完成した後にQAにテストを依頼するより効率的だと言われています。セキュリティも同じく、脆弱なソフトウェアをあとからセキュアにするより、最初からセキュリティを重視して作る方が効率的です。

DevSecOpsチームのもう一つの特徴は、自動化を積極的に活用していることです。コードがコミットされるたびに、QAとセキュリティテストを実行し、ソフトウェアの品質とセキュリティを確保しています。こうすることで、DevSecOpsチームは自動化を使用しないウォーターフォールやアジャイルの開発スタイルで開発する組織より速やかにリリースすることができます。

ソフトウェアの品質とセキュリティの向上

DevSecOpsはソフトウェア品質とセキュリティを優先し、テストとセキュリティの活動を早い段階で開始し、ソフトウェアのデザインとアーキテクチャに影響を与えられるようにしています。そうすることで、ロジックやアーキテクチャの根本的な問題をより早く見つけて修正し、本番環境で発生するインシデントを減少できます。

「Security as Code (SaC)」と「Infrastructure as Code (IaC)」などのDevSecOpsの考え方は、本番環境に悪影響を与えるヒューマンエラーのリスクも削減できます。SaCとIaCでは、セキュリティの活動、デプロイメントなどの重要なオペレーションは全て自動で行われるので、毎回のリリースプロセスにおいて一貫性を確保できます。

より良いチームコラボレーションと人材の育成

DevSecOpsは組織の共同的な文化と開発プロセスに関わる4つのグループ（開発、QA、セキュリティ、Operations）間で知識を共有する意識を向上させます。人材はスキルアップができ、将来にキャリアアップなども可能になるので、とても働きがいがある環境だと思います。以前書いた記事の通り、現代のエンジニアは「T型」のスキル（幅広い知識に一つか一つ以上の専門知識）が必要です。DevSecOps環境で働くエンジニアはテスト、デプロイメント、モニタリング、セキュリティなど、様々なスキルを身に付けられるので、自然にT型人材に成長するでしょう。

開発者ではない方は開発者と連携することで、懸念点や提案を開発プロセスの早い段階で聞いてもらうことができます。従来の開発手法では、、各チームは自分たちの作業だけに注力していたためコラボレーションがとても少なく、同じプロダクトを作っているのにサイロ化が発生してしまうことがありましたが、DevSecOps文化ではこれを防げると思っています。

メルカリと「シフトレフト・セキュリティ」

継続的テストには「シフトレフト・テスト」という考え方があり、継続的セキュリティにも「シフトレフト・セキュリティ」という考え方があります。DevSecOpsの組織では、セキュリティの活動がSDLCの初期フェーズに移行され、各段階でも行われます。

メルカリでも「シフトレフト・セキュリティ」を導入しています。以下は誰でも導入できる、おすすめの「シフトレフト・セキュリティ」活動の例です。

要件定義と設計フェーズ

• デザインと要件のセキュリティレビュー：メルカリのProduct Securityチームは新しい機能の要件定義と設計に関わっており、問題の発生しうる所を特定するためにユーザーフロー、ユースケース、ビジネス要件などのセキュリティレビューを行います。そうすると、機能の開発が始まる前に、デザイン段階でセキュリティ問題を洗い出し、セキュリティ品質を確保することができます。

• 脅威モデリング： 発生し得る脅威や脆弱性を洗い出し、リスク評価を行い、リスクを減少させるための対策を提案します。攻撃者が行うであろう全てのケースを洗い出すことで、先手を打って、攻撃者が悪用する前に対策を行うことができるようになります。

• アーキテクチャレビュー：メルカリのSecurity Engineeringチームはシステムインフラストラクチャやデータフローなどのレビューを行い、サイバー攻撃のリスクとインパクトを最小にするために対策を提案しています。

実装フェーズ

• セキュリティコードレビュー：機微情報の取り扱いの安全性を確保するために、機微情報に関わるコード（個人情報を預かったり、ペイメントなどに関連したりする箇所）のセキュリティレビューを行い、セキュリティ対策が不十分な部分や悪用されそうなロジックを洗い出しています。機微情報に関わらないコードに関しても、セキュアコーディングのベストプラクティス（クレデンシャルのハードコードの禁止、堅牢な暗号化アルゴリズムの使用など）に従っているかどうかの確認を行っています。

テストとインテグレーションフェーズ

• セキュリティテスト：機能のテストが可能になった時点で（QAのテストと同時進行）、脆弱性と悪用可能な部分を洗い出すために、Product Securityチームはセキュリティテストを行っています。

• 静的アプリケーションセキュリティテスト（SAST）：XSSやSQLiにつながる、脆弱なライブラリの使用やコーディングのミスなどのよくある問題を洗い出すツールです。メルカリはWhiteSourceやMobSFなどのSASTツールを導入し、CI・CDパイプラインで実行することで、コミットごとにセキュリティ品質を確保しています。

• 動的アプリケーションセキュリティテスト（DAST）：実際にソフトウェアを実行して、脆弱性があるかどうか解析するツールです。メルカリもNetsparkerなどのDASTツールを導入しています。

メンテナンスフェーズ

• 自動化ツールとモニタリング：セキュリティの活動はリリースで終わるというわけではありません。リリースが終わっても頻繁に脆弱性スキャナやセキュリティリグレッションテストなどを実施したり、モニタリング、アラート、監査を行うツールを導入することはサイバー攻撃が相次いている現代では必要不可欠です。メルカリは、Signal SciencesやWeb Application Firewall(WAF)やSysdigなどのセキュリティツールを利用し、社内で開発したSOAR (Security Orchestration, Automation and Response)などの監視システムを通して、継続的なモニタリングを実施しています。

チャレンジ

DevSecOpsのメリットは確かに多いですが、正しく導入するのは簡単ではありません。他の開発手法と同様に、チームは変化する役割や責任、および働き方やカルチャーに適応するのに時間がかかるため、移行期間中は開発スピードが下がる可能性があります。DevSecOpsに移行しようとする組織は、メリット享受するまでに生産性が下がる可能性があることを事前に理解し、受け入れる必要があります。

もう一つのチャレンジは、DevSecOpsのチームは互いに連携する必要がある点です。開発者、QA、セキュリティ、Operations（SREなど）の4つのチームの作業がSDLC全ての段階に存在しているため、親密な関係を築いて協力しなければなりません。従来のウォーターフォールとアジャイルの組織では、各チームが指定された自分たちのSDLC段階の中で作業をしてきましたが、DevSecOpsでは異なります。ちなみに、DevSecOpsについてよく耳にする誤解は、テスト、デプロイメント、モニタリングとセキュリティの責任を開発者に移譲したら、QA・セキュリティ・Operationsのエンジニアが必要なくなるという考えです。DevSecOpsの目的はこの3つの職を排除することではなく、むしろ彼らに開発者をサポートする役割を与えることです。つまり、開発者と友好的に協力して働くということです。

最後に、最も明確な課題は、DevSecOpsチームのエンジニアは様々な技術スキルと知識に精通している必要がある点です。開発者はコーディングを初め、テスト、デプロイメント、モニタリング、セキュリティなどの責任も持つため、自動化テストやセキュリティのマインドセットなど、様々なスキルと知識を身に付けなければなりません。DevSecOpsに移行しようとする組織は開発者向けのトレーニング、そしてQA・セキュリティ・Operationsチームからの継続的支援と知識を共有してもらう機会を確保する必要があります。メルカリのケースを紹介すると、セキュリティ知識を広げるために、「セキュリティチャンピオン」という社内育成プログラムを作りました。

さいごに

DevSecOpsは最近非常に注目されている話題の一つです。正しく導入する上で様々なチャレンジがあるかもしれませんが、リリースの高速化、バグと脆弱性の減少、そして社内クロスチームのコラボレーションと知識共有の促進などのメリットもあります。特に近年、サイバー攻撃の相次いている中で、セキュリティは補足的なものではなく、最初から開発プロセスと並行に行われる、不可欠な機能の1つになりました。「シフトレフト・セキュリティ」などのDevSecOps思想を導入することで、ソフトウェアに高いセキュリティ品質を埋め込むことができます。

本記事はDevSecOpsの基本的なコンセプト、注目されている理由、よくあるチャレンジとメルカリのDevSecOpsの実践事例を紹介しました。お読みいただきありがとうございました。明日も引き続きメルカリ Advent Calendarの記事が投稿されるので、ご期待ください。

メルカリではミッション・バリューに共感できるエンジニアを募集しています。一緒に働ける仲間をお待ちしております。
https://careers.mercari.com/jp/job-categories/engineering/

明日のMercari Advent Calendar 2020執筆担当は、 Engineering Officeの afroscript さんです。引き続きお楽しみください。