アプリケーションセキュリティ市場分析

セキュリティ用語集

「セキュリティ」という言葉が様々な文脈で使用されるため、用語を統一して区別することが重要です。

GitLab は、SDLC のすべてのフェーズ（Create、Plan など）にわたってお客様の Secure（セキュア）と Govern（ガバナンス） を支援します。セキュアなアプリケーションを提供するために、お客様は SDLC 全体で GitLab セキュリティコントロールを使用し、検証段階でセキュリティテストを実施します。最終的には、GitLab で計画段階での脆弱性の優先順位付けや本番環境でのセキュリティモニタリングが可能になります。

1. セキュリティコントロールは、SDLC 全体を通じてコードの監査性を GitLab のお客様に提供する GitLab の機能です（SAST/DAST のことではありません）。例として GitHub security を参照してください。これらのコントロールは、監査性とアクセス制御に関するポリシーを必要とする様々な業界規制への準拠を支援します。例:

   • ワークフローを中断することなくセキュリティポリシーを適用
   • 監査用の完全な変更ログ
   • アクセス制御を強化する 2 要素認証（2FA）
   • 検証時の自動化されたセキュリティスキャン より詳細な内容については コンプライアンスページ を参照してください。

2. アプリケーションセキュリティテストは Verify フェーズで使用される GitLab の機能・能力です。SAST、DAST、コンテナスキャン、依存関係スキャンが含まれます。GitLab はソフトウェアコンポジション分析にライセンスコンプライアンスも含めています。

3. GitLab は セキュアなアプリケーション です（GitLab はスケーラブル、オープンなどと同じく形容詞的な表現として使用）。Director of Security の管轄下にあるセキュリティチームは、GitLab ソフトウェアを保護するために人・プロセス・技術を管理します。これには SAST と DAST だけでなく、セキュリティポリシー（Mac の使用など）、独自のセキュリティコントロール、構成、本番環境での GitLab のモニタリング、脆弱性管理などが含まれます。GitLab アプリのセキュリティについて詳しくは about.gitlab.com/security をご覧ください。お客様や見込み客から GitLab アプリのセキュリティに関するアンケートへの回答を求められた場合は、こちらの手順 に従ってください。

アプリケーションセキュリティ市場の概要

サイバーセキュリティは動的な軌道を歩んでいます。従来は守備的なアプローチで境界を防御することに重点が置かれてきました。企業は単純なエンドポイント保護とネットワークセキュリティから始め、「多層防御（Defense in Depth）」のためのツールを積み重ねていきます。今日のセキュリティはより能動的・予測的になり、内部・外部の様々なソースのデータを組み合わせ、ユーザー行動分析と機械学習を適用して疑わしい活動を特定します。

セキュリティ投資も同様の軌道をたどっています。従来、支出の大部分はインフラストラクチャの保護に充てられてきました。2015 年に Gartner のアナリストである Joseph Feiman 氏は、アプリケーションセキュリティに 1 ドル支出するごとに、その他のセキュリティに 23 ドルが支出されていると推定しました。アプリケーションセキュリティが主流の関心事となったのは近年のことですが、状況は変化しつつあります！アプリケーションセキュリティが優先度を増している要因として、以下のような動向があります:

• Heartbleed のように、よく知られた重大なアプリケーションを標的とした攻撃の存在。
• GDPR は、企業が利用するベンダーのリスクを引き受けることを求めています。購入したアプリケーションに含まれる脆弱性がより大きな懸念となります。
• オープンソースコードが当たり前になりつつあります。この 451 の記事 は、悪用可能な脆弱性を持つ小さなコードが、いかに広範な影響をもたらしうるかを説明しています。
• クラウドコンピューティングでは、インフラストラクチャのセキュリティはクラウドプロバイダーの責任となります。企業が保護すべき境界は減り、エンドポイントとアプリケーションへの注力が増えています。
• DevOps の速度には迅速な CI/CD が必要です。従来のゲート型セキュリティはこのモデルに合わず、セキュリティとよりアジャイルなセキュリティプロセスとのトレードオフを迫られます。これが DevSecOps へとつながりましたが、まだ初期段階です。

高度な DevOps またはアプリケーションセキュリティプログラムを持つ企業は、開発者がコードを書いている時点で修正アドバイスを求めています。これは脆弱性を減らすだけでなく、開発者にセキュリティのベストプラクティスをリアルタイムで教えることで開発者を教育する手段でもあります。Fortify と他のいくつかの先進的なアプリセキュリティベンダーがこれを提供しています。

コンプライアンス

コンプライアンスは常に最低共通分母であり、セキュリティの MVC（Minimum Viable Compliance）として捉えられます。事業運営にソフトウェアと技術を依存している企業が、コンプライアンスのみをセキュリティ努力の指針にすることはほとんどありません。

とはいえ、コンプライアンスの重要性は増しています。アプリケーションのスキャンという従来の意味だけでなく、開発プロセスを通じてコードを保護するという観点でも重要性を増しています。コンプライアンスは、誰がいつどのコードを変更したかを示すための監査性に依存します。GitLab は、企業が業界規制に準拠するための監査機能、2 要素認証（2FA）などを提供しています。

コンプライアンスは製品ではなく、ソフトウェアファクトリーの SDLC に組み込まれた機能です。一部の競合他社は、特定の規制に有用な情報を集めて簡素化のためにまとめた コンプライアンスレポート を提供しているかもしれません。GitLab は IPO に向けて自社のコンプライアンスに注力するためにコンプライアンスチームを採用しました。この知識豊富なチームは、GitLab ユーザー向けのコンプライアンスレポートを作成するため、製品チームを指導することもあります。

競合他社

私たちの競争上の視点の焦点は、アプリケーションセキュリティテスト（App Sec）と他の ソフトウェアコンポジション分析機能（SCA）にあります。

