脆弱性の指摘を1か所に集めて重複を整理するOSS「DefectDojo」を解説

「診断ツールごとに結果が別々の画面にあって、同じ弱点を何度も追いかけている気がする」「どの指摘から手を付けるかを決めるだけで、毎回会議が長くなってしまう」——セキュリティ診断の結果をまとめる立場になった、情報システム担当やセキュリティ担当の方からよく聞く声です。こうした悩みは、道具をもう一つ足せば片づくように見えます。しかし本当の課題は道具の数ではありません。指摘を1か所に集め、重複を整理し、対応の優先順位と担当を決める統制があるかどうかが分かれ目です。この記事では、複数の診断ツールが出した指摘を集約して管理するOSS「DefectDojo」を取り上げ、何をする道具なのか、公開されている勧告をどう読むか、企業が導入前に何を確かめるべきかを、一次情報に基づいて整理します。設置や設定の手順は扱いません。

DefectDojoとは何か。2026年10月時点で確かめられる事実

DefectDojoは、GitHubで公開されているOSSです。READMEでは、開発と運用をまたいでセキュリティを組み込む取り組み（DevSecOps）と、アプリケーションのセキュリティ態勢を把握する管理（ASPM）、そして脆弱性管理を担う道具と説明されています。検査から修正、報告までをひと続きに編成するのが役割で、弱点を見つける工程の後ろ側を支える道具だと言えます。

見る点	確かめられた内容
公開元	GitHubのDefectDojo組織（2018年作成・公開リポジトリ27件）
リポジトリ作成	2015年2月19日
ライセンス	BSDの3条項
スター数	約5000（2026年10月16日時点）
フォーク数	約2000
監視している人	202
コミット数	1万5813
最新リリース	3.4.101（2026年10月14日）
公式サイト	自社のサイトを運営

READMEにはOWASPの旗艦プロジェクトであることを示すバッジがあります。OWASPはウェブの安全を扱う国際的な非営利のコミュニティで、その看板プロジェクトとして育ってきたことが分かります。保守は常任の担当者と複数のモデレーターで行われており、個人の思いつきで始まった道具ではなく、組織的に引き継がれてきたことが読み取れます。

公開されている開発の記録によると、修正は毎週のように積まれ、最新の版は2026年10月に公開されています。活発に保守されている点は、長く使う道具を選ぶときの前向きな材料です。ただし、後の章で見るように、この活発さは機能の追加だけでなく、公開されるセキュリティ勧告の多さにも表れています。

なぜ今、指摘を1か所に集めることが課題になるのか

企業の守りでは、セキュリティ診断の道具が年々増えています。ソースコードの検査、依存部品の検査、公開サーバーの検査、コンテナの構成の検査と、目的ごとに別の道具を使うのが普通になりました。道具が増えるほど、同じ弱点が別の名前で何度も報告されるようになります。

ある道具は「注入の問題」と呼び、別の道具は「入力の検証漏れ」と呼ぶ。同じ部品の同じ弱点でも、報告の形も重大度の付け方も違います。担当者は、どれが同じ弱点なのかを目で突き合わせ、重複を消し、どれから直すかを毎回判断することになります。道具を足すほど、この突き合わせの仕事が増えてしまうのです。指摘が100件を超えてくると、表計算のファイルで追う運用は限界に近づきます。突き合わせを人の記憶と手作業に頼るほど、見落としと属人化が進みます。集約と重複の整理を仕組みに任せる理由は、ここにあります。

ここで効いてくるのが脆弱性管理という考え方です。診断は弱点を見つける工程ですが、見つけた後に対応の優先順位を決め、担当を割り当て、直ったことを確認し、監査に耐える記録を残すところまでが一つの統制です。指摘が各道具の画面に散らばったままだと、この統制が成り立ちません。集約は、この統制を回すための土台になります。散らばった指摘は在庫になり、集めた指摘はじめて管理の対象になるという言い方もできます。

何を集め、どう重複を整理するのか

DefectDojoは、外部の診断ツールが出力した検査結果を取り込みます。READMEによれば、対応する取り込み口の一覧が公式の文書にまとめられており、多数の診断ツールの出力形式に対応しています。自社で使っている道具の結果を、そのままの形式で受け取れる範囲が広いことが、まずの売りです。

取り込んだ結果は、資産と、取り組みの単位で整理されます。製品や組織といったまとまりごとに、いつ、どの検査で、どんな指摘が出たかをひもづけて持ちます。同じ指摘をまとめ上げ、再検査で消えた指摘を閉じる仕組みがあり、これが重複の整理の中心です。

