AppSecの成功を測定する：価値を示す主要KPI

ソフトウェア開発業界では、ソフトウェア開発ライフサイクル（SDLC）をサイバー脅威から事前に保護することが、常に最優先事項でなければなりません。シフトレフトのアプローチを取り入れることで、早い段階からセキュリティに対処でき、開発チームは脆弱性への対応に費やす時間を減らし、イノベーションにより多くの時間を割けるようになります。しかし、それは始まりにすぎません。

AppSecチームは、AppSecプログラムが意図したとおりに機能し、ビジネス価値をもたらしていることも、CISOやその他の経営幹部に示す必要があります。そのため、AppSecへの投資がどのようにリスクを低減し、会社のビジネス目標達成に貢献しているかを可視化することが重要です。ただし、AppSecの成功を示すには時間がかかります。まず、プログラムの仕組みを経営幹部やステークホルダーが明確に把握できるよう、適切なKPIと指標を特定して収集する必要があります。次に、これらの指標を、対象者の心に響くストーリーへとまとめなければなりません。

このガイドでは、AppSecプログラムの成功を適切に測定し、伝える方法をご紹介します。意思決定者やマネージャーに、この分野への投資が継続的な成果をもたらしていることを理解してもらいましょう。

AppSecプログラムの主要業績評価指標（KPI）

「測定できないものは管理できない」というよく知られたビジネスの格言は、何かが機能しているかを示すにはデータが必要だということを表しています。これはAppSecにも当てはまります。数値化可能な指標を使えば、セキュリティ対策の有効性を測り、改善すべき領域を特定できます。注目すべきKPIは、次の4つのカテゴリーに分けられます。

1. リスク低減指標

2. チームの対象範囲と参加状況

3. アプリケーションセキュリティ態勢の推移

4. 脆弱性管理の効率性

リスク低減指標

リスク低減指標は、組織がセキュリティ脅威による潜在的な影響をどの程度軽減しているかを示します。代表的な指標は次のとおりです。

• 重大な脆弱性の数：重大な脆弱性の数を時系列で追跡します。

  • AppSecプログラムが成功していれば、数が減少傾向を示し、組織が直面する高リスクの脅威が減っていることが分かります。

• 脆弱性の修正率：一定期間内に脆弱性へ対処した割合を測定します。

  • たとえば、ある月に脆弱性が120件発見され、そのうち60件を修正した場合、月間の脆弱性修正率は50%です。

• 高リスクアプリケーションの割合：機密性が高い、またはビジネス機能にとって重要なアプリケーションの割合を測定します。

  • この指標を把握すると、脆弱性対応の優先順位を判断しやすくなります。できれば、まず高リスクアプリケーションへの脅威に対処しましょう。

• セキュリティ負債：時間の経過とともに蓄積する未解決のセキュリティ課題を追跡します。

  • セキュリティ課題を修正せずに放置する期間が長いほど、セキュリティ侵害やエクスプロイトが発生する可能性は高まります。この負債を追跡することで、組織全体のセキュリティ態勢を把握できます。

チームの対象範囲と参加状況

AppSecチームだけで脅威を防ぐことはできません。脅威を効果的に減らすには、部門横断的なチームと連携し、組織全体のセキュリティ向上に参加してもらう必要があります。各チームの参加度や関与度を測定すれば、AppSecの成功を示すことができます。役立つ指標には、次のようなものがあります。

• セキュリティテストの対象となっているアプリケーションの割合：セキュリティ評価を受けたアプリケーションの割合を追跡します。

  • カバー範囲に潜在的な抜け漏れが少ないことを示すため、この割合は高いほど望ましいと言えます。

• 開発者向けセキュリティトレーニングの完了率：セキュリティトレーニングを受講した開発者の割合を測定します。

  • セキュリティトレーニングを修了した開発者は、セキュアなコーディング手法を取り入れやすくなり、自身の開発成果をサイバー脅威から守る力が高まります。

• アプリケーションあたりのセキュリティ検出事項：アプリケーションごとに特定された脆弱性の数を追跡します。

  • この指標の解釈には注意が必要です。数が多い場合、テストが徹底されていることを示す一方、開発者がセキュアなコーディング手法を実践できていない可能性もあります。

• セキュリティ関与までの平均時間（MTSI）：開発ライフサイクルのどの段階でセキュリティチームが関与するかを測定します。

  • 開発プロセスの早い段階でセキュリティチームを関与させることで、問題が発生する前に脆弱性を特定して修正できます。

アプリケーションセキュリティ態勢の推移

AppSecプログラムが意図したとおりに機能していれば、指標は時間とともに望ましい方向へ推移するはずです。それを確かめるには、セキュリティの健全性を測る具体的な指標を追跡する必要があります。たとえば、次のような指標が挙げられます。

• 未解決の脆弱性の数：AppSecチームがセキュリティ課題の解決にどの程度追いついているかを追跡します。

  • 未解決の脆弱性が時間とともに減っていることを示すため、推移は下降傾向になるのが理想です。

• 脆弱性の再発率：同じ脆弱性がアプリケーションで再び発生する頻度を測定します。

  • 再発率が高い場合、同じ問題への対応を繰り返さずに済むよう、開発者のセキュリティプラクティスの改善や、より厳格なテストプロセスの導入が必要だと考えられます。

