セキュリティ脆弱性診断、これまでのままで大丈夫ですか

生成 AI が発見する膨大な脆弱性、AI コーディングエージェントによるコード、AI という新しいサイバー攻撃の脅威、そして困難を極めるサプライチェーン管理とコンプライアンス。

今年の脆弱性診断の報告書で、何が直りましたか。

診断は受けた。指摘も出た。それで、開発チームは何から手をつけたでしょうか。

報告書はきちんとファイルされています。深刻度の一覧もついている。けれど、わたしたちが入る現場では、話はそこから進んでいません。そして翌年、同じ指摘がまた出てきます。

脆弱性診断そのものが悪いわけではありません。報告書が、改善に直球で役に立つ形になっていない——問題はそこにあります。

公開される脆弱性は増え続け、攻撃側がそれを使いはじめるまでの時間も短くなりました。一方で、直すほうの時間はほとんど変わっていません。修正を作り、検証し、影響範囲を確かめて配る——ここは人と手続きの世界だからです。詰まっているのは、見つける側ではなく直す側です。

診断は、欠陥の一覧を受け取るために受けるものではありません。社内で修正を進めるためのガイダンスを、外から取ってくるためのものです。

そう捉え直すと、2つのことがはっきりします。報告書に何が書かれているべきか。そして、どう診断するべきものなのか。

報告書に、何が書かれているべきか

足りないと感じる点は、たいてい次の4つのどれかです。裏返せば、社内を動かすために本当は要るものが、この4つということでもあります。

いまの報告書に足りない4つと、それぞれに対してわたしたちがこう返す4つの対応
左が、よくいただく物足りなさ。右が、それぞれに対してわたしたちが返すものです。
  • どこから手をつけるかが決められない。指摘には深刻度がついています。けれど「その欠陥に、うちの環境で外から本当に届くのか」は書かれていない。届くかどうかが分からないまま件数を見ても、順番はつきません。
  • 直し方が一般論で終わっている。「入力値検証を実施してください」。正しいのですが、自分たちのコードのどこを、どう直すのかが分からない。開発者が読んで手が動く記述になっていません。
  • すぐに直せないものについて、何も書かれていない。止められない基幹システム、改修の予定がない古い仕組み、他社製の部品。現実には「直せない」が必ず残ります。そこをどう守るのかは、報告書の外側に置かれたままです。
  • 直したあと、直ったかどうかを確かめる筋道がない。再診断は別の見積もりで、別の稟議。結局、確かめないまま次の年になります。

4つ全部、という現場ばかりではありません。どれか1つでも心当たりがあれば、このページはそのまま当てはまります。

そして、何を見て、何を見なかったのかを書きます。見つからなかったことには、本当に無かったのか、そこまで届かなかったのか、試し方が足りなかったのか、いくつも理由があります。この区別が書かれていない報告書は、安全の裏づけとしては使えません。どの条件で、何について、どこまで言えるのか。そこまで書いて、判断の材料になります。

ここまで揃うと、報告書は「きちんとファイルされる文書」ではなく、翌週の計画になります。

どう診断するべきものなのか

診断には、診る側がどこに立つかで3つの型があります。見積書に並ぶメニュー名は、この3つのどれかに対応しています。

診断の3つの型。ホワイトボックスは中を開けて診る、ブラックボックスは外から診る、グレイボックスは両方を持って突き合わせる
ホワイトボックスは中を開けて、ブラックボックスは外から。両方を持って突き合わせるのがグレイボックスで、わたしたちが採るのはこの形です。

中身も外も持っているので、「欠陥がある」で止まらず、「外から届くか」「届いたら事業に何が起きるか」まで言えます。片方だけを見ている限り、この欄は埋まりません。埋まらないまま件数だけが増えると、直す作業に終わりが来なくなります。

この形をとると、次のことが言えるようになります。

  • この欠陥は、外から届くのか — 届くまでの攻撃シナリオを示します。
  • 業務の流れに無理がないか — 権限の与え方、処理の順序、金額や在庫の扱いを確かめます。
  • 認証・認可の設計が、意図どおりに効いているか — 設計の意図と、実装の挙動を突き合わせます。
  • AI エージェントに与えた権限が、想定を超えて使われないか — 与えた権限の範囲と、実際に届く範囲の差を確かめます。

