動的セキュリティテストがすべての資産に不可欠な4つの理由

この話が何度も持ち上がるのを、もう数えきれないほど見てきました。たいていは会議室で、ときにはZoomで、そしてほとんどの場合、悪気はありません。セキュリティ戦略の話し合いで、ほぼ必ず耳にする言葉があります。

「DASTはTier 1のアプリに絞ります。本当にリスクが高いのはそこです」

たいてい、スプレッドシートと整然とした分類モデルが添えられ、対象を絞ることで管理できているという安心感が生まれます。しかし、攻撃者の視点からすれば、その判断は贈り物のようなものです。

動的アプリケーションセキュリティテスト（DAST）を「重要な」アプリケーションに限定するのは、成熟したリスクベースのアプローチではありません。それは、ソフトウェアの構築方法がかつてそうだった時代の遺物であり、現代のアーキテクチャ、攻撃者、DevSecOpsツールの前では完全に通用しません。

その理由を見ていきましょう。

1. 攻撃者が狙うのは価値ではなく、弱点

セキュリティチームは、アプリケーションをビジネスへの影響で順位付けします。攻撃者は侵入のしやすさで順位付けします。この違いは重要です。

Tier 1のアプリケーションは、たいてい次のような対策が施されています。

• WAFで保護されている

• 綿密に監視されている

• 定期的にテストされている

• 経験豊富なチームが担当している

一方、Tier 3のアプリは次のような状態です。

• 急いで構築され、一度きりのことも多い

• ほとんど見直されない

• 古いフレームワークで稼働している

• 「社内向け」のはずが、そうでなくなる

攻撃者はそれを知っています。決済ゲートウェイに直接侵入しようとしているのではなく、あなたの環境へのアクセスを得ようとしているのです。率直に言えば、自動化された動的攻撃は、もはや高度な脅威アクターだけの武器ではありません。広告担当者、グロースチーム、プロダクトエンジニアは、ユーザー行動の継続的な調査、フローの最適化、大規模なエッジケースの悪用に、すでに日々活用しています。あらゆる業界が、自社システムに対して執拗な自動化実験を行うことに抵抗がないのなら、CISOやセキュリティチームが同じことをセキュリティのために行わない理由はありません。

AIを活用し、APIを中心とする世界では、この死角は特に危険です。多くの最新アプリケーションは、単一の/chatエンドポイントやエージェント用エンドポイントを公開し、「ただのAPI」として扱っています。実際には、どのツールを呼び出すか、どのデータにアクセスするか、どのアクションを実行するかを決定する、特権的な制御プレーンとして機能することが少なくありません。認可の定義が曖昧だったり、暗黙の信頼に頼っていたりすると、こうしたエージェントは権限昇格、スコープの拡大、検知されないポリシー回避の格好の手段になります。

さらに、ビジネスの現場がグロース実験ですでに実践しているのと同じ自動化、創意工夫、粘り強さをもって、AIやエージェントのエンドポイントを積極的に攻撃していないなら、それは「リスク管理」ではありません。脆弱性の発見を攻撃者に委ねているのです。

DASTを実施すると、可視性の低いアプリで認証の前提が破綻している、入力検証が欠けている、管理者用パスが露出している、APIがIDではなくネットワーク上の位置を信頼している、といった問題が一貫して見つかります。

こうしたアプリが侵害されると、IDシステム、共有データベース、社内API、CI/CDインフラへの侵入の足がかりになります。これは机上の話ではありません。現代の侵入は、実際にこのように進行します。重要なものに何でもアクセスできるアプリケーションは、「重要でない」ものではありません。攻撃対象領域の一部です。

2. 「アプリのことは把握している」は、たいてい過信

ほとんどの組織は、稼働中のアプリケーション全体をどれだけ把握できているかを大幅に過大評価しています。

実際の環境には、次のようなものが存在します。

• 停止されないまま残った古いステージング環境

• 特定の顧客1社を支えるレガシーAPI

• サードパーティがデプロイしたマーケティング用マイクロサイト

• いつの間にか恒久化した一時的なツール

こうしたアプリはアーキテクチャ図には載りません。攻撃者に発見されたときに、その存在が明らかになります。

DASTを幅広く実施する実用的なメリットのひとつは、資産の発見を促せることです。何が存在すべきかを議論するのをやめ、実際に何が存在するのかを検証できるようになります。セキュリティエンジニアリングの観点から、これは基本中の基本です。