• 既知の脆弱性がないアプリケーションの割合：アプリケーションに脆弱性が入り込むのを、組織がどの程度防げているかを示します。

  • 割合は高いほど望ましいですが、既知の脆弱性がないからといって安心しすぎないようにしましょう。まだ知られていない、または発見されていない脅威は、この指標では考慮されません。

• セキュリティパッチの適用率：組織がセキュリティパッチを適用する速さを測定します。

  • 適用率が高いことは、組織が脆弱性に積極的に対処し、セキュリティリスクへの露出を減らしていることを示します。

脆弱性管理の効率性

このカテゴリーでは、組織が脆弱性をどれだけ効率的に発見し、修正しているかに注目します。効率性が高まれば、開発者がセキュリティ課題の修正に費やす時間を減らし、生産性を向上できます。その結果、より良いソフトウェアの開発に専念できます。このカテゴリーの重要な指標は次のとおりです。

• 平均検出時間（MTTD）：脆弱性が発生してから検出されるまでの平均時間を測定します。

  • 検出時間が短いほど、問題を早期に発見するアプローチが効果的であることを示します。

• 平均修正時間（MTTR）：脆弱性を検出してから修正するまでの平均時間を測定します。

  • 修正時間が短縮傾向にあれば、効率的な脆弱性管理プロセスを構築できていることを示します。時間が長くなる傾向にある場合は、プロセスの見直しが必要です。

• 深刻度別の脆弱性対処率：組織が深刻度（例：重大、高、中）に基づいて脆弱性にどれだけ適切に優先順位を付けているかを測定します。

  • 最適化された脆弱性管理プログラムでは、深刻度の高い脆弱性から優先的に対処します。

• 誤検知率：報告された脆弱性のうち、実際の脅威ではないものの割合を示します。

  • 誤検知率が高いと、実在しない脆弱性の調査や修正にチームの貴重な時間と労力が費やされます。その場合は、より優れたテストソリューション（例：SCAやSASTツール）への投資や、セキュリティプロセスの見直しが必要かもしれません。

経営幹部のステークホルダーにROIを示す

指標の収集を始めるのは簡単だというチームもあります。難しいのは、数値とAppSecの成功事例を経営幹部やステークホルダーに提示し、プログラムの価値を十分に理解してもらうことです。そのためには、AppSecが組織の主要なビジネス目標の達成にどう貢献しているかを明らかにする、慎重に練られたストーリーが必要です。

技術的な指標をビジネス価値に置き換える

経営幹部が最も気にかけているのは何でしょうか。多くの場合、収益、スケジュールの順守、リスク管理、そして組織の提供する製品やサービスがビジネスの成功につながるかどうかです。文脈を示さずに数字を並べても、意思決定者の関心を引くことはできません。代わりに、リスク低減による財務的な効果を示しましょう。また、重大な脆弱性の数を減らすことで、侵害関連のコストをどれだけ抑えられるかも算出しましょう。

経営幹部は、セキュリティへの取り組みが業務効率の改善にどう役立つかを知りたいと考えています。開発の手戻りを減らし、市場投入までの時間を短縮することで、AppSecの取り組みがどれだけの時間を節約しているかを具体的に示しましょう。コンプライアンスはビジネスに不可欠な要素です。AppSecが関連規制（例：HIPAA、GDPR、PCI-DSSなど）への準拠にどう役立つかを示すことで、セキュリティのビジネス価値をさらに強調できます。

AppSecの成功を伝えるストーリーを作る

AppSecチームは問題の検出や脆弱性の集計に長けているかもしれませんが、プログラムの価値を伝えるには効果的なストーリーテリングが必要です。まず、成果に焦点を当てましょう。実施したセキュリティテストの数を示すだけでなく、そのテストによって脆弱性を特定し、セキュリティ侵害を防いだことや、製品のローンチスケジュールの達成に役立ったことを伝えましょう。

ケーススタディも、成功を分かりやすく伝えるのに役立ちます。たとえば、脆弱性を適時に修正したことで、同業他社に影響を及ぼした実際のインシデントを回避できた事例を紹介できます。グラフや図表などの視覚資料を使うと、特にMTTRの短縮といった好ましい傾向を示す際に、主張が伝わりやすくなります。最後に、AppSecが収益の拡大、ブランドの保護、顧客の信頼構築をどう支えているかを必ず結び付けましょう。

ASPMでAppSecの成功事例を作る

アプリケーションセキュリティ態勢管理（ASPM）は、アプリケーション環境を包括的に可視化し、関連指標を集約し、自動化を活用して脆弱性を管理することで、AppSecプログラムの成功を支援します。SnykとAccentureのホワイトペーパー開発者の力を引き出し、リスクを低減：ASPMがDevSecOpsを実現する方法をダウンロードして、詳細をご覧ください。

ASPMは、アプリケーションセキュリティに関するさまざまな課題を組織が効果的に管理するのに役立つと、私たちは考えています。Snyk AppRiskは開発者を第一に考えたASPMツールです。AppSecチームに、セキュリティの健全性を高めるために必要な可視性、コンテキスト、制御を提供します。デモを予約して、Snyk AppRiskが記録的な速さでリスク低減を実現する方法をご確認ください。