攻撃者に見つけられる前に、
AIで、こちらが見つける。
脆弱性を「見つける」コストは、AIによって急落しました。
それは守る側だけでなく、攻撃する側にとっても同じです。
最新の高精度AIで貴社のコードと構成を読み切り、
見つかった穴をどう直すか、いくらかかるかまで含めて提出します。
- DETECT 検出 AIがコードと構成を読み切る
- VERIFY 検証 人が再現性を確かめる
- REMEDIATE 対策 直し方と費用まで出す
NEWS
AIの脆弱性発見能力は、すでに人間の大半を超えた。
-
AIが「最も熟練した者を除けばあらゆる人間より優れたレベル」に到達
AIモデルは、ソフトウェアの脆弱性を発見し悪用する能力において、最も熟練した一部の人間を除くすべての人間を上回る水準に達した。
限定提供のモデル「Claude Mythos Preview」により、主要なOS・Webブラウザのすべてから高深刻度の脆弱性を発見。OpenBSDで27年間、FFmpegで16年間見過ごされてきた欠陥も含まれていました。
VIEW_SOURCE -
AIミュトスで脆弱性1万件超発見 アンソロピック「企業は早く修正を」
企業はソフトの修正対応を早める必要がある。
限定提供を受けた約50社での利用で、危険度の高い脆弱性が1万件を超えて検出されたと報じられました。見つかる量に、修正が追いついていません。
VIEW_SOURCE -
攻撃手法の開発成功が、2回から181回へ
セキュリティー訓練を受けていないエンジニアが使っても、一晩のうちに弱点を見つけ出して翌朝には攻撃手段が完成していた。
従来モデルでは数百回試して2回しか成功しなかった攻撃手法の開発が、181回成功したと報じられています。日本も2026年6月2日にアクセス権を取得し、15か国以上・150を超える組織が防御目的で利用しています。
VIEW_SOURCE
上記は、業界で何が起きているかを示すために報道を引用したものです。これらのモデルは防御目的で一部の組織にのみ限定提供されており、当社が診断に使用するものではありません。重要なのは、高い能力を持つAIが短時間で脆弱性を見つけ出せるという状況が、すでに前提になったこと。そしてその能力は、守る側だけでなく攻める側にも同じように届くという事実です。
ISSUE
見つけられるのが先か、見つけるのが先か。
-
01
「見つけるコスト」が、両側で下がった
コードを読み切って弱点を探す作業は、攻撃者にとっても以前ほど重い仕事ではなくなりました。
守る側だけが従来の頻度・従来の深さで点検を続ければ、差は開いていく一方です。 -
02
自社のコードを、最後まで読んだ人がいない
外注で作った部分、退職者が書いた部分、AIに書かせた部分。
動いているという理由だけで、誰も中身を確認しないまま本番に残り続けているコードがあります。 -
03
見つかっても、直せない
脆弱性は、見つけるより直すほうが難しい。どれから手を付けるか、誰が直すか、いくらかかるかが決まらないまま、検出結果の一覧だけが積み上がっていきます。
AUDIT PROCESS
AIが出した結果を、そのまま渡さない。
AIは、大量の可能性を短時間で洗い出します。ただしそこには、実際には成立しない指摘も混ざります。
検出結果をそのまま渡されても、現場は動けません。
AIで広く洗い、人で絞り込む。この2段構えが、診断の品質を決めます。
-
STEP 01
SCOPE DESIGN
診断範囲を決める
何を、どこまで診るかを先に確定します。対象のリポジトリ・ドメイン・環境、触ってよい範囲と触ってはいけない範囲、実施する時間帯。
ここで書面による許諾と範囲の合意を取り交わしてから着手します。範囲の曖昧な診断は行いません。- やること
- 対象資産の洗い出し / 許諾範囲の合意 / NDA・実施条件の取り交わし
- 成果物
- 診断計画書（対象・手法・実施期間・除外条件）
- わかること
- 自社に、診るべき資産がどれだけあるか
-
STEP 02
AI ANALYSIS
AIが読み切る
最新の高精度AIに、コード構造の把握・攻撃経路の洗い出し・データの流れの追跡を分担させます。
1ファイル単位ではなく、ファイルやモジュールをまたいだ処理の連鎖として読ませることで、目視のレビューでは見落とされやすい経路まで拾い上げます。- やること
- コード構造の把握 / 攻撃経路の列挙 / データフロー解析 / 設定・権限の確認
- 成果物
- 検出候補の一覧（深刻度・根拠・該当箇所つき）
- わかること
- どこに穴が空いている可能性があるか
-
STEP 03
VERIFICATION
人が確かめる
検出候補を人が一件ずつ確認します。実際に成立するのか、成立するならどこまで到達できるのか。
再現しなかったものは落とし、再現したものだけを報告に残します。「たぶん危ない」を渡さないための工程です。- やること
- 再現性の確認 / 誤検知の除去 / 影響範囲の特定 / 深刻度の確定
- 成果物
- 再現手順つきの確定リスト
- わかること
- 実際に突かれうるのは、どれか
-
STEP 04
REPORT & ESTIMATE
直し方と費用まで出す
検出結果に、対策方針・想定工数・優先順位を添えて提出します。
報告会では、開発を担当される方へ修正方針を直接説明します。読んだその日から動ける状態で渡すことが、この工程の目的です。- やること
- レポート作成 / 優先順位づけ / 対策方針の設計 / 報告会の実施
- 成果物
- 診断レポート / 対策方針書 / 修正のお見積り
- わかること
- 何から、誰が、いくらで直すか
SCOPE
何を診るか。
-
SOURCE CODE
ソースコード診断
リポジトリを対象に、認証・認可、入力処理、外部連携、秘密情報の扱いを確認します。稼働環境を用意できない場合でも実施できます。
- 認可制御の不備
- 入力値処理の欠陥
- 認証情報のハードコード
- 依存ライブラリの既知脆弱性
-
WEB APPLICATION
Webアプリケーション診断
稼働しているアプリケーションとAPIに対して、許諾された範囲で挙動を確認します。本番影響を避けるため、ステージング環境での実施を基本とします。
- 認証・セッション管理
- 権限昇格の可否
- APIの認可漏れ
- エラー時の情報露出
-
CLOUD & ACCESS
クラウド構成・権限診断
クラウド環境の設定と権限設計を確認します。コードが正しく書かれていても、構成の緩さがそのまま入口になることがあります。
- 過剰な権限付与
- 公開設定の誤り
- 鍵・認証情報の管理
- ログと監査記録の有無
-
AI AGENT
AIエージェント・LLMアプリ診断
生成AIを組み込んだアプリケーション特有のリスクを確認します。従来のWeb診断の観点だけでは拾えない領域です。OWASPが公開しているLLMアプリケーション向けのリスク分類も参照します。
- プロンプトインジェクション
- エージェントに渡している権限の広さ
- 外部データ経由の指示混入
- 出力をそのまま実行していないか
REPORT
読んで、そのまま動ける報告書を。
検出結果の羅列ではなく、社内でそのまま回せる形で提出します。
以下は体裁を示すサンプルです。実在の企業・システム・診断結果ではありません。
- CRITICAL 2
- HIGH 5
- MEDIUM 11
- LOW 23
< SCROLL_横にスクロールできます
| ID | 深刻度 | 分類 | 対象 | 想定工数 |
|---|---|---|---|---|
| F-001 | CRITICAL | 認可制御の不備（CWE-639） | 会員情報取得API | 0.5人日 |
| F-002 | CRITICAL | 認証情報のハードコード（CWE-798） | バッチ処理 | 0.5人日 |
| F-003 | HIGH | SQLインジェクション（CWE-89） | 検索機能 | 1.0人日 |
| F-004 | HIGH | サーバサイドリクエストフォージェリ（CWE-918） | 外部連携処理 | 1.5人日 |
| F-005 | MEDIUM | クロスサイトスクリプティング（CWE-79） | 入力確認画面 | 0.5人日 |
他ユーザーの会員情報を参照できる（認可制御の不備）
- 検出内容
- リクエストに含まれる会員IDを別の値に差し替えると、ログイン中の本人以外の登録情報が返却される。
- 影響
- 認証さえ通れば、全会員の氏名・連絡先・購入履歴が第三者から参照可能。個人情報の大量流出につながる。
- 再現性
- あり（再現手順を別紙に記載 / 認証済みセッションが必要）
- 推奨する対策
- リクエスト値ではなくセッション上の会員IDを基準に、リソース所有者との一致をサーバ側で必須チェックする。同じ構造の他エンドポイントにも横展開する。
- 想定工数
- 0.5人日（修正 + 回帰テスト）
上記はレポートの体裁を示すためのサンプルです。実際のレポートには、検出ごとの再現手順・影響範囲・推奨する修正方法・想定工数を記載します。そのまま悪用できる形の攻撃コードは納品物に含めません。
REMEDIATION
見つけて終わり、にしない。
診断は、直して初めて意味を持ちます。
検出結果を渡すところで終わらせず、直すための計画と費用までを同じ窓口で出します。
-
PLAN
修正方針の設計
検出ごとに、どう直すのが妥当かを設計します。その場しのぎの塞ぎ方ではなく、同じ種類の欠陥が再発しない直し方を提示します。
-
IMPLEMENT
修正の実装・伴走
貴社の開発チームが直す場合は、レビューと相談役として伴走します。手が足りない場合は、OUTLIERが実装まで引き受けます。
-
RE-AUDIT
再診断
修正後、同じ手法で再度確認します。直ったこと、そして修正によって別の穴が空いていないことを確かめます。
お見積りは、この3点で決まります
- 深刻度と件数 全件を直すのか、CRITICAL・HIGHに絞るのか。
- 対応方式 貴社が直すのか、OUTLIERが実装まで行うのか。
- 再診断の範囲 修正箇所のみか、周辺を含めて再度診るか。
診断そのものの費用も、対象の規模と手法によって設計します。まずは対象システムの構成をお聞かせください。概算をお出しします。
HOW WE WORK
前提として、守ること。
-
許諾のない診断は、行いません
診断は、対象の所有者・管理者の同意があって初めて成立します。
対象範囲・実施期間・手法を書面で合意してから着手します。他社が運用するシステムを含む場合は、その運用元の許諾も確認します。 -
AIの出力を、そのまま渡しません
AIが出した検出候補は、人が再現を確認したうえで報告に残します。
再現できなかったものは落とします。件数を多く見せることが目的ではありません。 -
攻撃コードは、納品物に含めません
レポートには再現手順と影響範囲を記載しますが、そのまま悪用できる形のコードは含めません。
取り扱いに配慮が必要な内容は、受け渡し方法を個別にご相談します。 -
10年の機械学習実績が土台
2016年のディープラーニング黎明期からAIの社会実装に携わってきました。
AIの出力をどこまで信用し、どこから疑うべきか。その判断基準が、診断の品質を支えます。
FLOW
進め方
-
STEP 00
ご相談・現状の確認
対象システムの構成と、いま不安に感じている点を伺います。
-
STEP 01
診断範囲の合意
対象・手法・実施期間・除外条件を確定し、NDAと実施許諾を取り交わします。
-
STEP 02
AI解析
最新の高精度AIで、コードと構成を横断的に洗い出します。
-
STEP 03
手動検証
検出候補の再現性を人が確認し、誤検知を除去します。
-
STEP 04
レポート提出・報告会
優先順位と対策方針をつけて提出し、開発を担当される方へ直接説明します。
-
STEP 05
対策・再診断（任意）
修正の伴走または実装を行い、修正後に同じ手法で再度確認します。
期間・体制・費用は、対象の規模と手法によって設計します。まずは現状をお聞かせください。