• 洗い出していないものに優先順位は付けられない

• 到達可能だと知らないものは監視できない

• マッピングしていない攻撃対象領域は防御できない

DASTの対象範囲を広げることで、未知の露出が既知のリスクになります。リスク低減への第一歩です。

3. DASTの対象を限定すると、セキュリティ文化が損なわれる

耳の痛い話かもしれませんが、重要なことです。一部のアプリケーションしかスキャンしないと、意図するかどうかにかかわらず、重要度の認識次第でセキュリティは任意になるというメッセージを送ってしまいます。

その結果、次のようなことが起こります。

• 社内ツールのチームは、実際の脆弱性の検出結果を目にすることがない

• 開発者が悪用可能な欠陥を見抜く感覚を養えない

• セキュリティに関するフィードバックが、一部に集中した特権的なものになる

そして必然的に、「重要でない」アプリがビジネスに不可欠な存在になります。

• 顧客向けの拡張機能

• パートナーとのインテグレーション

• 収益に直結する機能

その結果、何年も実行時のセキュリティ検証を受けていないものを、外部向けにリリースすることになります。DASTは単なるセキュリティ対策ではなく、学びの仕組みでもあります。プルリクエスト上でコードがどう見えるかではなく、攻撃を受けたときにどう動くかを開発者に示します。セキュア・バイ・デフォルトな開発を実現するには、セキュリティのフィードバックを選別せず、すべてに提供する必要があります。

4. 以前のDASTに対する懸念は、もう当てはまらない

よくある懸念に正面から向き合いましょう。従来のDASTツールは、スキャンが遅く、設定が壊れやすく、誤検知が絶えず、CI/CDとの親和性も皆無で、扱いにくいものでした。「すべてをスキャンする」ことへの不安は、そこから生まれています。

しかし、最新のDASTは根本的に進化しました。

• 誤検知率が低く、ノイズを大幅に削減できる

• APIファーストのテストで、実際のアプリの構築方法に対応できる

• 認証への対応は、もはや後回しではない

• 内部スキャンも、外部に露出させず安全に実施できる

• 高速で段階的に実施でき、CI/CDパイプラインに適したスキャン

速度と網羅性のトレードオフは、もはや現実のものではありません。現代のデリバリーパイプラインを想定していなかったツールの時代に生まれた、過去の思い込みです。現在、DASTの対象範囲を限定するのは技術的な必然ではなく、戦略上の選択です。そしてたいてい、その選択は賢明とは言えません。

リスクはもはや、ビジネス価値が最も高い場所だけに存在するのではありません。前提が崩れる場所に潜んでおり、前提が最も頻繁に崩れるのは、誰も見ていない場所です。

アプリケーションに到達できる、認証が必要である、または重要なシステムから信頼されているなら、DASTを実施すべきです。

こう尋ねるのではなく、

「このアプリはビジネスにとって重要か？」

代わりに、こう尋ねてください。

「ここから攻撃者は何にアクセスできるか？」

現代の攻撃者は、最重要資産に直接侵入するわけではありません。裏口や忘れられた入口、存在すら知られていない入口から侵入します。セキュリティ戦略には、その現実を反映する必要があります。最新のアプリケーションセキュリティプラットフォームが重要なのは、まさにこの点です。単独のポイントソリューションとしてではなく、規模に応じた対策を可能にするものとして機能します。

Snykのようなプラットフォームは、リスクはもはや一か所に存在するものではないという前提に基づいています。Snyk API & Web (DAST)を使えば、チームはWebアプリとAPIの両方を継続的にテストし、実際に露出している資産を発見して、デリバリーを遅らせることなく、根拠に基づいて実際に悪用可能な問題を明らかにできます。SAST、SCA、コンテナ、Infrastructure as CodeにわたるSnykの幅広いアプリケーションセキュリティ機能と組み合わせることで、DASTはたまに行う監査ではなく、ソフトウェアの構築と運用に組み込まれたものになります。目的は、ただスキャンを増やすことではありません。死角をなくすこと、特に重要ではないと思われていたアプリに潜む死角をなくすことです。

AIを活用したSASTとDASTを組み合わせる必要性について詳しく知りたい方は、今すぐ『The Gorilla Guide® To Unified SAST and DAST in the AI Era』をダウンロードしてください。