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

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

2022年04月25日 05時00分 公開
[田中一成]

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

DevSecOpsとは

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

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

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

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

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

 これらの脆弱性検出ツールはそもそも、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日本オフィスの立ち上げに尽力。


Copyright © ITmedia, Inc. All Rights Reserved.

譁ー逹€繝帙Ρ繧、繝医�繝シ繝代�

製品資料 株式会社ビルドシステム

「ローコード開発×内製化」失敗の理由とは? 3つの事例から得た2つの教訓

迅速なサービスの提供を実現する手段として、「ローコード開発×内製化」が注目されている。エンジニア不足の中でも、非IT部門が開発を担える点がその理由の1つだが、全てが順調に進むわけではない。失敗事例から得た2つの教訓を紹介する。

製品資料 株式会社ビルドシステム

“ローコード開発ツールを活用した内製化”を成功に導く3つのポイント

多くの企業がDXの取り組みとして、ローコード開発ツールを活用した内製化を進めている。しかし、実務で使えるアプリケーションをローコードで構築するには、いくつかの課題を解消することが必要だ。本資料で詳しく解説する。

製品資料 株式会社matchfy

マッチングサイト構築の課題を解決、ノーコードで構築できるプラットフォーム

企業がマッチングサイトを構築する際、従来は数百万円の初期開発費と数カ月の構築期間が必要だった。さらに、契約・決済・スケジュール調整・ユーザー管理などの機能も個別に開発する必要があった。このような課題を解決する方法を探る。

事例 オーティファイ株式会社

みずほリースなど9社の事例に学ぶ、テストの工数やコストを削減する秘策

プロダクトの品質を確保するためには、テストの工程が重要になる。しかし、リソースや人材の不足などさまざまな課題を抱えている企業も多い。そこで本資料では、みずほリースなど9社の事例からテストの課題を一掃する方法を解説する。

事例 オーティファイ株式会社

ソフトウェア開発のテストはこう乗り越える、8社の事例に学ぶ課題解決のヒント

ソフトウェア開発における「テスト」では、コストを抑えながら迅速に対応することが求められる。人材やスキルが不足していても、品質の確保は怠れない。本資料では、このような課題に企業がどのように向き合い、解決したかを紹介する。

アイティメディアからのお知らせ

From Informa TechTarget

なぜクラウド全盛の今「メインフレーム」が再び脚光を浴びるのか

なぜクラウド全盛の今「メインフレーム」が再び脚光を浴びるのか
メインフレームを支える人材の高齢化が進み、企業の基幹IT運用に大きなリスクが迫っている。一方で、メインフレームは再評価の時を迎えている。

繧「繧ッ繧サ繧ケ繝ゥ繝ウ繧ュ繝ウ繧ー

2025/08/14 UPDATE

  1. 繧ウ繝シ繝峨�繧ゅ≧譖ク縺九↑縺�€補€墓€・騾溘↓豬ク騾上☆繧九€後ヰ繧、繝悶さ繝シ繝�ぅ繝ウ繧ー縲阪�迴セ螳�
  2. 縺�∪縺輔i閨槭¢縺ェ縺�€後せ繝医Μ繝シ繝�蜃ヲ逅�€阪→縲後ヰ繝�メ蜃ヲ逅�€阪�驕輔>縺ィ縺ッ��
  3. 縲後Γ繧ソ繝舌�繧ケ縺ョ辭ア迢ゅ€阪′豸医∴縺ヲ縺励∪縺」縺溪€懷ス鍋┯縺ョ逅�罰窶�
  4. 縺�∪縺輔i閨槭¢縺ェ縺�€後せ繝医Μ繝シ繝�蜃ヲ逅�€阪→縺ッ�溘€€繝ェ繧「繝ォ繧ソ繧、繝�蛻�梵縺ョ蝓コ遉守衍隴�
  5. 繧ェ繝シ繝励Φ繧ス繝シ繧ケ縺ョ縲檎曝縺�o縺ェ縲阪€€縺昴�閾ェ逕ア縺後b縺溘i縺吮€應ク崎�逕ア縺ェ迴セ螳溪€�
  6. 繧ェ繝ッ繧ウ繝ウ蛹悶°繧牙�豬ョ荳翫€€AR�酬R縺ォ險ェ繧後◆窶懊∪縺輔°縺ョ螻暮幕窶�
  7. 縲郡DK縲阪→縲窟PI縲阪�驕輔>縺ィ縺ッ�溘€€縺ゥ縺�スソ縺��縺代k��
  8. Google繧БWS縺ェ縺ゥ螟ァ謇紀T繝吶Φ繝€繝シ縺後%縺槭▲縺ヲ謗。逕ィ縲€縲窟pache Iceberg縲阪→縺ッ菴戊€�°
  9. 縲後Ο繝シ繧ウ繝シ繝峨€催励€沓PM縲阪〒讌ュ蜍吶r縺ゥ縺�、蛾擠縺ァ縺阪k�溘€€縺吶$縺ォ蠢懃畑縺ァ縺阪k豢サ逕ィ萓�
  10. 縲後Ο繝シ繧ウ繝シ繝蛾幕逋コ縲阪→縲沓PM縲阪€∵・ュ蜍呎隼蝟�€�2螟ァ謇区ウ補€昴�驕輔>縺ィ豢サ逕ィ繝昴う繝ウ繝�

ITmedia マーケティング新着記事

news017.png

「サイト内検索」&「ライブチャット」売れ筋TOP5(2025年5月)
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。

news027.png

「ECプラットフォーム」売れ筋TOP10(2025年5月)
今週は、ECプラットフォーム製品(ECサイト構築ツール)の国内売れ筋TOP10を紹介します。

news023.png

「パーソナライゼーション」&「A/Bテスト」ツール売れ筋TOP5(2025年5月)
今週は、パーソナライゼーション製品と「A/Bテスト」ツールの国内売れ筋各TOP5を紹介し...