一覧を作る仕事は、もうかなりの部分が自動化されました。残るのは、本当に目的を達成できてしまうのかを確かめる仕事です。攻撃する側と同じ手口で、セキュリティの機能を回避して、実際にそこまで行けるのか。ペネトレーションテストと呼ばれる仕事で、攻撃側が AI を使う時代には、実際に試す以外に確かめようがありません。

もう1つあります。社内のツールも AI も、御社の資産の一覧や設計の資料を土台にして判断しています。その土台に載っていないものは、道具がどれだけ賢くなっても、評価の対象になりません。だから、土台そのものを外から作り直す仕事があります——攻撃面の把握(ASM)です。棚卸しから漏れた資産、放置されたサブドメイン、部門が独自に立てた仕組み。「うちがインターネットに何を出しているのか、正確には言えない」という状態に、外側から答えを出します。

わたしたちが外から入る意味は、別の前提、別の道具、別の攻撃の立て方を持ち込むことにあります。社内で回している評価とは、違う間違え方をする。だからこそ、いまの評価がどこまで信用できるのかを、外から確かめられます。

どこまで行けるのか

外部に頼む理由は、脆弱性やシステム上の改善点を見つけてもらうことだけではありません。御社の直し方そのものが機能しているか、それを外から確かめるという理由もあります。会計の監査と似た役目です。報告書に何件並んでいたかより、来年また同じことが起きないか。経営が知りたいのはそちらです。

リードで触れた「翌年、同じ指摘がまた出てくる」には、もう1つの顔があります。直したかどうかだけの問題ではなく、同じ問題を次に入れない仕組みが、社内で育っていないという問題です。外から見つけたものを、指摘のまま置いておくと、次も外から見つけることになります。

1年目から3年目にかけて、外からの指摘として上がってくるものが減り、社内で先に気づけているものが増えていく
見つけたものを、静的解析のルールや回帰テストのケース、リリース前に止める条件として、御社の側に戻していきます。回を重ねるほど、わたしたちが新しく見つけるものは減っていく。それが正しい姿です。減った分は、もっと深いところを診る時間になります。(図はイメージです)

次に同じ問題が入ったときには、こちらの診断を待たずに御社の中で気づける。そこへ向けて、一件ずつ戻していきます。ここまでがわたしたちの仕事です。見つけて報告して終わり、ではありません。

進め方

進め方:対象と深さの設計 → 診断 → レポート → 再診断。年間の枠では、ここが計画のなかで回り続ける

1. 対象と深さの設計 — 御社にあるどんなシステムを、どんなリスクを踏まえて、どの深さで診るか。テスト設計をする必要があります。事業が止まるレベル、あるいは顧客に大きな損害を与えるレベルの急所と、外から見えている面の両方から決めます。何を見て、何を見ないかも、ここで決めてお伝えします。

2. 診断コードや設計に関わるドキュメントを拝見できると、動いているシステムと突き合わせられます。その欠陥に外から本当に届くのか、届いたら事業に何が起きるのかまで、確かめられます。

3. レポートその脆弱性が実際にどう悪用され、悪用されたら事業に何が起きるのか。そこに至る攻撃シナリオを分析して、そのシステムに即した直し方をつけてお返しします。すぐに直せないものには、守り方を添えます。

4. 再診断 — 直したものが本当に直っているかを確かめます。最終報告のあと90日以内であれば、ご依頼に応じて1回。年間の枠では、この 1〜4 が計画のなかで回り続けます。

なぜ、この形を作ったのか

脆弱性診断には、攻撃を先回りするという性質があります。攻撃する側は、画面の数を数えてから来るわけではありません。ページ単位で見積もるやり方は、そもそも診断の性質に合っていません。そのうえ診断のたびに、お客様がパラメータの一覧や仕様の解説を用意する。スキャナでふるまいを見て、コードを読めば意味は分かるのに、その手前で発注する側が消耗しています。

もう一段、大きな問題があります。診断の対象を細かく切り分け、収益性の高い部分にしか予算がつかない。この枠組みのままで、CISO は自社のリスクを把握できるでしょうか。わたしたちは、無理だと考えました。

だったら、スケジュールとリソースの許すかぎり、ネットワークから Web、モバイルにいたるまで、よくある脆弱性診断をモジュール化して、順に自由に使える仕組みがあればいい。そこから「サブスクリプション」「年間契約」という形を提案し、実現したのが Asterisk 3D です。テストのメニューを平準化し、ページ単位ではなく、リスクを軸にした包括的なテストとして設計し直しました。

