よくある利用事例

この記事は、DefectDojo, Inc. が2025年2月に開催したOffice Hours「よくある利用事例への対応」を基にしています。

利用事例の例#

DefectDojoは、セキュリティチームの規模、ITの複雑さ、レポート量にかかわらず、あらゆるセキュリティ実装に対応できるように設計されています。以下の事例は、皆様ご自身のニーズを検討するための出発点として紹介するものですが、いずれも私たちのコミュニティやDefectDojo Proチームによる実際の事例に基づいています。

大企業の場合:RBACとエンゲージメント#

「BigCorp」は、最高情報セキュリティ責任者(CISO)と、AppSecを含む一元化されたITセキュリティ部門を持つ大規模な多国籍企業です。

BigCorpにおけるセキュリティは高度に一元化されています。一部の業務は、事業部門情報セキュリティ責任者(BISO)に委任されています。

BigCorpの主な関心事は次のとおりです。

• 組織内のすべての事業部門で一貫したテスト手法を設定し、維持すること
• コンプライアンス要件を満たし、規制上の問題を回避すること

テストモデル#

BigCorpは、多くのソースからセキュリティデータを扱っています。

• SAST、SCA、シークレットスキャンツールを自動的に実行するCI/CDジョブ
• 特定の製品に対するサードパーティによるペネトレーションテスト
• 特定の製品に対するPCIコンプライアンス監査

これらのレポートカテゴリーはそれぞれ個別のエンゲージメントで扱うことができ、DefectDojo内ではスキャンの種類ごとに個別のテストを設定できます。

• 製品にCI/CDパイプラインがある場合、そのパイプラインからのすべての結果を、単一のオープンエンドなエンゲージメントに継続的にインポートできます。使用する各ツールはCI/CDエンゲージメント内に個別のテストを作成し、新しいデータで継続的に更新できます。
  (再インポートについてのガイドをご覧ください)
• 各ペネトレーションテストの取り組みごとに、すべての結果を格納する個別のエンゲージメントを作成できます。例:「Q1 Pen Test 2024」「Q2 Pen Test 2024」など。
• BigCorpはおそらく、本番の監査に備えて独自の模擬PCI監査を実施したいと考えるでしょう。これらの監査結果も、個別のエンゲージメントとして保存できます。

RBACモデル#

• 各BISOには、担当する事業部門(製品タイプ)ごとにリーダーアクセス権が割り当てられています。
• 各製品オーナーには、自分が担当する製品に対するライターアクセス権があります。製品オーナーは、自分の製品内でメモを残したり、CI/CDパイプラインを設定したり、リスク受容を作成したりするなど、他の機能を使ってDefectDojoを操作できます。
• BigCorpの開発者はDefectDojoに一切アクセスできませんし、その必要もありません。製品オーナーは、関連する脆弱性情報をすべて含んだJiraチケットをDefectDojoから直接プッシュできます。開発者はすでにJiraを使用しているため、他の開発タスクと変わらない方法で修正作業を追跡できます。

組み込みシステムの場合:バージョン管理されたレポート#

Cyber Roboticsは、組み込みソフトウェアシステムを搭載した製造用ハードウェアを販売する企業です。同社には、製品全体とサイバーセキュリティ全体を統括する最高製品責任者(CPO)がいます。

BigCorpほど多様なセキュリティ情報を管理しているわけではありませんが、重大な検出事項に積極的に対応できるよう、セキュリティ情報を適切に文脈付けすることが依然として不可欠です。

Cyber Roboticsの主な関心事:

• 製品ラインは限られていますが、各製品には適切にカタログ化する必要のある多数のバージョンが存在します。
• 製品のメンテナンスは複雑でコストも高いため、不要な作業は避ける必要があります。

テストモデル#

Cyber Roboticsは、すべての組み込みシステムに対して標準化されたテストプロセスを持っています。

• CI/CD、SAST、SCAテストの実施
• セキュリティ管理策のレビュー
• ネットワークスキャン
• サードパーティによるコードレビュー

しかし、ソフトウェアの各バージョンは独立しているため、整理すべき大量のデータが必然的に発生し、その多くは特定のコンテキスト(つまり、実行している特定のソフトウェアバージョン)でのみ有用です。

Cyber Roboticsは、単一の製品ラインを表す製品タイプと、バージョンごとの個別の製品を使用することで、この問題を解決できます。これにより、特定の脆弱性がどの製品に関連しているかを詳細に絞り込むことができます。

ソフトウェアバージョンをエンゲージメントではなく製品に割り当てることで、必要に応じて特定のソフトウェアバージョンへのアクセスを制限できます。フィールド技術者やサポート担当者には、製品ライン全体へのアクセス権を与えることなく、単一バージョンのソフトウェアへのアクセス権のみを付与できます。

RBACモデル#

ここでのAppSecチームには、操作レベルを管理するグローバルロールが割り当てられています。

• CPOは、BigCorpのCISOと同様に、DefectDojoに対するグローバルリーダーアクセス権を持っています。
• 各製品オーナーは、DefectDojo内のすべての製品に対するグローバルリーダーアクセス権と、自分が所有する製品に対するライターアクセス権を持っています。

サポート側では:

• サポート担当者には、保守を担当する特定の製品に対して一時的にリーダーアクセス権が付与されますが、DefectDojoの全データにはアクセスできません。

動的なIT環境とマイクロサービスの場合:クラウドサービス企業#

Kate’s Cloud Serviceは、Kubernetes、マイクロサービス、自動化を活用した急速に変化する環境を運用しています。Kate’s Cloud Serviceには、クラウドセキュリティの問題を統括するVP of Cloudがいます。また、提供するソフトウェア開発を管理するCISOもいますが、この例では特にクラウドセキュリティに関する懸念事項に焦点を当てます。

