「SAST」「DAST」「SCA」がDevSecOpsに向かない“なるほどの理由”

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

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

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

DevSecOpsについて知る

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

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

図

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

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

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

SAST、DAST、SCA、WAFの課題

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

Subscribe to get access

Read more of this content when you subscribe today.

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」(インタラクティブアプリケーションセキュリティテスト)を紹介します。

著者紹介

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

https://techtarget.itmedia.co.jp/tt/news/2110/29/news03.html

Leave a Reply