よくある脆弱性診断アスタリスク・リサーチ
買い方案件ごとに見積もりを取り、発注します。そのつど社内で稟議を通す必要があります。あらかじめチケットを買っておけます。たとえばモバイルの Comprehensive テスト(アプリ本体とバックエンドの API)を年に3回と決めているなら、3回分を先に買っておきます。年間の枠として持つこともできます。枠で持つ場合、テストのたびに必要なのはスケジュール調整だけです。
見積もりの単位画面数やページ単価で積算します。テストの観点を増やすほど高くなり、ツールで診るか人手で診るかでも変わります。ツールと人手は、はじめから両方使う前提です。価格はテストの種類で決まり、画面数やページ単価という考え方をとりません。規模が大きければチケットが2枚になったり、日数が増えてコースが変わったりはします。年間の枠なら、どのテストでも同じ枠に入るので、スケジュールさえ合えば実施できます。
対象の決め方予算に応じて、診るシステムを選びます。予算に応じて、テストの内容も絞ります。年間の枠なら、単体では予算がつきにくい小さなシステムも診られます。対象を決めたあとに、セキュリティ上必要なものを予算のために削る、ということはめったにありません。
スケジューリングかなり前もって予約しておく必要があります。調整はもちろん要りますが、枠のなかで柔軟に選んでいただけます。
テスト前の準備見積もりの単位に関わる技術情報や、リクエストの詳細資料を用意するオーバーヘッドがかかります。詳細な仕様書は、基本的に必要ありません。画面やリクエストの単価で見積もらないからです。設計の資料はあるに越したことはなく、ソースコードや設計書をお預かりできれば、より解像度の高い結果をお返しできます。準備の進行は、日本語でこちらが担います。
修正支援脆弱性の指摘にとどまることが多く、修正を確かめる再診断は別の見積もりになりがちです。再テストに応じる会社もあります。どれから直すべきかを、はっきり示します。最終報告のあと90日以内であれば、直した箇所の確認をお受けします。同じ診断をもう一度やるより、修正の進め方についてのガイダンスのほうが役に立つ場面が多いので、そちらを手厚くしています。終わったあとの打ち合わせや、チャットでのやり取りにも対応します。
経営への報告深刻な指摘が何件あったかを報告し、共有します。件数に加えて、いまどうなっているかを、ダッシュボードでいつでも見られます。年間契約ではポータルとダッシュボードをご提供します。経営への報告を、そのつど作るのではなく、いつでも出せる状態にする。そこを目標にしています。

案件ごとの発注が悪いわけではありません。年に一度で足りるシステムもあります。ただ、年に何本も出していて、そのつもりがないまま前年の仕様を踏襲しているなら、左の列にコストが隠れています。

何を診て、どう頼めるか

診断のメニューと、その頼み方です。「うちのこれは、どれで、どうやって頼めるのか」から引いてください。

日数はテスト開始からの営業日で、祝日は含みません。テスト開始の3営業日前までに事前確認を済ませます。認証情報の不備やロックアウト、テストデータの不足、ホスティング事業者の許可待ち、対象システムの停止——こうしたことが起きると、その分だけ延びます。規模と深さによっても変わるので、対象を決める段階でお見通しをお伝えします。
「個別」は、下のプロフェッショナルサービスでお受けします。組込機器・IoT 機器は、まずご相談ください。

頼み方は3つあります

  • 年間契約(Asterisk 3D) — 枠として持ち、カレンダーの許すかぎり入れられます。依頼と進行のポータル、状況を見るダッシュボードをご提供します。6か月(26週)または12か月(52週)。作業は1レーンにつき一度に一件ずつなので、並行させたい場合は複数レーンをお持ちいただけます。
  • オンデマンドのチケット — Web やモバイルのテストなど、一部のメニューを必要なぶんだけ。まず一本、から始められます。
  • プロフェッショナルサービス — スペシャリストによる個別対応のサービスです。

年間契約 — Asterisk 3D

あらかじめテストの枠を確保しておき、その枠を「何を診るか」「いつ診るか」「どれだけ深く診るか」の3つの軸で組み替えます。だから、システムを1つずつ稟議にかけるのではなく、企業のシステムを横断して、続けて診ていけます。対象・深さ・開始時期を指定してリクエストし、優先順位が変わったら並べ替えられます。作業は一度に一件ずつ。並べ替えの主導権はお客様側にあります。

