ラジャット・シャルマ氏はCWSのセキュリティディレクターである。
こんな状況を想像してみてほしい。開発チームがアプリケーションの更新をリリースした。製品は予定通りに出荷され、顧客は大喜びだ。
しかし、脅威アクターも同様に喜んでいる。数週間後、侵害が発見される。しかもその発見は自社チームからではなく、第三者からもたらされた情報だった。通報には感謝するものの、チームは今や脆弱性の修正と公式対応に追われることになる。
残念ながら、多くの企業がこのような状況を経験している。標的型攻撃の影響を軽減するための一つの方法は、アプリケーションセキュリティ（AppSec）評価を実施することだ。これにより、不可避の事態が発生した際に必要なセキュリティ対策が整っていることを確認できる。
サイバーセキュリティにおけるAppSecの役割
フィッシングや認証情報を悪用した攻撃が侵害報告の大半を占める中、アプリケーション自体も重要な攻撃対象となっている。安全でないAPI、設定ミス、検証されていない入力など、アプリケーション内の脆弱性は直接悪用される可能性がある。
2023年、T-Mobileは公開されたAPIを攻撃者に悪用され、3700万人の顧客に影響を与える侵害を受けた。同様に2022年には、オーストラリアの通信事業者Optusが公開アクセス可能なAPIが原因で侵害を受け、約1000万人のユーザーの機密データが露出した。
現代のアプリケーションは複雑で、急速に進化し、システム全体に深く統合されている。定期的なAppSec評価と適切な管理がなければ、隠れた欠陥が悪用されるまで気付かれないままとなる可能性がある。Checkmarxの2024年レポートによると、組織の92%が過去1年間に社内開発アプリケーションの脆弱性に起因する侵害を経験している。
AppSec評価は、既存の管理策の有効性、スキャン手法、アプリケーション環境全体の可視性を評価することで、これらのリスクを明らかにするのに役立つ。これらの評価は、クラウドネイティブシステム、分散アーキテクチャ、グローバル環境の複雑さを考慮している。ガバナンスにおける定期的なチェックポイントとして使用することで、組織はセキュリティ態勢を強化し、コンプライアンスを向上させ、顧客やステークホルダーとの持続的な信頼関係を構築できる。
監査には合格したが、実際の攻撃に耐えられるか？
NIST 800-53、SOC 2、ISO 27001、PCI-DSSなどの基準への準拠は規制要件を満たすために不可欠だが、それだけでは持続的なセキュリティは保証されない。これらのフレームワークは基準を確立するが、特定の管理策の存在よりも、それらの管理策が実際にどれだけ機能しているかを重視することが少ない。
AppSecは、ガバナンス、設計、実装、運用全体にわたるセキュリティ態勢の成熟度を検証することで、別のレイヤーを追加できる。このアプローチは、どのような管理策が導入されているかだけでなく、それらが意図したとおりに機能しているか、どこにギャップが残っているか、時間の経過とともにどのように改善できるかを特定するのに役立つ。
対応する主な質問には以下が含まれる：
• 組織のサイバーセキュリティガバナンス構造は、そのミッションとステークホルダーの期待に沿っているか？
• 資産、データ、サプライチェーンに関連するサイバーセキュリティリスクを効果的に特定・管理しているか？
• 重要な資産を保護するためにどのような安全対策が講じられているか？
• サイバーセキュリティインシデントの検出、対応、復旧において組織はどの程度の能力を持っているか？
これらの領域を体系的に分析することで、AppSec評価はセキュリティ対策をビジネス目標に合わせ、常に進化する脅威環境における回復力を確保できる。
中小企業におけるAppSecの活用法
スタートアップや中堅企業は、AppSecを大企業の懸念事項と捉えがちだ。しかし、小規模な組織でもサイバー脅威の格好の標的になりうる。開発プロセスの早い段階でAppSec評価を実施することで、ギャップを特定し、成長に合わせてセキュリティを維持できる。
典型的な評価は準備から始まる。レビュー対象となる特定のアプリケーションの範囲を決め、関連するチームとステークホルダーを特定する。組織はソフトウェア開発ライフサイクル（SDLC）のワークフローを概説し、現在のツール使用状況、実践、ポリシー、実施状況をレビューする。
エンジニアリング、プロダクト、運用、セキュリティとのワーキングセッションでは、ソフトウェアの提供方法、サードパーティの利用方法、管理策の運用場所について検討する。評価は現状の明確な把握、目標とする態勢、優先順位付けされた推奨事項で締めくくられ、必要に応じて認知されたアプリケーションセキュリティフレームワークにマッピングされる。
開発者が安全なコードを提供するために必要なもの
開発者は安全な製品を構築するために不可欠だが、明確さとサポートが必要だ。AppSec評価は、レビューされていないスキャン結果、不明確な所有権、ポリシーで定義されているがSDLCワークフローで実施されていないチェックなどのギャップを特定する。
典型的な摩擦ポイントは、ノイズの多い発見事項と不明確な引き継ぎだ。トリアージ担当者を指名し、チケットの作成方法を定義し、重大な問題に対する「完了」の意味について合意することでこれらを解決する。結果として、組織全体の標準がSDLCに組み込まれる。
発見事項は明確な所有者と優先順位でトリアージされ追跡されるため、ソフトウェアは最初からセキュリティを念頭に置いて構築される。
AppSec評価のベストプラクティス
成熟したチームでもAppSec評価で摩擦が生じることがある。
例えば、アプリケーションリストが不完全であったり、SDLCワークフローが文書化されていなかったり、責任が不明確であったりすると、進捗が遅れる。コーディネーターを指名し、どの製品とパイプラインが対象範囲かについて合意し、エンジニアリング、プロダクト、セキュリティ、運用のリーダーを招集して、その場で決定できるようにする。
評価中は、データ品質とツールの乱立が一般的な問題点だ。多くの組織では、スキャナーは稼働しているが調整されておらず、発見事項がレビューされることはなく、ポリシーには記載されているがパイプラインでは実施されていないチェックがある。
リクエストからリリースまでの実際のパスをたどり、チェックが実行される場所、結果をレビューする人、所有権がどのように割り当てられるかを確認する。評価後は、実行が作業となる。推奨事項は、納品に対して優先順位付けされていない場合や、チケットに所有者がいない場合に失敗する。
発見事項をビジネスへの影響とリスクに関連付けた段階的な計画に変換する。責任ある所有者を割り当て、通常の計画サイクルに組み込み、レビューのケイデンスを設定する。セキュリティチェック付きのパイプライン、重大な問題の修正時間、セキュリティスキャンのカバレッジなど、重要な成果を追跡する。開発者を管理策の設計に参加させることで、納品を遅らせることなくセキュリティを向上させる。
これらの課題を予測することで、評価は一度限りのレポートではなく、着実で測定可能な改善のための触媒となる。
