「SAST」「DAST」「SCA」がDevSecOpsに向かない“なるほどの理由”：これで分かる「DevSecOps」の課題と解決【第1回】

セキュリティを取り入れたアプリケーション開発手法「DevSecOps」ではさまざまなツールを利用できるが、それぞれに“ある問題”がある。それは何なのか。DevSecOpsの要件と共に解説する。

[田中一成，著]

　「DevOps」「アジャイル」といった迅速な開発を可能にする手法の台頭により、Webアプリケーション開発のスピードと効率が飛躍的に向上しています。企業は週に数回、多い所では1日に数回のペースでWebアプリケーションをリリースする運用体制が取れるようになりました。一方Webアプリケーションのセキュリティ対策では、企業はソースコードのスキャンや脆弱（ぜいじゃく）性診断に時間を取られ、Webアプリケーション開発のスピードとセキュリティ対策の間でバランスを取るのに苦慮しています。

DevSecOpsとは

　そうした中、「開発」「運用」「セキュリティ」を密接に連携させたアプリケーション開発手法「DevSecOps」が広がっています。DevSecOpsはアプリケーション開発と運用の各工程にセキュリティを組み込むことが特徴です。企業はDevSecOpsによりアプリケーション開発のスピードを損なわずに、アプリケーションに脆弱性が組み込まれるリスクを低減し、セキュリティを保つことが可能になります。

　代表的な脆弱性検出ツール（図）には、

• SAST（静的アプリケーションセキュリティテスト）
• DAST（動的アプリケーションセキュリティテスト）
• SCA（ソフトウェアコンポジション解析）

などがあります。これらの脆弱性検出ツールはアプリケーション開発の現場で広く使われており、セキュリティ向上の有力な手段であることは確かです。ただしDevSecOpsの実現にこれらの脆弱性検出ツールを生かそうとする場合には、注意が必要です。

「SAST、DAST、SCAはDevSecOpsに向かない」の真相

併せて読みたいお薦め記事

DevSecOpsについて知る

• DevSecOpsを確立する方法
• 「DevOps」「NetOps」「SecOps」「DevSecOps」「NetSecOps」の違いとは？

　これらの脆弱性検出ツールはそもそも、DevSecOpsでの利用を前提に設計されていません。「必ずしもアプリケーションの開発スピードとセキュリティのバランスを考慮しているわけではない」と言い換えることもできます。例えばSASTはソースコードしか確認しないため検出精度を高めにくく、脆弱性を検出できない「検知漏れ」や、実際は脆弱性ではないものを脆弱性として検出する「過検知」（False Positive）の発生を抑制しにくい問題があります。従来のSAST、DAST、SCAは開発終了後の診断での利用が前提なので、企業はこれらのツールで脆弱性を検出した後に修正、テスト、デプロイを繰り返さなければならず、結果的に開発スピードの遅延につながります。

　開発スピードを遅らせてでもセキュリティを強化しようとすれば、企業は修復を次回の開発以降へ回したり、リリースを遅延させたりしなければならなくなります。つまり脆弱性検出ツールがセキュリティ向上の面でも、開発期間短縮の面でもボトルネックになってしまうのです。

図　脆弱性検査ツールの歴史。手動検査、ツール活用、自動化という流れを踏んでいる（出典：Contrast Security Japanの資料）《クリックで拡大》

　セキュリティ部門と開発・運用部門が完全に分離されている企業は、Webアプリケーションの開発が終わってから脆弱性検出といったセキュリティ確認や対策を実施することになり、余分な人件費が発生する可能性があります。こうした事態を避ける手段がDevSecOpsです。

　DevSecOpsを実現するためには、開発部門、運用部門、セキュリティ部門が一丸になって、部門の垣根を越えた組織を形成することが欠かせません。そうした組織ができれば、企業はWebアプリケーション開発の初期段階から脆弱性を検出して修復し、本番環境で攻撃を確実に検出、ブロックできるようになります。

SAST、DAST、SCA、WAFの課題

　脆弱性検出ツールをはじめ、さまざまなセキュリティツールがDevSecOpsの実現手段として利用されています。こうしたセキュリティツールの代表例と、それぞれの課題を見てみましょう。

SASTの課題