一度の診断で良し悪しを判断する視点には閉じません。システムのライフサイクルのなかで、どう改善されていくかを見ます。定期検診と、かかりつけ医。そういう関わり方で、脆弱性診断を御社の仕組みのひとつにする——それが 3D のコンセプトです。

稼ぎ頭のシステムには手厚くテストを入れられる。けれどその隣で動いている古い業務システムや、部門が独自に入れた仕組みは、稟議を通す名目がないまま何年も手つかずになります。攻撃する側は、その差を知りません。枠として持つと、この差が埋まります。

プロフェッショナルサービス

スペシャリストが、対象を決めて深く入る個別対応のサービスです。製品そのものを診たいとき、判断が割れているとき、いまの診断結果をどう読むか迷っているときにお受けします。

そして、一般の診断会社にメニューがない対象。たとえば Windows や macOS のデスクトップアプリケーション。あるいはグレイボックステストそのもの——外からの診断とコード診断が別のメニューに分かれていて、両方を突き合わせる形が用意されていない。標準の手順に当てはまらないので見てもらえなかった、という相談をよくいただきます。仕様を読み込むところから始めます。

  • 製品のグレイボックステスト — クライアント製品・業務システムを、ソースと実機の両方から。外から届くか、権限の設計、業務の流れの無理を、仕様の意図まで読んで確かめます。
  • ソースコード解析(SAST・SCA) — 設計と実装、そして持ち込んだ部品を診ます。年間契約の枠だけでなく、単体でもお受けします。
  • 攻撃面の把握(ASM) — 外から見えている資産と入口を洗い出します。社内の一覧に載っていないものを、外側から見つける仕事です。
  • 診断の設計 — 御社にあるどのシステムから、どの順番で診るか。事業への影響とリスクから決めます。
  • いまお持ちの報告書の読み直し — 指摘に攻撃シナリオが書かれているか、事業の重さで並べ替えると順番はどう変わるか、次に診るべきはどこか。お手元の一冊があれば、話はいちばん具体的に始められます。
  • クラウドの構成・設計のレビュー — 意図したセキュリティ条件が、実際の構成で満たされているか。設計の側から確かめます。
  • 直せないものをどう守るか — すぐに直せない資産について、被害の広がる範囲を先に狭める設計をご一緒します。

ここは、アスタリスク・リサーチ自身の仕事です。診断を「受けて終わり」にしないための部分です。

来年度の発注で、確かめること

発注仕様を昨年から変えるには、材料が要ります。どんなテストをどう組むかより一段上の問いを、7つに整理しました。相手に確かめるものと、自社に問うものが混ざります。どちらも要ります。

診断する力について

  • 1脆弱性を正確に評価できますか。AI が書いたもの、人が書いたもの、外部に委ねたもの。設計の問題か、実装の問題か、持ち込んだ部品の問題かを見分けたうえで評価できますか。ツールの出力が、確かめられないまま並んでいませんか。
  • 2システムのビジネスリスクを考慮に入れたテストを展開してくれますか。1つの画面のなかで完結する深刻度ではなく、事業が止まるレベル、顧客に大きな損害を与えるレベルから見て、どこを深く分析するかを決めていますか。
  • 3国内外のコンプライアンスの要求まで含めて、サプライチェーンの求めに応えられますか。取引先から求められる水準は、年ごとに具体的になっています。求められてから慌てるのか、先に答えを持っておくのかの差になります。

診るチームについて

  • 4信頼できる技術と判断力を持つ人たちが診て、相談に乗ってくれますか。最近のインシデント事例の分析や、OWASP が示すセキュリティのプラクティスを、実際のテストに落とし込めていますか。判断が割れたときに、どうすべきかをいっしょに考えられる相手かどうかです。
  • 5AI を含むさまざまな道具を、責任を持って使っていますか。何を道具で見て、どこまで人が確かめたのかを説明できますか。道具が増えるほど、ここを説明できるかどうかで差がつきます。

自社にかかる負荷について

  • 6システム全体に必要なテストを、まとめて届けてくれますか。画面数やページ単価で積むと、そのシステムに本当に必要なテストが、見積もりの都合で落ちます。必要な脆弱性があれば指摘が返ってくる、そういうオーダーの形になっていますか。
  • 7準備が終わったら、あとは任せられますか。毎回こちらが同じ説明を繰り返すのか、前回の経緯を覚えていて、こちらの事情を汲んで動いてくれるかどうかです。どれくらいの時間で望んだ結果が返るのかも、はじめにはっきりしていますか。

