アプリケーションセキュリティ完全ガイド：ツールとベストプラクティス
このアプリケーションセキュリティガイドで、2025年も安全を保つために必要な情報をすべてご紹介します
0 分で読めます
アプリケーションセキュリティ（AppSec）とは？
アプリケーションセキュリティ（AppSec）はソフトウェア開発における重要な要素であり、アプリケーションのセキュリティ脆弱性を特定、修正し、防止することを目的としています。セキュアなソフトウェア開発ライフサイクルを導入し、セキュリティ対策を強化するとともに、データの完全性、機密性、可用性を確保することを目指します。
アプリケーションセキュリティ（AppSec）は重要な取り組みです。ソフトウェアアプリケーションのライフサイクル全体を通じて、セキュリティ上の欠陥を発見し、防止し、修正します。対象はコードだけにとどまらず、システム設定、設計、データベース、API、そしてそれらが稼働するネットワークも含みます。AppSecの主な目的はセキュリティを強化し、アプリが扱うデータの安全性、機密性、可用性を確保することです。これにより、新たなオンライン脅威からアプリを守ります。
アプリケーションセキュリティが重要な理由
アプリケーション、特にクラウドネイティブアプリケーションは、サーバーやネットワークへの入口となり、悪意ある攻撃者にとって理想的な攻撃経路となるため、アプリケーションセキュリティは不可欠です。そのため、アプリケーションは攻撃者の格好の標的になります。開発の初期段階からセキュリティを組み込むことで、AppSecは弱点が悪用される前に発見します。
悪意ある攻撃者はソフトウェアへの侵入手法を進化させ続けているため、セキュリティは開発プロセスに深く組み込まれた継続的な取り組みでなければなりません。
アプリケーションセキュリティのベストプラクティスは、攻撃者がネットワークやデータへの侵入に利用する前に脆弱性を発見するのに役立ちます。また、顧客情報などの機密データを確実に保護するため、アプリケーションデータのセキュリティも考慮することが重要です。
脆弱性は、設定ミスや、既知の脆弱性を含むソフトウェアコンポーネントの使用といった、単純な原因から生じることがあります。この問題は広く見られます。Snykの「2021 State of Cloud Native Application Security」レポートによると、56%を超える組織が、クラウドネイティブアプリケーションに関連する設定ミス、または既知の未修正脆弱性によるインシデントを経験しています。すべての脆弱性が重大なセキュリティリスクになるわけではありませんが、ハッカーは侵入に利用できそうな脆弱性を見つけるために評価を行います。
最もよくある問題は、設定ミスと、既知の未修正の脆弱性です
あらゆる規模の組織が、設定ミスによるリスクを認識する必要があります。特に、金融機関のように機密性の高いデータを扱う組織は注意が必要です。
AppSecセキュリティを強化するには
アプリケーションセキュリティを強化するには、企業は次の2つのアプローチを実践する必要があります。
プロセスの改善
シフトレフトのセキュリティ文化。セキュリティを後工程に回さず、設計、計画、コーディングの段階から取り入れます。
セキュアSDLC ＋ 脅威モデリング。早い段階でセキュリティ要件を定義し、脅威モデリングを実施して、安全なコーディング基準を徹底し、テストを統合するとともに、アプリケーションを継続的に監視してパッチを適用します。
開発者のトレーニングと意識向上。定期的な実践型セキュリティトレーニングを実施し、OWASP Top 10のリスクに対する意識を高め、計画からデプロイまで開発者の責任意識を促します。
ツールと自動化
開発プロセスに統合されたSAST、DAST、RASPツール。静的アプリケーションセキュリティテスト（SAST）、動的アプリケーションセキュリティテスト（DAST）、ソフトウェア構成分析（SCA）を活用し、IDE、プルリクエスト、CI/CDパイプラインに組み込んで、脆弱性を早期に検出します。
WAF、依存関係スキャン、CI/CDチェック。WAFを導入して悪意あるトラフィックをフィルタリングし、アプリケーションに到達する前にブロックすることで、一般的なWeb攻撃に対する第一線の防御とします。
継続的な取り組み
安全な設計とコーディング。入力値の検証、出力のサニタイズ、安全なライブラリの使用により、インジェクション、XSS、バッファオーバーフロー、アクセス制御の不備、設定ミスを防ぎます。
パッチ管理と適切な設定の維持。既知の脆弱性や設定ミスによるリスクを軽減するため、サードパーティ製ソフトウェア、ライブラリ、OS、インフラに定期的にパッチを適用します。
セキュリティテスト、ログ記録、監視。開発中からデプロイ後まで、SAST、DAST、ペネトレーションテスト、監査を継続的に実施し、変化する問題を検出します。
クラウドとコミュニティ
Snyk AI Security Platformは、Snyk Code、Snyk Open Source、Snyk IaCなどのツールを提供し、セキュリティ上の問題を監視して修正します。これらのツールは開発者の既存のワークフローに組み込めるため、アプリケーションセキュリティを高めるうえで、セキュリティ対策を可能な限り自動化できます。
アプリケーションセキュリティのギャップ分析を実施する方法
このガイドでは、資産の可視性、AppSecのカバレッジ、優先順位付けを対象に、アプリケーションセキュリティのギャップ分析を実施する手順を解説します。
アプリケーションセキュリティにおける一般的なリスクとその影響とは？
現代のアプリケーションセキュリティは、幅広く複雑なテーマです。ここでは、組織がよく直面する主な課題を5つにまとめました。
カテゴリ | 関連するOWASPリスク／問題 |
継承された脆弱性 | アクセス制御の不備、インジェクション、安全でない設計、設定ミス、認証の失敗、完全性の失敗 |
サードパーティおよびオープンソースのリスク | 脆弱で古いコンポーネント、OSS固有のサプライチェーンリスク |
DevSecOpsのアプローチ | 安全でない設計、完全性の失敗、パイプラインのセキュリティ、早期検出ツール |
適任者の確保 | スキル不足と人員不足がセキュリティの有効性に影響する |
ツールの一元管理の欠如 | 連携の取れていない運用、可視性の低さ、チーム間での非効率なカバレッジ |
それぞれの課題を詳しく見ていきましょう。
継承された脆弱性
これらは、自社のコードベースにおける設計や実装上の選択に起因する欠陥です。
ソフトウェアシステムはエントロピーの影響を受けます。絶えず変化して複雑さが増し、更新や改善が必要になります。
どの修正、更新、保守作業が最も重要かを判断する脆弱性の優先順位付けは、重要かつ継続的な取り組みです。
多くの組織の環境では、レガシーコードが今も重要な役割を果たしています。セキュリティチームはこのコードをスキャンし、最も重要な修正に優先順位を付ける必要があります。古いコードは新しいアプリケーションコードほど魅力的ではないため、関心を持つ人は少ないものの、セキュリティ面で慎重に検討する必要があります。
最新のセキュリティツールは、レガシーコードへの対応を想定してライセンスされていないことがよくあります。コードが保守されず、安全が確保されなければ、問題は時間とともに積み重なります。
サードパーティおよびオープンソースの脆弱性
これらは、自社で直接管理できない外部ライブラリやコンポーネントに起因します。
サードパーティやオープンソースのライブラリが広く使われているため、攻撃者にとって魅力的な攻撃経路になっています。推移的（間接的）依存関係は特に注意が必要です。開発者が脆弱なパッケージを使っていることに気付かない場合があるためです。
ただし、オープンソースの依存関係に関する懸念は、外部の攻撃者だけではありません。メンテナー自身が悪意あるコードや脆弱性を含むパッケージをリリースする可能性もあります。
こうした脆弱性をすべて手作業で見つけることは不可能です。そのため、オープンソースの依存関係を保護するには、更新が必要な対象とタイミングを把握し、新たな脆弱性の発生を検出できるツールが必要です。スキャンツールに加えて、ポリシーの適用もプロジェクトの初期段階からセキュリティを組み込むのに役立ちます。チームはベストプラクティスに沿ったポリシーを策定し、それを適用するツールを選ぶべきです。たとえばOpenSSFフレームワークは、オープンソースソフトウェアプロジェクトが遵守すべきルールを定めています。すべての人がこのフレームワークを活用すれば、セキュリティツールの必要性は下がるかもしれませんが、近いうちにそうなる可能性は低いでしょう。
AppSecにDevSecOpsのアプローチを取り入れる
セキュリティツールの導入に加え、シフトレフトのアプローチを採用し、開発プロセス全体にセキュリティを組み込むことが不可欠です。従来、スキャンはソフトウェア開発ライフサイクルの後半に実施されていました。その結果は修正のために開発チームへ戻され、セキュリティチームが他の業務のボトルネックとなっていました。ツール自体も、開発者にさらなる負担をかけていました。誤検知が多く、チームメンバーは問題のトリアージに時間を取られていたのです。
この従来のアプローチは、ウォーターフォール型でソフトウェアをリリースする組織では十分に機能しました。しかし現代のソフトウェア開発では、セキュリティと開発のより緊密でアジャイルな連携が求められます。開発の早い段階で問題を発見して修正すれば、セキュリティチームだけでなく、関係者全員にとってプロセスが効率化します。
シフトレフトテストでは、CI/CDパイプラインのできるだけ早い段階からテストのベストプラクティスを取り入れます。
シフトレフトテストでは、CI/CDパイプラインのできるだけ早い段階に、テストのベストプラクティスを組み込みます。
適任者の確保
シフトレフトに加えて、セキュリティの人的側面も重要です。適任のセキュリティ専門家を確保することは最優先事項です。また、セキュリティチーム自身もトレーニングを強化し、効率的なプロセスを整え、ツールを分析する必要があります。そうすることで、CI/CDパイプラインと並行してスキャンを実行し、開発者が簡単に修正できる、より統合されたセキュリティアプローチを実現できます。開発者とセキュリティ担当者の比率は約100対1であり、経験豊富なサイバーセキュリティ人材の採用が難しいことから、教育と自動化を通じて、開発者によるセキュリティ対策に期待する組織が増えています。
一元管理ツールの欠如
セキュリティ担当者は、組織が許容するリスクを管理する役割を担います。リスクをゼロにできるという考えは、最善の場合でも楽観的すぎ、最悪の場合は逆効果です。リスク管理では、アプリケーションに含まれる脆弱性を評価し、どの問題に、いつ、どのように対処するかを優先順位付けすることが重要です。
アプリケーションセキュリティチームには、その業務を支援するツールが必要です。アプリケーションのセキュリティ態勢を継続的に監視・評価し、作業の効果を追跡するための適切なアプリケーションセキュリティ指標を使用する必要があります。セキュリティ態勢とは、アプリケーションのあらゆるレベルにおけるセキュリティ知識を組み合わせたものです。この知識をもとに、セキュリティチームは問題をトリアージし、アプリケーションセキュリティプロセスの一環として対応すべき課題のバックログを作成します。
最後に、セキュリティチームはバックログにある問題が適切かつ迅速に解決されていることを監視し、確認する必要があります。優れたツールなら、必要なレポートをすべて一元管理し、単一のダッシュボードで関係者に提示できます。
アプリケーションセキュリティアーキテクチャの3つの層
現代のアプリケーションのアーキテクチャは3つの層で構成されています。それぞれの層には対処すべき固有のリスクがあります。各層の構成と潜在的なリスクを見ていきましょう。
1. 最上位層：クライアント
この最上位層は、Webフロントエンド、IoT（モノのインターネット）フロントエンド、またはモバイル フロントエンドであり、ユーザーがアプリケーションを操作する場所です。フロントエンド開発者は、エンドユーザーに高性能で高品質な体験を提供することを重視しますが、フロントエンドの種類ごとに脅威の特性が異なるため、セキュリティを見過ごしてはなりません。インジェクションやサービス拒否攻撃など、フロントエンドを攻撃する方法は数多くあります。
2. 中間層：アプリケーション
この層では、ユーザーから収集したデータを処理します。階層化アーキテクチャは、エンドユーザーとデータの間にファイアウォールのような境界を設け、エクスプロイトからの保護に役立ちます。細かく調整されたアクセス制御など、他のツールもこの中間層の保護に役立ちます。
3. 最下層：バックエンド
ここには、オペレーティングシステム、クラウドインフラ、コンテナなど、アプリケーションの実行やデータの保存に使われるすべてのものが含まれます。多くの攻撃はこの層への侵入を狙うため、安全な設定、適切に構成されたネットワーク、強固なデータ暗号化によってバックエンドを保護することが重要です。
モダンなアプリケーションのアーキテクチャ図
以下の図は、最新のアプリケーションのアーキテクチャを示しています。フロントエンドを支えるのはビジネスロジックとデータのレイヤーで、フロントエンドにAPIを公開し、クラウド（AWS、Azure、Google Cloudなど）内で実行されます。
左側では、ソースコードがクライアントとロジック、依存関係のパッケージ、クラウド仕様（IaCを使用）、そしてアプリケーションの実行に使われるコンテナの設定を定義するファイルを表しています。
右側は本番環境の運用管理です。本番環境のクラウド管理コンソールは、ハッカーにとって特に価値の高い標的です。誰かがクラウド管理コンソールを掌握すると、マシンを乗っ取ってビットコインをマイニングするなど、不正な用途に利用される可能性があります。
セキュリティを各層にわたって統合し、管理・運用できるようにすることが重要です。これにより、クラウドの過剰な利用につながるクリック詐欺を検出できるなど、さらなるメリットも得られます。
アプリケーションセキュリティのアーキテクチャ図
アプリケーションセキュリティのベストプラクティス
アプリケーションセキュリティを支える3つの柱
効果的なアプリケーションセキュリティを支える柱は、主に次の3つです。
テクノロジー：プロセスやトレーニングのためのツールを含む
プロセス：ポリシー、原則、コントロールを含む
人材：セキュリティに関する教育やトレーニングが必要（フィッシング対策など）
アプリケーションセキュリティにおける重要なベストプラクティスを紹介します。
テクノロジー：ツールを見直す
まず、相互に連携でき、リソースや予算に合った包括的なツールセットを定義しましょう。最適なツールは推奨事項を提示しますが、その価値を最大限に引き出すには、人が実際に対応する必要があることを忘れないでください。
新しいツールを調べ、その機能を確認しましょう。
ツールのロードマップを策定しましょう。ツールは今後どう進化するのか、ツール活用のビジョンは何か、ビジネスのニーズに対応し続けられるのかを検討します。
プロセス：明確にする
まず、アプリケーションセキュリティのプロセスを定義しましょう。明確にするために、文書にまとめてください。
プロセスをテストしましょう。本当に機能するでしょうか。緊急事態が起きてからではなく、テスト中に問題を把握するほうが賢明です。
プロセスのリポジトリを整備しましょう。プロセスを一か所にまとめておくことで、オンボーディングに役立つほか、プロセス間の重複にも気づきやすくなります。
人材：それぞれの役割を尊重する
セキュリティチームと開発者は、知識を活用して働く人材です。ソフトウェア自体にアップグレードが必要なように、彼らにも継続的な成長が必要です。セキュリティ分野は絶えず変化していますが、開発者コミュニティには豊富な情報やトレーニング、イベントがあります。脅威やその緩和策の変化を把握できるよう、人材の教育と育成に投資しましょう。
セキュリティのあらゆる層に投資しましょう。清掃スタッフからCEOまで、全員がセキュリティの重要性やルールを理解できるようにする必要があります。
ささいなことでも、誰もが率直に声を上げられる文化を育みましょう。「気づいたら、伝えて、解決する」をモットーにしてください。誰も問題を報告しなければ、解決できません。
アプリケーションセキュリティに使われる最適なツールやテクノロジーとは？
スキャンツールは、アプリケーションを本番環境で実行する前にテストできるため、アプリケーションセキュリティの中核を担います。ソースコードを直接スキャンするものや、入力値を与えてアプリケーションを実行しながら評価するものなど、さまざまな種類があります。代表的なスキャンツールを6つ紹介します。
静的アプリケーションセキュリティテスト（SAST）：ソースコードにアクセスするホワイトボックステスト手法です。実行していない状態のコードを分析し、脆弱性につながる弱点を特定してレポートを生成します。
対話型アプリケーションセキュリティテスト（IAST）：このアプリケーションセキュリティテストでは、アプリケーションの実行中にソースコードをスキャンして脆弱性を検出し、ユーザーが一般的に行う操作をシミュレートします。
ソフトウェア構成分析（SCA）：オリジン分析とも呼ばれ、ソースコードを含むソフトウェアコンポーネントやライブラリをすべて分析する手法です。既知の脆弱性を特定し、利用可能なパッチや更新をユーザーに通知します。
動的アプリケーションセキュリティテスト（DAST）：実行中のアプリケーションにさまざまな攻撃を試みて、セキュリティ状態をテストします。ソースコードへのアクセスが不要なため、ブラックボックステスト手法に分類されます。
サービスとしてのアプリケーションセキュリティテスト（ASTaaS）：この場合、組織は外部企業にアプリケーションのテストを委託します。ASTaaSでは通常、静的・動的なセキュリティ手法のほか、ペネトレーションテストやアプリケーション・プログラミング・インターフェース（API）の評価も組み合わせて実施します。
ファジング：ランダムなデータを入力してアプリケーションをテストし、潜在的なバグを見つける手法です。ファジングは、IAST、DAST、SASTなどのテストを補完します。
SASTとDASTとSCAの比較
Snykによるアプリケーションセキュリティ
Snykは、開発者が既存のワークフローに組み込めるエンドツーエンドのモニタリングと対策を提供する、不可欠なアプリケーションセキュリティテクノロジーです。次のようなツールを提供しています。
Snyk Code：修正を簡単かつ効率的に行える、開発者ファーストのSASTツールです。
Snyk Open Source：オープンソースの脆弱性を検出し、優先順位を付けるソフトウェア構成分析（SCA）ツールです。
Snyk Container：ベースイメージからランタイムまで、コンテナのセキュリティ確保を支援するツールです。
Snyk IaC：開発者が安全なIaC構成を記述できるよう支援するツールです。
Snyk AppRisk：資産を検出し、セキュリティツールで保護され、脆弱性がない状態を維持できるよう支援するASPMツールです。
Snykのツール群がアプリケーションセキュリティにどのように役立つかを図でご覧ください。
Snykのツールは、開発者のセキュリティを可能な限り自動化するための自然な次の一歩です。Sysdigとのパートナーシップや最近のFugue買収を通じて、ランタイムにおけるアプリケーションの保護へと進化を続けています。これらのツールを組み合わせることで、アプリケーションのライフサイクル全体を通じてセキュリティを確保できます。
アプリケーションセキュリティの導入事例
導入事例では、開発者に使いやすいワークフローを通じて、Snykでアプリケーションセキュリティのプロセスとセキュリティ状態を改善した組織の例をご覧いただけます。
「Glovoのセキュリティチームは、Snykの活用により、依存関係とコードにおける重大な脆弱性を78%削減したと報告しています。さらに、平均修正時間を40%短縮し、より安全なコードをより速くリリースできることを実証しました。」
Glovo
AppSecに関するよくある質問
アプリケーションセキュリティライフサイクルとは何ですか？
アプリケーションセキュリティライフサイクルは、ソフトウェア開発ライフサイクル（SDLC）と並行して進みます。従来のセキュリティ手法では、開発の後期、あるいは本番環境で稼働してからアプリケーションを保護しようとしていました。最新の開発手法では、セキュリティ対策をプロセスの早い段階から取り入れます。そのため、セキュリティチームと開発チームは、SDLCの初期段階からランタイム環境に至るまで、セキュリティを組み込む必要があります。
アプリケーションをどのように保護しますか？
アプリケーションのセキュリティは、計画の初期段階から始まります。この段階で脅威モデリングとセキュア・バイ・デザインの原則を取り入れることで、アプリケーションにセキュリティを組み込めます。その後、開発・テスト段階へと続き、スキャンツールを開発者のワークフローに組み込めば、セキュリティテストを自動化できます。アプリケーションの実行に使用するコンテナやインフラストラクチャを開発者が担うケースも増えているため、それらの環境も保護する必要があります。
アプリケーションセキュリティのコントロールとは？
アプリケーションセキュリティのコントロールとは、セキュリティ標準を実施するために設けられる具体的な手順です。セキュリティの階層では、ポリシーによって組織全体の指針を定め、標準ではそのポリシーに基づく具体的なルールを定めます。そして、コントロールによって標準を実践に移します。たとえば、楕円曲線暗号に基づく特定の暗号化アルゴリズムのみを使用するというポリシーを企業が定めるとします。標準では、アプリケーションのどこにそのポリシーを適用するかを定め、コントロールではその実装を（理想的には）自動化します。
アプリケーションデータセキュリティとは何ですか？
アプリケーションデータセキュリティとは、ソフトウェアアプリケーションによって処理・保存される機密性の高い企業情報や顧客データを、不正アクセス、改ざん、削除などの脅威から保護することです。アプリケーションセキュリティ戦略全体を構成する重要な要素です。
アプリケーションセキュリティ、クラウドセキュリティ、ネットワークセキュリティの違いは何ですか？
アプリケーションセキュリティは、ソフトウェアそのもの（コード、ロジック、インターフェース、処理するデータ）を脆弱性や攻撃から守ることに重点を置きます。セキュアコーディング、静的・動的テスト、ランタイム保護、サードパーティ製の依存関係の安全性確認などの取り組みを行います。一方、ネットワークセキュリティはインフラ層を保護します。データの転送、境界防御、ネットワークのセグメンテーション、ファイアウォール、VPN、侵入検知システムなどを通じて、システムやデータへの不正アクセスを防ぎます。
クラウドセキュリティは両方の領域にまたがりますが、インフラ、設定、ID・アクセス管理、コンプライアンスなど、クラウド環境の保護に重点を置きます。マルチテナンシー、設定ミス、クラウドネイティブAPIに固有のリスクに対処します。クラウドにおけるアプリケーションセキュリティはアプリケーション層を対象とする一方、ネットワークセキュリティは仮想ネットワークの保護や、サービスコンポーネント間の安全な通信の徹底にまで及ぶことがあります。
セキュア・バイ・デザインのアーキテクチャの基本原則とは何ですか？
セキュア・バイ・デザインとは、後からセキュリティを付け加えるのではなく、設計の初期段階からシステムの基盤となる特性としてセキュリティを組み込むエンジニアリングの考え方です。攻撃を予測し、侵害が起きても被害を抑えられるようにシステムを設計することを重視し、最小権限、攻撃対象領域の縮小、多層防御、継続的な保証などの原則を適用します。さらに、シンプルさ（KISS）、オープンな設計（セキュリティを隠すことで実現しようとしない）、職務の分離、安全側に倒すデフォルト設定といった実践も、複雑さを抑え、監督を強化することで、システムの堅牢性を高めます。
ゼロトラストはアプリケーションセキュリティにおいてどのような役割を果たしますか？
ゼロトラストとは、「決して信頼せず、常に検証する」という原則に基づくセキュリティモデルです。場所やネットワーク境界にかかわらず、ユーザー、デバイス、アプリケーション間のあらゆるやり取りについて、継続的な認証と認可を求めます。アプリケーションセキュリティに適用すると、厳格で状況に応じた制御を通じてのみ、アプリケーションやAPIへのアクセスを許可し、最小権限ポリシーを徹底するとともに、リアルタイムで監視して異常な挙動を検知します。
また、このモデルは侵害が起こり得ることを前提としているため、マイクロセグメンテーション、通信の暗号化、IAM、継続的な行動分析などのアーキテクチャ戦略を支援します。これらの戦略によって、システム内での侵入者の滞在時間やラテラルムーブメントを抑え、アプリケーションのレジリエンスを高めるとともに、攻撃による潜在的な影響を軽減します。
AppSecの観点から、コンテナとKubernetesワークロードをどのように保護できますか？
コンテナ化されたアプリケーションとKubernetesワークロードを保護するには、多層的な戦略が必要です。まず、デプロイ前にコンテナイメージをスキャンして既知の脆弱性を検出し、イメージ署名を必須にするとともに、CI/CDパイプラインの早い段階でInfrastructure as Code（IaC）のセキュリティチェックを組み込みます。Admission Controller、ロールベースのアクセス制御（RBAC）、ネットワークポリシーなど、Kubernetesネイティブの制御機能を活用して、ワークロードを検証し、アクセスを制御し、Podやサービス間の通信を保護します。
さらに、セキュリティ強化済みのホストOSを使用する、コンテナを必要最小限の権限で実行する、クラスター構成を継続的に再評価するといったベストプラクティスを徹底し、外部に公開された名前空間や過剰な権限を持つロールなどの設定ミスを防ぎます。
CISOがアプリケーションセキュリティの成熟度を測るために追跡すべきKPIや指標は何ですか？
CISOは、リスク低減の進捗と、チーム全体へのAppSecの浸透度の両方を示す指標を確認する必要があります。重要なAppSec KPIには、悪用可能な脆弱性の数、平均修正時間（MTTR）、コンプライアンスフレームワークへの準拠度などがあります。これらはSnykのプラットフォームで追跡・可視化できます。。同様に重要なのが、チームの関与度やカバレッジを示す指標です。たとえば、SAST/DASTを統合したプロジェクトの割合、脆弱性の修正率、開発者によるAppSecツールの導入状況などです。
SnykでDevSecOpsを加速
SnykとAccentureの知見を活用して、アプリケーションの複雑化やAIのハルシネーションに対処し、開発チームとセキュリティチームの連携を促進しましょう。