重複の整理は、完全に自動で決まるものではありません。同じ弱点かどうかの判断には、対象の資産、弱点の種類、場所といった手がかりを使いますが、最後に同じものとしてまとめるかを決めるのは運用する人です。道具は候補を並べ、人が確認する、という分担だと捉えておくのが安全です。また、取り込んだ結果には、検査の日時や対象の資産の情報が付きます。いつ時点の在庫なのかが分かることで、古い指摘を今も直っていないものとして数えてしまう取り違えを防げます。いつの情報かが残っていること自体が、管理の質を左右するという点も押さえておきたいところです。

対応の優先順位をどう決めるのか

集約の次に問われるのが、優先順位です。指摘は数百から数千に膨らむことがあり、全部を同じ勢いで直すことはできません。どれから手を付けるかを、記録を残して決められるかが、脆弱性管理の実力になります。

この道具には、重大度や弱点の情報をもとに優先順位づけを助ける仕組みがあります。リスクを受け入れる判断にも期限を付けられ、承認した記録を残せます。直さないと決めたものも、決めた証拠として残す設計になっている点が、監査の場面で効きます。

ただし、優先順位の基準そのものは道具が決めてくれません。どの資産が大事か、どの弱点が自社にとって重いかは、事業の事情で変わります。道具に並べ替えさせた後に、人が事業の観点で順番を直す。この分担を決めておかないと、一覧はあっても対応は進みません。

診断結果を受け取る口の広さと、その注意点

対応する取り込み口の多さは、この道具の分かりやすい強みです。公式の文書には、ソースコードの検査、依存部品の検査、公開サーバーの検査、クラウドの構成の検査など、幅広い道具の結果を取り込めることが示されています。

一方で、取り込み口が多いことは、自社の管理点が多いことでもあります。どの道具の結果を、どの資産に、どの単位で取り込むかは、利用する側が決めて管理する必要があります。取り込みの設定が属人化すると、担当が替わったときに何を取り込んでいるのか分からなくなります。

また、取り込む結果の量が増えるほど、保管する場所と見せる範囲の設計が重要になります。検査結果には、まだ直していない弱点の場所が含まれます。取り込み口を増やす前に、誰がそれを見られるかを決めておく。順番を間違えると、集約がそのまま露出になります。

OSS版と有償版（Pro版）の違い

DefectDojoには、無償で使える公開版（コミュニティ版）と、有償のPro版があります。READMEによれば、Pro版は新しい画面、リスクに基づく脆弱性管理、規模への強さ、外部サービスとの連携、自動のデータ付加、優先順位づけといった点で公開版を上回ります。

統制の観点で特に見逃せないのが認証です。READMEには、外部の認証基盤との連携（シングルサインオン）、ディレクトリとの連携、多要素認証はPro版の機能だと明記されています。公開版では、利用者の管理を自社で作り込む前提になるということです。

見る点	公開版（コミュニティ版）	有償版（Pro版）
画面と操作性	従来の画面	刷新された画面
優先順位づけ	自社で基準を設計	リスクに基づく支援あり
外部の認証基盤との連携	ローカルアカウント中心	シングルサインオンなどに対応
外部サービスとの連携	限定的	コネクタが充実
提供の形	自社で運用	クラウドまたは自社で運用

どちらを選ぶかは、統制の要件で決めます。外部の認証基盤と連携できないと社内の決まりを満たせない組織は、公開版では要件を満たせない可能性があります。機能の差だけでなく、認証と権限の要件で選ぶのが要点です。

公開版を使うときに組織で決めておくこと

公開版は便利な半面、運用の責任が自社に来ます。更新に追随する計画、障害時の復旧、保管するデータの場所、そして利用者の権限の設計を、自社で決めて回す必要があります。

特に権限の設計は、この道具の性格上、軽く見てはいけません。集約した先は、社内の弱点の在庫一覧です。誰がどの製品の指摘を見られるかを、資産の大事さに合わせて分けることが求められます。

運用の体制も決めておきます。取り込む道具と、取り込む頻度、重複をまとめる承認者、リスクを受け入れる権限を持つ人を決め、担当が替わっても続く形で文書に残す。これが、集約を一度きりの作業で終わらせないための条件です。

見張りの仕組みも要ります。誰がいつ、どの指摘を見て、何を変えたのかを記録として残し、定期的に見返します。集約の道具は、使われているかどうかが外から分かりにくいため、更新が止まっていないかを点検する担当を決めておくことが大切です。入れて終わりにせず、区切りを決めて権限と取り込みを見直す運用にしておくと、設計のずれに早く気づけます。

公開済みの勧告20件をどう読むか

ここからは注意点です。GitHubのセキュリティ勧告の欄には、2026年10月16日時点で20件の勧告が公開されています。重大度は中が19件、低が1件です。公開の時期は2026年9月21日から10月12日に集中しており、いずれもこの組織の担当者が公開しています。

勧告の内容には共通する傾向があります。目立つのは、権限の確認漏れです。ある製品にだけ関わるはずの利用者が、別の製品の情報を読めたり、削除の権限がないのに指摘を消せたりする種類の指摘が並びます。「見えるはずのないものが見える」という方向の問題が多いのが特徴です。