この7つは、複数社から見積もりを取るときの比較軸にもなります。わたしたちに向けてでも、他社に向けてでも、そのままお使いください。複数のベンダーに分けて発注している場合は、同じ7つを全社に要求できるかどうかで、品質のばらつきが見えます。

誰が診るのか — 文脈を知っているかどうかで、結果が変わります

セキュリティテストは、文脈がほとんどすべてです。同じ製品でも、そのシステムがどういう経緯でその設計になったのか、事業のどこに乗っているのか、何が起きるといちばん困るのかによって、見るべき場所は変わります。だから、技術の確かなエンジニアと、適切に判断できるメンバーが要ります。

実際に手を動かすチームには、長い系譜があります。ソフトウェアセキュリティという分野そのものを作ってきた Cigital——のちに Synopsys のソフトウェア・インテグリティ事業となり、Black Duck の名で知られたチーム——と、わたしたちは長くいっしょにやってきました。2025年9月、この事業は UltraViolet Cyber(米国バージニア州マクリーン)に引き継がれています。 会社の看板は何度か変わりましたが、同じチームが、同じお客様を、続けて診てきました。外部に発注を流しているのではありません。この体制は、十数年かけて自分たちで組み上げてきたものです。

いつでも、ざっくばらんにご相談ください。日本で必要になるコンプライアンスは何か。御社が守りたいシステムについて、セキュリティの目標をどこに置くか。それに向けて、テストではどのフレームワークを採るのがよいか。改善に向けていっしょに取り組む相手として、わたしたちはテストのチームと付き合ってきました。同じ関わり方を、御社との間でもします。ご契約も、ご請求も、何かあったときのエスカレーションも、すべてアスタリスク・リサーチがお受けします。テスト準備の進行も、日本語でこちらが担います。

アスタリスク・リサーチ自身も、テストの力があるメンバーとともに、汎用のサービスには当てはまらない対象のテストを、設計から実施までやってきました。

海外のコンプライアンスについては、テストのチームが、きわめてハイリスクな顧客の要求にも応えられるよう取り組んでいます。わたしたちは、日本のハイリスクなシステムを支えている方々——真剣に作り、持ち、動かしている方々——を支えてきました。いま、どんなシステムも少しずつハイリスクになっています。高まるリスクに向き合っている方々を支えてきたので、自信を持ってお勧めできます。

※ UltraViolet Cyber は2025年9月4日、Black Duck のアプリケーションセキュリティテスト事業(ペネトレーションテスト、レッドチーム、脅威モデリング、クラウド/コンテナのリスク評価、アーキテクチャリスク分析、セキュア開発コンサルティング)の取得を発表。Black Duck は Synopsys のソフトウェア・インテグリティ事業を前身とします。

国内外のユーザー事例について

共通しているのは2つです。ひとつは、自社のシステムやサービスの上に、他社の事業や人の生活が乗っていること。止まったとき、困るのが自社の中で収まりません。もうひとつは、そのリスクの高さを、自分たちで自覚していることです。

ライフライン、SaaS・プラットフォーム、金融、製造業、製薬。システムインテグレーター、そして大企業グループのシステムを担う専門会社。規模にも幅があります。長く続いている大企業のシステムもあれば、立ち上がったばかりのサービスもあります。海外の組織からのご依頼もあります。

使うほどに、使いやすくなっていきます。2つのテストを並行させたいお客様は、年間の枠を2レーン、あるいはそれ以上お持ちです。年間の枠に加えてチケットを買い、一時的に並行させる形をとるお客様もいます。前回の経緯が引き継がれるので、回を重ねるほど、こちらから説明する手間が減っていきます。

窓口になるのは、情報システム・セキュリティ部門、PSIRT・製品セキュリティ、CSIRT、サービスを運営している事業部門、品質保証、開発のリーダーです。

リスクに向き合うお客様の側に立ちます。テストの品質も、ポータルでのやり取りや納品も、わたしたちの責任です。

※ 守秘の観点から、お客様名は掲載していません。

