セキュリティテストを開発時に行いCI/CD連携を加速するDevSecOps
吉井氏は、「DevOpsとセキュリティの間には、越えられないギャップが存在している」と指摘する。アプリケーション開発のテストは、大きく開発段階の「静的解析」とデプロイ以降の「動的解析」の2つのフェーズに分けられる。静的解析では主にコードを見る「SAST（静的アプリケーションセキュリティテスト）」や「SCA（ソフトウェア・コンポジション解析）」が行われ、動的解析では「DAST（動的アプリケーションセキュリティテスト）」や「Pen-test（侵入テスト）」などが実施される。
テストの中でも特に重要な「脆弱性の発見」などは、実際にアプリケーションを実行してみないと難しいため、DASTの段階で行われる。しかし運用開始後に出てきたセキュリティ課題は、開発者が単独で修正を判断できるものでもなく、また現場で見つかった課題をそのまま開発者にフィードバックしてしまうのも難しい。
「アプリケーションのライフサイクルが前後に分断されてしまうので、CI/CD（継続的インテグレーション/継続的デリバリー）連携が行えず、せっかくのDevOpsのサイクルが円滑に回りません。特にセキュリティの課題は、スペシャリストが見てトリアージするので、仮にテスト結果をすぐに開発側に戻せたとしても、専門知識を持たない開発者は独断では動けません」（吉井氏）
そこで最近急速に浮上してきたのが、「DevSecOps」の考え方だ。これまでは「アプリケーションの完成後にセキュリティテストを実施」という流れが、CI/CDのライフサイクルを妨げてきた。それならば、セキュリティテストを開発プロセスのより早い段階にシフトし、問題をすべて解決してからデプロイ～運用に入ればよい、といった発想の転換である。
インタラクティブテストツール「Seeker」がDevSecOps実現の障壁をクリア
DevSecOpsの発想そのものは画期的だが、実現には多くのハードルがあるのも事実だ。もっとも大きな阻害要因として、吉井氏は以下の3つの課題を挙げる。
（1）テスト結果に誤検知が多くトリアージに時間を要する
DevOpsではセキュリティの専門家がテスト結果を見て、問題点を開発者にフィードバックするケースがほとんどだ。しかし既存のツールは誤検知が非常に多く、正しい結果を確定するまでに時間がかかってしまう。
（2）セキュリティテスト用の環境を用意するのが困難
開発者がセキュリティテストを行うためには、別に専用の環境を用意しなくてはならず、開発プロセスの変更やコストの増加が避けられない。
（3）セキュリティテストの結果を見ても問題点がわからない
セキュリティ課題は専門家でないと詳細がわからず、開発者自身がDASTの結果を見ても、なかなか問題を発見できない。
では、これらの課題をどう解決すればよいのか。吉井氏は、（1）正確性：誤検知が極めて少ないこと、（2）連携：別環境を設けずに、通常の機能テストのバックグラウンドで同時にセキュリティテストを実行できること、（3）対応可能：開発者が指摘された課題を自分で理解・対応できることの3つが重要なポイントだと指摘。それを可能にするのが、日本シノプシスの提供するIAST（インタラクティブアプリケーションセキュリティテスト）ツールである「Seeker」だと紹介する。
「IASTとは従来のSASTとDASTのギャップを埋める考え方で、Seekerは両者の間をつなぎ、CI/CD連携を可能にします。このツールを利用することで、開発フローの変更や工数を増やすことなく、誰でも容易にDevSecOpsを実現できる点が、開発者にとって最大のメリットです」（吉井氏）
セキュリティテストを自動化し高精度な問題発見と迅速対応が可能に
そんなSeekerは「セキュリティテストの自動化」を実現するため、以下の3つの特徴を備えている。
（1）開発者のストレスにならない正確さ、誤検知率5％を実現
開発者にとって一番の悩みの種は、せっかくセキュリティテストのツールを導入しても、誤検知が多くて品質の改善につながらないことだった。これまでも「SASTとDASTのギャップを埋め、CI/CD連携を実現」をうたうツールは存在したが、誤検知が非常に多く、発見された課題の半分以上が誤検知というレベルだったからだ。その点、Seekerは誤検知率がわずか5％と、極めて高い精度を誇っている。
IASTの特徴として、アプリケーションの中にエージェントが入れられていて、いわばデバッガの役割を果たしている。アプリケーションにhttpリクエストが投げられて、処理結果を返す際に問題点を検知するのだが、既存のツールはこの精度が低く誤検知が多発。「本当か間違いかわからない」ことが、修正を行う開発者のストレスになっていた。
「これを解決したのが、当社独自の技術です。Seekerのエージェントは一度検知した結果があやしいと判断すると、内部で処理を再度実行して、それが真の脆弱性であるかを確認します。この技術の搭載によって、誤検知率わずか5％という飛躍的な精度の向上を実現できました」（吉井氏）
（2）特別な環境の準備は不要、開発者は機能テストを実行するだけ
Seekerでは、開発環境と別にテスト用環境を用意する必要はまったくない。通常のアプリケーションのテスト環境にSeekerをデプロイし、Seekerのエージェントをアプリケーションに組み込むことによって、機能テストのバックグラウンドでセキュリティテストを実行する仕組みだ。機能テストの結果はJiraに出力され、脆弱性があれば開発者に通知される。
（3）開発者が対応可能な情報を提供、脆弱性のある行数まで特定できる
もし脆弱性が発見された場合、開発者が脆弱性を特定するための詳細なレポートをSeekerが提供する。ここには「ファイル名」「メソッド」「行番号」といった具体的なレベルでコードの中の脆弱性が存在する箇所が示されているので、開発者はレポートを受け取ってすぐに修正対応に取りかかれる。
Seekerが最適の修正方法を提案e-ラーニング情報なども網羅
セッションの後半では、吉井氏がSeekerの機能をデモで詳細に紹介。脆弱性学習用のアプリケーションとして知られる「WebGoat」にSeekerエージェントを組み込み、ログイン処理をするだけで、瞬時に複数の脆弱性が指摘された。この他にもSQLインジェクションの検知など、典型的かつ重要な脆弱性を特定するデモがいくつも披露されると、参加者は一様に見入っていた。
「やはり開発者にとって一番大きなメリットは、問題点がコードの具体的な『場所』として示される点です。セキュリティの専門家の指示を待たずに、すぐに対応できるので開発やテストのフローを止める必要がありません」（吉井氏）
また自分で判断しかねる場合も、Seekerの「Remediation（修復）」機能が最適の修正方法を提示してくれるうえ、関連する技術が学べるeラーニングの情報まで提供してくれるという。
クロスサイトスクリプティングやSQLインジェクションなどは、開発者がコーディングの際に注意すべき脆弱性として、すぐに見つけて修正しておきたい。Seekerなら、従来のようにセキュリティ専門家にしかわからない難解な解析の形ではなく、開発者が簡単に理解し修正できる形で、的確にフィードバックしてくれる。DevOpsのプロセスにセキュリティを組み込み、DevSecOpsを実現するのにうってつけのツールだろう。
最後に吉井氏は、「アジャイルやスクラムなど、短い周期で開発を行って、機能テストの際にセキュリティも固めておきたい場合などに、ぜひ活用してセキュアなアプリケーションをリリースしていただければと思います」と語り、セッションを終えた。
お問い合わせ
日本シノプシス合同会社