個別に見ると、代表的なものがあります。2026年10月12日に公開された勧告は、3.3.0で加わった読み取りの経路を通じて、他の利用者のアカウントの情報が読めてしまう問題を扱っています。詳細では、影響を受ける版は3.3.0以上3.4.0未満、修正版は3.4.0と明記されています。報告は外部の脆弱性報告の窓口を通じて行われ、複数の報告者が同じ問題を独立に見つけています。

ここから読み取れるのは、深刻な問題が放置されているという話ではない、ということです。多くは報告を受け、修正版を出して公開する流れに乗っています。ただし、権限まわりの指摘が繰り返し出ていることは、この道具が多くの利用者と多くの資産を1か所で扱う道具であることの裏返しでもあります。使う側の権限設計が、そのまま安全性に直結します。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを、公開されている事実だけを基に精査しています。OSSをダウンロードしたり動かしたりはしていません。DefectDojoの判定は「注意付き」です。

注意付きとした根拠を挙げます。一つ目は、公開済みのセキュリティ勧告が20件あることです。多くは権限の確認漏れに関わり、中には製品をまたいで情報が見えてしまう種類のものも含まれます。報告から修正、公開までの流れは整っていますが、勧告の数自体は無視できません。

二つ目は、使う版によって安全性が変わる点です。先の勧告では、影響を受ける版と修正版が明示されていました。古い版を使い続けると、修正済みのはずの問題を抱えたまま運用することになります。使うなら修正版に固定し、更新に追随する前提で臨む必要があります。

一方で、判定を重くしすぎない材料もあります。ライセンスはBSDの3条項で、非商用に限るなどの制約はありません。作者は2018年から続く組織のアカウントで、公開リポジトリも複数あります。インストールの段階で自動的に動く処理は、確認できた範囲では見当たりませんでした。

なお、ここで見つからなかったことは安全の保証ではありません。この精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。勧告の内容と、自社の使い方の両方を見て判断してください。

勧告が示す傾向から、運用の注意点を読む

勧告の一覧を並べて読むと、傾向がいくつか見えてきます。まず、権限の確認漏れが多いこと。次に、ある製品の利用者が別の製品の情報に触れてしまう横断的な見え方の問題が多いこと。そして、利用者の情報や操作の記録が想定より広く見える問題が含まれることです。

これらは、攻撃の手順ではなく、守りを設計するうえでの示唆として読むべきものです。この道具は、組織の弱点を1か所に集めるからこそ、権限の境界が破れたときの影響が大きいという性質を持ちます。集約先の権限は、集約元のどの道具よりも厳しく設計する。これが勧告から学べる最初の教訓です。

もう一つ、報告の流れそのものも参考になります。報告は外部の窓口を通じ、常任の担当者が非公開の場で修正を進め、修正版と一緒に公開する形が取られています。報告してくれた人をクレジットする運用も明記されています。弱点の報告を受け止めて直す流れが整っていることは、道具を選ぶうえで前向きな材料です。

さらに、勧告の中には、保存された形で画面に残り、その画面を開いた人が影響を受ける種類のものも含まれます。これは、見る人の権限を狭めるだけでは防ぎきれない種類で、更新に追随することが最も確実な備えになります。

導入を検討するときに確かめること

DefectDojoのような集約の道具は、機能の多さより先に、運用と権限の前提を確かめる必要があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めで確かめられることに絞っています。

この手順の要は、道具を入れる前に、見せる範囲と任せる範囲を決めておくことです。集約は便利さの裏返しで、一覧を1か所に集めるほど、その1か所の価値と危険が同時に大きくなります。

悪用されうるリスク

DefectDojoは守りのための道具で、それ自体が攻撃の道具になるものではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、集約した一覧が、攻撃側にとっての地図になることです。

弱みの場所、まだ直っていない箇所、影響の大きい資産が、1か所に整理されます。ここへの権限が破れれば、攻撃する側は調べる手間を大きく省けます。公開された勧告の多くが権限の確認漏れに関わっていたことは、この危険が絵空事ではないことを示しています。

これは推測ですが、集約した結果を外部のサービスに送って分析する使い方をすると、送り先が新たな漏えいの入口になりうると考えられます。連携先を増やすときは、何をどこまで送るかを決めてからにすべきです。

なお、この道具が実際に攻撃に使われたという報告は、2026年10月16日時点で確認できませんでした。危険は、道具の悪用というより、集めた情報の守り方の不備として現れると考えるのが現実的です。

企業が取るべき対策

DefectDojoを入れるかどうかにかかわらず、脆弱性管理について企業として決めておきたい対策を挙げます。一つ目は、集約の道具を、社内の弱点の台帳として正面から位置づけることです。誰が持ち主で、誰が更新し、誰が監査するかを決めます。