　SASTはコンパイル前のソースコードを解析して脆弱性や品質不良を検出するセキュリティツールです。ソースコード内の関数、メソッド（データに対する操作）やクラス（データとメソッドの集合）のパターンマッチングや構文解析により脆弱性を検出します。開発中のアプリケーションの全てのソースコードをスキャンするため、脆弱性を検出しやすいと言えます。

　アプリケーションを稼働させずにテストを実行するので、SASTはクエリ実行時やその前後におけるランタイム（実行時）などの情報を把握するのが困難です。そのため過検知が起きやすい問題があります。

　ある国内企業では、SASTが脅威として検出した脆弱性のうち90％が過検知によるもので、正しい脆弱性を見つけ出すのに開発チームとセキュリティチームのリソースが逼迫（ひっぱく）することになりました。このように、精度の低い脆弱性検出ツールを利用しても、効果的なDevSecOpsは実現できません。

DASTの課題

　DASTは実際の攻撃を基にしたHTTPリクエスト（試験パターン）をWebアプリケーションに送信することで、脆弱性を確認します。DASTの問題は、一般的に試験パターンが数百件から数千件という限られた数であり、これらの試験パターンでカバーできない脆弱性は検出が難しいことです。試験の際に実際に攻撃をするので、結果としてDASTがWebアプリケーションをクラッシュ（システム停止）させる可能性があることも弱点として挙げられます。DevSecOpsの一貫としてDASTを利用する場合、クラッシュによってアプリケーション開発のライフサイクルに影響を及ぼしかねません。

SCAの課題

　ソフトウェアライセンス管理およびOSS管理ツールであるSCAには“前身”があります。ソフトウェアライセンス管理ツールがそれに当たります。ソフトウェアライセンス管理ツールは、アプリケーション開発においてオープンソースソフトウェア（OSS）採用をする際、プロプライエタリ（商用）ソフトウェア、コピーレフトソフトウェア（誰でも利用や改変、再配布ができるソフトウェア）の組み込みを防いでライセンス問題を回避するためのツールです。SCAはここ数年で脆弱性を持つOSSも検出できるようにすることで、セキュリティツールとして使い道を広げてきました。

　SASTと同様に、SCAはパターンマッチングにより脆弱性を検出するため、ソースコードや利用していないOSSにも警告を出します。これは従来のSCAが、「CVE」（共通脆弱性識別子：Common Vulnerabilities and Exposures）が割り振られた脆弱性を含むライブラリを検出することはできるものの、記述したソースコードが実際にそのライブラリを利用しているかどうかまでは調査できないことが原因です。CVEは脆弱性ごとに固有の名前や番号です。

WAFの課題

　WAFは、社内LANへの不正アクセスを防ぐ一般的なファイアウォールと違い、Webアプリケーションへの攻撃を検出することに特化したセキュリティツールです。WAFはルール化された攻撃パターン集を基に悪意のある通信を検出し、アプリケーションを防御します。一方で攻撃パターン集に含まれていない“未知の脅威”は検出できないため、セキュリティエンジニアによる定期的なチューニングや運用管理が必要になります。

---

　昨今は主に2つの理由で、Webアプリケーションのリリースサイクルが高速化しています。1つ目はWebアプリケーションを狙う攻撃が勢いづいていることを受け、企業の間で新たな脅威に備える動きがあること。2つ目は激しい競争下での顧客維持・拡大のため、新規機能や差異化機能を競合に先んじて提供する重要性が高まっていることです。そうした中、DevSecOpsがうまく実現できず、Webアプリケーションの脆弱性を完全に修正しないままリリースしている企業が少なくないため、こうした脆弱なWebアプリケーションを狙った情報漏えい事件は枚挙に暇がありません。

　第2回は、SASTやDASTといった従来のテストツールの問題点を解決したセキュリティツール「IAST」（インタラクティブアプリケーションセキュリティテスト）を紹介します。

著者紹介

田中一成（たなか・かずなり）　Contrast Security Japan

国内システムインテグレーターや外資系企業で営業を経験した後、ArcSight（現Micro Focus）、41st Parameter（現Experian）、SundaySkyなど、主に米国スタートアップのカントリーマネジャーとして6社の日本オフィスを立ち上げ、成長させた。IT業界で約30年の経験があり、ハードウェア、ソフトウェア、クラウド、セキュリティ、データベース、デジタルマーケティングなどさまざまな分野に精通している。Contrast Security日本オフィスの立ち上げに尽力。