Kate’s Cloud Serviceはレポート作成をすべて自動化しており、レポートが生成されるとすぐにデータをDefectDojoに取り込みます。

Kate’s Cloud Serviceの主な関心事:

• マルチテナントのクラウドセキュリティを管理し、共有サービスの提供を可能にしながら顧客間の干渉を防止すること。
• クラウド環境の急速な変化に対応すること。

共有サービスのタグ付け#

Kateのモデルには、他の製品に影響を及ぼしうる共有サービスが多数含まれているため、チームは製品にタグを付けて、どのクラウド提供サービスがそれらのサービスに依存しているかを示しています。これにより、共有サービスに関する問題を製品横断でフィルタリングし、関連チームに報告できます。これらの共有サービスはそれぞれ、主要なクラウド提供サービスとは区別された単一の製品タイプにまとめられています。

会社が急速に成長し、テックリードが頻繁に交代するため、Kateはタグを使用して各クラウド製品を現在担当しているテックリードを追跡でき、DefectDojoシステムを常に手動で更新する必要がなくなります。これらのテックリードとの紐付けは、DefectDojoの外部にあるサービスによって追跡されており、インポートパイプラインを管理したり、DefectDojo APIを呼び出したりすることができます。

タグ付けの詳細については、タグについてのガイドをご覧ください。

RBACモデル#

セキュリティ/コンプライアンス側では:

• DefectDojoを所有する製品セキュリティチームは、システム全体に対する管理者アクセス権を持っています。
• VP of Cloud配下のアナリストには、システム全体に対する読み取り専用アクセス権が付与されており、VPがさまざまなクラウド提供サービスのセキュリティを評価するために必要なレポートやメトリクスを生成できます。

開発側では:

• 各クラウド製品(コンピュート、ストレージ、共有サービスなど)のテックリードは、自分が担当する特定のクラウド製品に関するセキュリティ結果をトリアージするために、割り当てられた製品に対するメンテナーアクセス権を持っています。彼らは自分の製品内で検出事項をレビューして対応を行い、検出事項データを大幅に再編成することもできます。
• 特定の製品に携わる開発者には、自分が作業している製品に対するライターアクセス権が付与されており、検出事項にコメントしたり、ピアレビューを依頼したり、リスク受容を作成したりすることができます。

新規買収先のオンボーディングの場合:SaaSy Software#

SaaSy softwareは、他のソフトウェア企業を頻繁に買収する急成長中の企業です。新しい企業を買収するたびに、品質エンジニアリング担当ディレクターとAppSecチームは、突然多数の新しいコードリポジトリ、開発者、プロセスを管理することになります。彼らのDefectDojoモデルにより、できるだけ早く状況を把握できるようになっています。

SaaSy Softwareの主な関心事:

• SOC2などのコンプライアンスプログラムを維持しながら、公になるセキュリティ問題を回避すること。
• 新規製品からのツールやプロセスを自信を持ってオンボーディングできること。
• 本番環境と開発中のブランチの両方で脆弱性を報告・分類できること。

テストモデル#

SaaSyでのテストは、標準化されたツールの使用よりも大まかな方針に重点を置いています。これは、買収先ごとにAppSecの独自のツールやプロセスを持っているためです。SaaSyは、内部評価(CI/CD、DAST、コンテナスキャン、脅威モデリング)と外部評価(サードパーティによるペネトレーションテスト、コンプライアンス監査)の両方を実施する必要があります。

新しいアプリケーションのオンボーディングを支援するため、SaaSy softwareはデータモデルに対する標準的なアプローチを採用しています。SaaSyは新しいアプリケーションをオンボーディングするたびに、そのアプリ用の新しい製品タイプを作成し、それを構成するリポジトリ(フロントエンド、バックエンドAPIなど)ごとにサブ製品を作成します。

これらの各製品は、メインブランチ用に1つ、開発中の各ブランチ用に1つというように、さらにエンゲージメントに細分化されます。これらのエンゲージメント内のテストは、テストの取り組みを分類するために使用されます。開発ブランチには、CI/CDおよびSCAスキャンの結果を保存する個別のテストがあります。メインブランチにも同様のテストがありますが、それに加えて手動コードレビューと脅威モデルのレポートを保存するテストも追加されています。

これらのテストはすべてオープンエンドであり、再インポートを使用して定期的に更新できます。重複排除はエンゲージメントレベルでのみ処理されるため、あるコードブランチの検出事項が別のブランチの検出事項をクローズしてしまうことを防ぎます。

このモデルを一貫して適用することで、SaaSyは新たに買収するソフトウェアにも適用できるモデルを手に入れ、AppSecチームはコンプライアンスを確保するためのデータ監視を迅速に開始できます。

RBACモデル#

セキュリティ/コンプライアンス側では:

• SaaSy softwareのAppSecチームがDefectDojoを所有しており、ソフトウェアに対する完全な管理者アクセス権を持っています。
• QEおよびコンプライアンスチームは、必要に応じてレポートを取得したりデータを詳しく調べたりできるよう、システム全体に対する読み取り専用アクセス権を持っています。

開発側では:

• 各製品オーナーは、DefectDojo内で自分が所有する製品に対するライターアクセス権を持っており、リスク受容を作成したり、その製品のメトリクスを閲覧したりできます。
• 開発者は、自分が携わる各製品に対して読み取り専用アクセス権を持っています。修正しようとしている検出事項や問題について、ピアレビューを依頼することができます。