アプリケーションセキュリティテストという用語には、Static Application Security Testing（SAST）、Dynamic Application Security Testing（DAST）、依存関係スキャン、コンテナスキャンが含まれます。また、GitLab がまだ提供していない Interactive Application Security Testing（IAST）と Runtime Application Security Protection（RASP）も含まれます。

ソフトウェアコンポジション分析という用語には、Static Application Security Testing（SAST）、依存関係スキャン、コンテナスキャン、ライセンスコンプライアンス、コード品質テストが含まれます。多くの場合、Bill of Materials 機能も含まれますが、これは通常、独立した製品ではなく他の機能の一部です。Forrester などの業界アナリストは、機能をグループ化するために SCA を使用しています。私たちの ソリューション で定義されているように、私たちは SAST とコード品質をソフトウェアコンポジション分析に含めないよう意図的に決定 しています。

競合他社のスコープ

GitLab のセキュア機能を使うのは誰か?

MR パイプラインレポート内 - 開発者

• 担当者に即時に届く
• 自身のコード変更の影響が明確（他者の変更や既存の脆弱性と混在しない）
• コンテキストを変えずにセキュリティ上の欠陥を修正できる

セキュリティダッシュボード内 - セキュリティチーム

• 未解決の脆弱性をプロジェクトまたはグループ単位で表示
• すでに他のコードとマージ済み
• 主な責任はリスクの管理
• リスクを減らし繰り返しのミスを防ぐためのプロセスとプロセス改善のより広い視点
• 長期的視点
• 平均修復時間や傾向を重視

市場セグメントの概要

アプリケーションセキュリティは難しい分野です。サイバーセキュリティのなかでも最も小さな市場セグメントの 1 つで、採用率も最も低い領域です。これは、ネットワークセキュリティやエンドポイント保護などに比べ、人・プロセス・技術の組み合わせに依存する度合いがはるかに大きいためです。高度なプログラムは、コアビジネスのためのカスタムソフトウェアに依存している企業に主に見られます。

高度なアプリケーションセキュリティプログラムを持つ企業

特徴

• 主に大規模な Fortune 2000 企業
• すでに Veracode や Fortify などのツールに投資済み（10 万ドル〜100 万ドル超）。これらにキャリアを賭けている可能性がある。
• 専任のアプリケーションセキュリティ専門家（Application Security Engineers）を擁する
• Threat Intelligence Analyst やセキュリティリサーチャーによる脅威ハンティングにも取り組んでいる可能性がある
• カスタムコードが事業の要
• 多くは金融サービス業界、営利の医療プロバイダーや保険会社
• セキュリティ予算が大きい
• 多くの場合、侵害、ペネトレーションテスト、または監査の不合格後にアプリケーションセキュリティへの予算が確保される。

課題

• 市場投入までの時間
• データ侵害のリスクから評判を守るためのセキュリティと、効率的な SDLC のバランス

価値提案

• 既存のアプリセキュリティツールを補完する形で、開発者のワークフローに組み込まれた GitLab により、市場投入時間を短縮しコストを削減します。
• より多くのセキュリティバグをより早期に発見し、セキュリティアナリストのノイズを減らすことでセキュリティを改善します。
• GitLab セキュリティは、すでに定着している他のアプリセキュリティツールをすぐに置き換えるわけではない可能性が高い。
• 開発チームとセキュリティ手法・知識をより良く統合する機会。

確立されたセキュリティプログラムを持つ企業

特徴

• アプリケーションセキュリティに注力し始めたばかり（スイートスポット）
• あらゆる規模の企業 - 大規模 F2000 でもアプリケーションセキュリティへの注力が不足している可能性あり
• Security Operations Engineer を擁する Security Operations Center（SOC）を持つ場合がある
• セキュリティ予算の大半はエンドポイントセキュリティとネットワークセキュリティに充てられている
• コンプライアンスとアプリケーションセキュリティのためペネトレーションテストに依存
• 最先端の場合は Web Application Firewall（WAF）を持つこともある
• 脅威検知よりもコンプライアンスに注力している場合が多い - Compliance Analyst、Risk Management
• 自社開発のコードがそれほど多くない場合がある
• 開発者は統合や Web フロントエンドに注力している可能性が高い

課題

• リソース制約
• アプリケーションセキュリティの専門知識。

価値提案

• 低コストで、すでに使用しているビルド・デプロイツールにアプリセキュリティを統合する手段を提供し、統合のコストと労力を回避できます。製品が軽量であることに懸念を抱くかもしれませんが、より高価な専用アプリセキュリティツールの代替として試す可能性があります。

セキュリティへの注力が最小限の企業

特徴

• SMB、スタートアップ
• 1〜2 人のセキュリティジェネラリスト、または IT 運用担当者がいる程度
• アプリケーションセキュリティプログラムなし、優先度はエンドポイントセキュリティとネットワーク（クラウド中心でない場合）
• コンプライアンスとアプリケーションセキュリティのためペネトレーションテストに依存
• 規制要件への準拠を満たすための MVC に注力（個人識別データに対する GDPR、クレジットカードに対する PCI、医療に対する HIPAA など）
• アプリケーションセキュリティテストを実施しているとチェックボックスを満たしたい
• セキュアコーディングの改善やプロセス改善への投資は予定していない。
• セキュリティ調査結果を理解できず、優先順位付けと修復に支援が必要な場合がある。

課題

• リソース制約
• セキュリティ専門知識の不足

価値提案

• GitLab は、セキュリティテストのコンプライアンスチェックボックスを満たすのに役立ち、開発プロセスと統合されているため追加の作業は発生しません。

ページのソースコードを見る - ページの編集 - please contribute.