よくあるご質問

  • 費用はどのように決まりますか。年間契約の費用は固定です。オンデマンドのチケットとプロフェッショナルサービスには、価格表があります。ウェブには載せていませんので、まずは御社の状況を共有していただくミーティングから、ご一緒しましょう。
  • どれくらいの期間がかかりますか。メニューごとの目安は、上の「何を診て、どう頼めるか」の表にあります。わたしたちはテストを時間の枠で区切って行います。御社が判断するために必要な材料を、必要なときに手に入れていただくことを重視しているからです。
  • ソースコードを預けられないのですが。その場合は外から診る形になります。その条件のもとで、できるテストを設計して実施します。閲覧のみ・こちらから持ち出さない、といった取り扱いのご相談も承ります。
  • いま他社に診断を依頼しています。乗り換えの相談になりますか。いいえ。テストの設計をご一緒するところからお受けしています。御社にとって本当に必要なテストは何か。それを整理する助けになれます。
  • 診断のあいだ、サービスを止める必要がありますか。原則として止めません。検証環境をご用意いただく場合と、本番に近い環境で慎重に進める場合があります。どちらにするかは、対象と深さを決める段階で相談して決めます。実施時間帯の指定にも対応します。
  • 報告書は英語でも日本語でも出せますか。どちらでも出せます。年間契約(Asterisk 3D)の報告書は、もともと英語で出ます。日本語でもお出しします。プロフェッショナルサービスの報告書も、英語でお出しできます。海外の親会社やお客様への提出、サプライチェーンからの求めに応じる用途でご利用いただいています。

開発と運用のチームの成長に、いちばん貢献する診断を選んでください

診断を選ぶときに見ていただきたいのは、それが御社の開発と運用のチームを育てるかどうかです。ソフトウェアの欠陥が直ればよい、という話ではありません。問題が出たときに、自分たちで適切に判断できるようになる。そこに効くかどうかで選んでください。

わたしたちのサービスは、ソフトウェアを作り、変え続けている企業がどこで詰まるかに沿って並んでいます。「何を売っているか」ではなく、「いま、うちは何で困っているか」から引いてください。

いま困っていること効くもの診る対象
この一件を深く診てほしい。うちがインターネットに何を出しているのか、正確に言えない。すぐには直せない。Professional Service個別の難所と、外から見えている面ぜんぶ
毎年診断は受けている。でも報告書が改善に直球で役に立たない。直したかどうかを確かめないまま次の年になる。Asterisk 3D動いているシステム・サービス
指摘がツールごとにバラバラで、いまどうなっているのかを誰も言えない。開発を止めずに回したい。Checkmarx One開発の日々の流れ
同じ脆弱性が毎年出る。一部の人に頼っていて、組織として育っていない。経営に投資の根拠を示せない。OWASP SAMM アセスメント組織・体制(人と仕組み)

この4つは、代替ではありません。並べ替えると成長の段になります。深く一点を診る → 横断して続けて診る → 開発の流れに埋め込む → 組織の地力にする。上に行くほど「外から見つける」、下に行くほど「自分で気づく」。わたしたちの目的は、お客様が下へ移っていくことです。

そして、どのサービスでもサクセスマネジメントはアスタリスク・リサーチが担います。御社のフロントに立つのは、わたしたちです。技術の監修も、進め方の改善も、わたしたちの仕事です。製品を仕入れてお渡しするのでも、どこかのチームに取り次ぐのでもありません。

AI がコードを書き、AI が攻撃にも使われる。どちらの側から見ても、この時代に要るものは同じだと思います。決まった理屈で、繰り返し同じように測れるリスクの俯瞰。そして、成長のための改善に付き合う相手。道具が、それだけで答えを出してくれるわけではありません。AI から本当の便益を得ているのは、問いを正しく立てられる人だけです。

さて、どこから検討されますか。

来年度の発注仕様を組み直すところからでも、対象を1つ決めて深く診てみるところからでも、いまの診断で足りていないところを整理するところからでもかまいません。どこから手をつけるのが御社にとっていちばん効くのか、そのご判断のお手伝いができます。

いまお持ちの報告書を見ながら、話しませんか

対象を決めるところからご相談いただけます。直近の脆弱性診断報告書がお手元にあれば、それを見ながら話せます。指摘に攻撃シナリオは書かれているか。事業の重さで並べ替えると順番はどう変わるか。次に診るべきはどこか。

はじめての診断でも同じです。何をどの深さで診るのが妥当か、対象の話からご一緒します。

対象の相談をはじめる

お申し込みフォームの「どんなご状況でしょうか」で、脆弱性診断やソースコード検査を受けたいをお選びください。

arrow_upward