二つ目は、権限の最小化です。見る範囲と操作する範囲を分け、削除や設定の変更は限られた人に絞ります。三つ目は、更新への追随です。公開された勧告と修正版の情報を定期的に確認し、使っている版が修正版から遅れていないかを点検する体制を持ちます。

四つ目は、取り込み元の棚卸しです。どの診断ツールを使い、その結果を誰が管理しているかを一覧にし、使っていない取り込みを閉じます。五つ目は、報告の窓口の確認です。弱点の報告先と対応の約束を把握し、社内の問い合わせ先を決めておきます。対策は、道具を入れてから考えるのではなく、入れる前提として決めておくものです。

集めた結果そのものが機密である

この道具を使ううえで、最も見落とされやすいのが、結果そのものの扱いです。集約した先には、まだ直っていない弱点の場所と、影響の大きい資産の名前が並ぶからです。

ソースコードと同じ水準で、保管、見せる相手、残す期間、外部への共有の可否を決めます。画面の共有や、報告用の出力を外部に送る場面は、情報を持ち出す行為と同じだと捉えます。

監査の記録も整えます。誰がどの指摘を見て、直さないと決めたのかを残すことは、監査の場面でそのまま役に立ちます。守りの道具の結果を守る。この二重の守りまで含めて、脆弱性管理の統制だと考えてください。

具体的には、出力の扱いを決めます。報告用に書き出したファイルは、メールに添付して回すのではなく、見る権限のある人だけが開ける場所に置き、残す期間を過ぎたら消す。こうした決まりを、集約の道具に限らず、社内の弱点の情報すべてに当てはめると、抜けが減ります。

AIに任せる範囲と、人が決める範囲

近年は、AIに指摘の整理や分類を手伝わせる使い方も広がっています。大量の指摘を分類し、似たものをまとめる補助は有用です。ただし、優先順位づけとリスクの受け入れは、AIに決めさせず、人が決めるのが基本です。

AIに任せるなら、なぜその判断をしたのか根拠を書かせ、人が確かめる範囲を先に決めます。そして、やってはいけない向き合い方を挙げておきます。

• 集約した結果を、機密情報として扱わずに共有する
• 誰でもすべての製品の指摘を見られる権限のまま運用する
• 古い版を使い続け、修正版への更新を後回しにする
• AIに優先順位づけとリスクの受け入れまで決めさせる
• 取り込み元の診断ツールを棚卸ししないまま、口だけ増やし続ける
• 報告や修正の流れを確かめず、中身が見えないまま導入する

人が決める範囲ははっきりしています。何を大事な資産とするか、どれから直すか、何を直さないと決めるか、誰に何を見せるか。この四つはAIにも道具にも委ねず、人が決めます。道具に任せてよいのは、決めた範囲で候補を速く並べる部分です。

よくある質問：勧告が多いOSSを導入してよいのか

「公開された勧告が20件あるOSSを、導入してよいのか」という問いには、勧告の中身と対応の流れで答えることになります。多くは修正版が出ており、報告から修正、公開までの流れも整っています。問題は勧告の数そのものより、使う版と権限の設計です。自社が使う版を書き出してから判断するのが確実です。

「公開版で足りるのか」という問いもよくあります。外部の認証基盤との連携や多要素認証が要件になる組織では、公開版では満たせない可能性があります。まず統制の要件を書き出し、それに合う版を選ぶ順番が確実です。

「集約すれば重複は自動で消えるのか」という問いには、いいえ、と答えます。道具は候補をまとめますが、最後に同じ弱点として扱うかを決めるのは人です。自動化の度合いを上げるほど、判断の根拠を残すことが大事になります。

• DefectDojoの機能・版・勧告の件数は、GitHubのリポジトリ・勧告の欄・リリースの記録を2026年10月16日に確かめた範囲に基づきます。内容は変わる可能性があります
• 勧告の影響範囲と修正版は、各勧告の記載に基づきます。すべての勧告を個別に確認したものではありません
• この記事は防御と評価の目線で書いています。設置・設定・実行の手順は扱いません

まとめ

DefectDojoは、複数のセキュリティ診断ツールの結果を1か所に集め、重複を整理して、修正と報告まで追う脆弱性管理のOSSです。OWASPの旗艦プロジェクトとして10年以上続き、幅広い診断ツールの結果を取り込めます。指摘が散らばって対応の順番が決まらない、という悩みに正面から答える道具です。

一方で、公開済みの勧告が20件あり、多くは権限の確認漏れに関わります。使うなら最新の修正版に固定し、権限を最小化し、集めた結果を機密として守る。そのうえで、優先順位とリスクの受け入れは人が決める。集約は守りの入り口であり、集めた後の決め方まで含めて初めて統制になる。これが、この道具との付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。