外部からの検査は
表層で止まるShallow detection
- 外からURLを手当たり次第に叩く検査は、どこに入口があり、どこで認証しているかを知らないまま当てにいきます。
- 問題が見つかっても「どのファイルの何行目か」は、人が追い直すことになります。
- 変更系メソッドや認証付きの経路には、そもそも届きません。
AI Security Solution / cuonology series
From finding
to fix.脆弱性対応を、検知で終わらせない
脆弱性が見つかったあと、誰が、いつ、どこを直すのか。そこが決まらないまま、指摘だけが積み上がっていきます。cuonology securityは、その「見つけたあと」を仕組みにするソリューションです。
- 01取得GET FINDINGS
- 02判定ROUTE
- 03優先度P1 — P4
- 04起票ISSUE
- 05書き戻しSYNC
- 06回収CLOSE
- 07修正PRMERGE
00Background
The ground moved脆弱性をめぐる前提の変化
AIは攻撃側のコストを下げ、守る側に求められる水準を押し上げました。「まだ見つかっていないから安全」という前提は、もう成り立ちません。
発見も攻撃も、誰でもできる時代になりました。AIは公開コード・設定・公開資産を読み、脆弱性の発見と分析を自動化します。弱点の公表から攻撃コードの出回りまでの時間は数日から数時間へと短縮され、攻撃の技術的障壁とコストは大きく下がりました。だから守る側も、人手のトリアージではなく、仕組みで速度を上げる必要があります。
SHIFT 01
発見が容易になる
AIが公開コード・設定・公開資産を読み、脆弱性の発見と分析を自動化します。弱点の公表から攻撃コードの出回りまでが、数日から数時間になります。
SHIFT 02
攻撃が簡易になる
偵察・エクスプロイト生成・フィッシング文面をAIが代行し、攻撃の技術的障壁とコストが低下します。目立たないシステムや中小規模の組織も等しく標的になります。
SHIFT 03
守る水準が上がる
主要システムだけでなく、アプリ・インフラ・設定・依存・ログを含むシステム全般を強固にする必要があり、人手のトリアージと対応では追い付きません。
REQ.01
先回りの
脆弱性検査
外部診断を待たず、自ら検査する
REQ.02
システム全般の
防御
設定・依存・アプリ・ログまで
REQ.03
検知性能の
向上
検知源を足しても運用が回る形に
REQ.04
検知から修正までの
高速化
cuonology securityが担う領域
01The gap
Where it breaks従来の対応に残っていた3つの穴
検知の手段は、AWS側で大きく充実しました。残っていたのは「検知の深さ」「検知後の人手」「修正先のずれ」です。
外部からの検査は
検知後の対応が
一番人手を食うManual triage
- 設定の不備、ソフトウェアの弱点、不審な動きの警告が、毎日のように積み上がります。
- どれを誰がいつ直すか（優先度・起票・追跡・解消確認）は、手作業のままです。
- 放置と二重対応が同時に起き、全体像はSecurity Hubの画面を眺めるしかありません。
検知された場所と
直す場所がずれるFix location
- インフラ設定の警告はアプリのアカウントに出ますが、直すのはインフラの設定ファイル側です。
- アプリのソフトウェアの弱点はリポジトリで直しますが、インフラの設定ファイル側には関係がありません。
- 「起票先」と「修正先」が混ざり、担当が宙に浮きます。
TWO
PRINCIPLES
PRINCIPLES
i.
コードを知った状態で深く検査する
GitHubにあるコードからルート・認証・入力の到達点を読んだうえで、攻撃者と同じ視点で実際に試す検査を行います。見つかった問題は「どのファイルの何行目か」まで特定できるため、「見つけた場所」と「直す場所」が一致します。
ii.
検知はAWSに一任し、検知後の対応に集中する
検知器を自作せず、Security Hubを唯一のバスにします。取得から回収・可視化までの「検知後」の工程を無人で回すことに、開発リソースを寄せています。
02Mechanism
One pipeline検知から修正PRまでを同じパイプラインで
AWSが検知し、cuonology securityが判断して起票し、GitHubで直します。7つの工程を1本のパイプラインにまとめ、セキュリティ担当者は判断とレビューに集中できる状態をつくります。
Architecture / detect → triage → fix検知はAWS、判断と起票は cuonology security、修正はGitHub
Detect / AWSAWSが担う「検知」
- Security Hub設定
- GuardDutyTHREAT
- Inspector弱点
- IAM Access AnalyzerIAM
- Security LakeLOG / OCSF
- その他の検知源共通形式
検知器は作りません。すでにある検知を、そのまま使います。
Triage / cuonology securityプラグインが担う「検知後の対応」
- 01取得機械
- 02判定（起票先・修正先）機械
- 03優先度と根拠機械＋AI
- 04Issue起票AI＋GitHub
- 05Security Hubへ書き戻し機械
- 06解消したIssueの回収機械
- 07可視化・レポート機械
判断の根拠が残り、誰が実行しても同じ基準で動きます。
Fix / GitHub開発フローの中で「修正」
- Issue（担当・期限つき）TICKET
- 修正PRREVIEW
- Issue駆動の実装支援AUTO
- 完了印による成否の機械判定VERIFY
- インフラ設定側の修正設定
警告もコードも、Cuon側には持ち出しません。
NO DETECTOR BUILT
検知器を足すのではなく、すでにある検知（AWS）とすでにある開発フロー（Issue → PR）の間を埋めます。
IN YOUR ENVIRONMENT
ソリューションはお客様のAWS / GitHub環境上で稼働し、リポジトリの内容をCuonに送信しません。
ONE SOURCE OF TRUTH
件数の正本はSecurity Hubです。修正済み・未対応・放置をHTML 1枚のレポートに集約します。
※ 構成は提供プランにより異なります。対応するAWSサービス・リージョン・権限範囲は導入時に個別に設計します。
03Strengths
Six differences「検知して終わり」にしないための6つの設計
新しい監視の仕組みを増やすのではなく、すでにある検知の仕組みと、すでにある開発の進め方の間を、コードを知った状態でつなぐ。それが cuonology securityの立ち位置です。
01
警告の集約先を、1つに決める
各チームが見に行くのは、自社アカウントの「セキュリティ警告の一覧」だけです。設定の不備も、ソフトウェアの弱点も、不審な動きも、検査の結果も、すべて同じ一覧に集まります。どのシステムがどの契約・アカウントのものかという対応表を持たなくて済み、新しい検知の仕組みを足しても、そのまま同じ流れに乗ります。
02
チケットを切る場所と、直す場所を分ける
警告はそのシステムを担当するチームにチケットとして渡し、実際に直すのがインフラの設定ファイル側であれば、そう指定しておきます。「誰の持ち物か」と「どこを直すか」を混ぜないので、チケットが宙に浮かず、担当が決まらないまま放置されることがありません。
03
機械が決めること、AIが書くことを分ける
集める・振り分ける・記録する・集計する、といった手順は、すべてプログラムが決まったとおりに実行します。AIが担うのは優先度の理由づけと文章を書くところだけです。生のログや個人情報、パスワードはAIに渡しません。誰が実行しても同じ結果になり、判断の理由も後からたどれます。
04
中身を知ったうえで、外から攻撃を試す
これまでの外部診断は、URLを手当たり次第に叩くものでした。cuonology securityは、先にソースコードを読んで「どこに入口があり、どこで認証し、どこが危ないか」を把握してから検査します。見つかった問題は「どのファイルの何行目か」まで特定でき、設定の不備やソフトウェアの弱点と同じ基準で優先度を付けられます。
05
チケットから修正まで、途切れさせない
警告の検知から、チケット作成、優先度付け、修正案の用意までを同じ流れで完結させます。自動で直せる範囲はあらかじめ絞り、影響が読み切れるものだけを対象とします。最後の確認と承認は、必ず人が行います。
06
人が見張らなくても、回る仕組み
毎日決まった時刻に自動で動き、重要なものは1件ずつチケットに、軽いものはまとめて1件にします。同じ警告が続くときは「もう対応は要らないのでは」と提案し、直ったものは自動で閉じます。作業の抜け道を塞ぐ仕組みも入っているので、放置も暴走も起きにくい運用になります。
04Before the attack
Read the code, then attack攻撃される前に内側から弱点を探す
これまでの外部診断は、外からURLを手当たり次第に叩くものでした。cuonology securityは、先にソースコードを読み、「どこに入口があり、どこで認証し、どこが危ないか」を把握してから検査します。見つかった問題は「どのファイルの何行目か」まで特定でき、設定の不備やソフトウェアの弱点と同じ基準で優先度を付けられます。
STEP 01
コードを読む
画面やAPIの入口をすべて洗い出し、攻撃されうる箇所を5つの観点（不正な命令の混入／表示の乗っ取り／認証のすり抜け／機密情報の露出／外部への不正な通信）で列挙します。
STEP 02
検査の設計図をつくる
洗い出した入口から、実際に試す攻撃のシナリオを自動で組み立てます。各シナリオは「どのファイルの何行目か」を保持します。データを書き換える操作は、明示的に許可したものだけを対象にします。
STEP 03
攻撃を試す
承認済みの検証環境に対して、2種類の検査ツールを必ず両方実行します。対象のサーバーを限定し、システムを壊しうる操作は除外する仕組みを、プログラム側で強制します。
STEP 04
警告を一箇所に集める
結果を社内の共通フォーマットに変換し、セキュリティ警告の一覧に書き戻します。設定の不備やソフトウェアの弱点と同じ並びに載るので、優先度付けも同じ基準になります。
STEP 05
直す場所を特定する
見つかった問題を「どのファイルの何行目か」に結びつけ、同じ書き方をしている他の箇所も合わせて洗い出します。修正の方向性まで示し、実際の修正は開発チームの流れで行います。
観点
従来の外部診断
cuonology securityの事前検査
検査対象の把握
URLをたどって、入口を推測する
コードから入口の一覧を作成。取りこぼしは食い違いの警告で検知
問題の場所の特定
人がログから該当箇所を探す
最初から「どのファイルの何行目か」を保持。同じ書き方の箇所も列挙
検査の観点
検査ツールが持つルール次第
5つの観点で危ない箇所を先に洗い出してから検査する
結果の行き先
ツールごとのレポートで完結する
セキュリティ警告の一覧に集約。設定の不備やソフトウェアの弱点と同じ流れで対応
安全性
担当者の注意に委ねる
対象の限定・危険な操作の除外・認証情報の伏せ字を、仕組みとして強制
05Coverage
Seven domains守る範囲を7領域で整理する
いずれも「検知はAWS（または公開されている検査ツール）、その後の対応はcuonology security」という同じ分担です。何を守り、何を意図的に外すのかを先に明示します。
| 領域 | 対象 | 検知後の扱い |
|---|---|---|
| 設定の不備 | AWSが公開している推奨設定項目に対する違反 | 修正先がインフラの設定ファイルなら、そう指定して起票 |
| ソフトウェアの弱点 | サーバー・コンテナ・実行環境に含まれる既知の弱点 | 同じプログラムの弱点はまとめ、自動修正の候補にする |
| 不審な動きの検知 | 不審な操作・マルウェア・外部への不正な通信 | そのシステムを担当するチームにチケットを渡す |
| 権限と公開範囲 | 外部に公開された資源・使われていない権限 | 組織全体に関わる検知は、インフラ側の課題として起票 |
| 記録の監査 | 管理者権限の使用／ログイン失敗の集中／設定変更／鍵の共有／不審な通信 | 集計結果を警告として登録し、アプリ側の流れで拾う |
| アプリの事前検査 | 5つの観点による疑似攻撃（コードを読んだうえで実施） | コードから作った検査シナリオ。「どのファイルの何行目か」まで特定 |
| 状況の可視化 | 直った／未対応／放置 × 分類 × 重要度、対応不要の判断、チケットの追跡 | 1枚のレポートに集約。元データはセキュリティ警告の一覧 |
意図して対象外にしている領域
設計上、守備範囲を広げすぎない- コードの静的解析の本格運用変更内容を読む補助的な観点として存在。検査の主体は事前検査
- インフラ設定の生成・適用インフラ側の責務。追跡チケットを作るところまで
- 検知の仕組みの有効化設計組織レベルの設計領域。導入支援でカバー
- 手作業による侵入テスト人の作業。必要に応じて専門会社と組み合わせ
- 通信の遮断ルールの運用運用設計の領域。検知結果の集約まで
- 管理対象外のアカウント対象組織の外は検査範囲に含みません
06Plans
How to start提供形態とはじめ方
年間契約＋サポート契約（1ユーザー単位のシート課金）を基本に、閉域環境向けのオフライン提供と、導入支援をご用意しています。価格は構成により異なるため個別にお見積りします。
Standard
年間契約＋サポート契約
1ユーザー単位のライセンスです。契約期間中の版の更新提供とサポート対応を含みます。契約期間中にリリースされた版は、期間後も継続してご利用いただけます。節目版（1.x）間のパッチはサポート契約者に提供します。
PRICE
個別お見積り（シート課金・税別）
Air-gapped
オフライン提供
外部通信が制限された環境向けに、署名検証済みのオフライン用バンドルを納品します。閉域のAWS環境でも、検知から起票までの流れを同じように運用できます。
PRICE
個別お見積り
Onboarding
導入支援（オプション）
現状診断、検知源（Security Hub / Security Lake 等）の有効化設計、トリアージ運用の立ち上げ、開発連携（cuonology engineering）の構築までを支援します。
PRICE
個別お見積り
Requirements
対応環境：AWS（Security Hub / GuardDuty / Inspector / Access Analyzer / Security Lake）＋ GitHub。配布は版を固定したインストーラーで、ハッシュと署名を公開し、実行前に内容を確認する手順をご案内します。表記価格は税別です。
07Message
AI is a weapon
for both sides.
AIは攻撃者にも守る側にも武器になります。cuonology securityは、脆弱性を「検知して報告する」段階で止めず、修正PRまで自動で進めることで、限られたセキュリティ要員でも攻撃者より速く回り続ける運用を実現します。
手順を決まったプログラムに、判断をAIに分けた設計は、無人化を進めながら監査可能性を保つための私たちの答えです。Cuon自身の全社AWS環境で実運用した実績と改良を、継続的に製品へ反映します。
08FAQ
Questionsよくあるご質問
Q.01リポジトリのコードや警告の内容は、Cuonに送信されますか。
いいえ。cuonology securityはお客様のAWS / GitHub環境上で稼働し、警告の内容やコードをCuon側に持ち出しません。AIに生ログ・個人情報・認証情報を渡さない設計です。配布するインストーラーも署名検証できる形で提供します。
Q.02すでに動いているSecurity Hubの運用と併用できますか。
はい。cuonology securityは検知器を置き換えず、Security Hubを唯一のバスとして使います。既存のコントロールや検知源をそのまま活かしたうえで、検知後のトリアージ・起票・回収・可視化を自動化します。
Q.03どのAWSアカウント・リージョンが対象になりますか。
複数リージョン・複数アカウントの構成に対応します。対象範囲（Organization構成、リージョン、権限の委任方法）は、導入時に個別に設計します。管理外のOrganizationは対象外です。
Q.04導入までにどれくらいの期間がかかりますか。
現在のAWS構成とリポジトリ構成を確認したうえで、個別にご案内します。検知源の有効化状況によって作業範囲が変わるため、まずは現状診断（導入支援オプション）から始めることをおすすめしています。
Q.05閉域環境（インターネット接続なし）でも使えますか。
オフライン提供をご用意しています。署名検証済みのバンドルを納品し、外部通信が制限された環境でも検知から起票までの運用を行えます。利用できる機能の範囲は個別にご相談ください。
Q.06誤検知やノイズが多いのでは、という懸念があります。
重要度の高い検知は必ず個別に起票し、低いものはダイジェストに集約します。繰り返し続く検知は抑止を提案し、解消したIssueは自動で回収します。優先度の判断根拠を残すため、後から運用ルールを見直せます。
Q.07自動で修正PRまで作られると、統制が効かなくなりませんか。
自動実装の候補は型を限定し、影響範囲を絞っています。修正は必ずレビューとマージを経由し、force-pushや検証スキップを塞ぐ仕組みも内蔵しています。無人化の範囲を制御しながら運用できます。
Contactまずは、現状の検知体制を
お聞かせください
「検知はできているが、直すところまで手が回らない」。その状態をどう変えるかを、具体的な構成とあわせてご提案します。製品資料のご請求もこちらから承ります。
03-5577-4405 受付時間 平日 10:00〜19:00
※ 本ページの記載内容は2026年10月時点の情報です。価格・対応環境・提供開始時期は調整中であり、予告なく変更される場合があります。記載の会社名・製品名は、各社の商標または登録商標です。
- HOME
- SECURITY