セキュリティ研究者はSource Codeを読み、Application Behaviorを解析し、DeveloperのAssumptionと実際のImplementationを比較し、疑わしいConditionを再現しながら、そのWeaknessが本当にExploit可能かを判断してきました。
AIは、このWorkflowを大きく変え始めています。
現代のFrontier Modelは、大規模なCodebaseを分析し、未知のFunctionを説明し、Data Flowを追跡し、Vulnerability Hypothesisを生成し、複数ComponentをまたぐAttack PathのCandidateを調査できます。
しかし、AIが疑わしいCode Patternを発見したからといって、それが自動的にReal Vulnerabilityになるわけではありません。
Security Impactは依然として、
Reachability、
Authentication、
Authorization、
Runtime Configuration、
Attacker-Controlled Input、
Business Logic、
Human Validation
によって決まります。
元記事では、DARPA AI Cyber ChallengeやAnthropic Project Glasswingなどを、AIが単なるSecurity BenchmarkからReal-World Vulnerability DiscoveryとRemediationへ進み始めている例として扱っています。
なぜ脆弱性研究はAI支援型へ移行しているのか
現代のSoftwareは、人間だけですべてを深く確認するには大きすぎます。
一つのProductでも、
巨大なCodebase、
Third-Party Library、
API、
Framework、
Cloud Service、
Authentication Infrastructure、
絶えず更新されるDependency
を含みます。
Experienced Security Researcherであっても、すべてのComponentへ同じAttentionを向けることはできません。
従来型Security Toolはこの問題を部分的に解決してきました。
Static AnalyzerはSuspicious Patternを検出します。
Dynamic ScannerはKnown ConditionをTestします。
Dependency ScannerはKnown Vulnerable Packageを探します。
これらは今後も重要です。
ただし多くのConventional Automationは、事前に定義されたRule、Signature、Known Weakness Classへ依存しています。
Frontier AIが追加するのは、
SoftwareをContextの中でReasoningする能力です。
複数FunctionがどうInteractionするか。
Developerが何を意図していたのか。
どのAssumptionが別Execution Pathで破れる可能性があるか。
こうした問いへ参加できるようになります。
Pattern MatchingからSecurity Reasoningへ
Traditional Scannerは、すでに知っている問題を見つけることに強みがあります。
Exposed Configuration。
Known Vulnerable Dependency。
Dangerous Function。
しかしZero-Day Researchでは、それだけでは十分ではありません。
Critical Vulnerabilityは、複数の一見正しいImplementation Decisionが組み合わさって生まれることがあります。
Authorization Checkは存在するが、Wrong Layerで実行される。
Parserは通常Inputでは安全だが、別Componentと組み合わさるとDangerousになる。
Applicationは、
「このValueは前のLayerでValidation済み」
とAssumeしている。
しかし一つのAlternate Code Pathだけ、そのValidationをBypassする。
こうしたIssueにはContextual Reasoningが必要です。
AIはSecurity ResearcherがそのContextを探索するSpeedを大きく上げられます。
AI支援Code Analysis
AI Vulnerability Discoveryで最も実用的な用途の一つがCode Comprehensionです。
Security Researcherは、自分が書いていないSoftwareを調査することが多くあります。
まず理解しなければならないのは、
User-Controlled Dataはどこから入るのか。
どこでTransformされるのか。
どのFunctionがAuthenticationを要求するのか。
Authorization Checkはどこにあるのか。
どのCodeがFile、Memory、Network、Privileged Operationへ触れるのか。
です。
Large Repositoryでは、これだけでかなりの時間を使います。
AIはModule間のRelationを説明し、Relevant Functionを探し、Deep InvestigationすべきCode Pathを絞り込むことで、この初期理解を高速化できます。
ただし重要なのは、
AIの説明をSecurity Conclusionとして扱わないことです。
AIはResearch Instrumentです。
Final Evidenceではありません。
Vulnerability Hypothesisを大量に作れる
優れたSecurity ResearchはHypothesisから始まります。
このFunctionはどんなAssumptionをしているのか。
AttackerはこのValueをControlできるか。
ValidationはSensitive Operationより前に行われるか。
別PermissionのCode Pathから同じFunctionへReachできるか。
二つのFeatureを組み合わせたら何が起こるか。
AIはこうした質問を大量に生成できます。
これは大きな利点です。
しかしModelが100件のHypothesisを生成しても、100件のVulnerabilityが見つかったわけではありません。
CandidateとConfirmed Findingを明確に分ける必要があります。
AI-assisted vulnerability discoveryの目的は、
最大数のFindingを作ることではなく、Human Validationする価値の高い場所を見つけることです。
Attack Pathの探索が高速になる
Weakness単体のTechnical Severityより、
Attackerがそこへ到達できるか
の方が重要な場合があります。
Authorization Weaknessがあっても、Internal AdministratorしかReachできないならScenarioは限定されます。
小さなInformation Disclosureでも、そこから別UserのObject Identifierが得られ、そのIdentifierをBroken Authorization Endpointで使えるなら重大になります。
AIは複数Component間のRelationを追跡できるため、Attack-Path Explorationと非常に相性があります。
Suspicious Functionを見つける。
どこからCallされるか確認する。
どのInputが到達するか探す。
どのPrivilegeが必要か分析する。
Related EndpointやToolを調査する。
Human Researcherは、
そのChainが現実に成立するか
を確認します。
Large CodebaseでSecurity-Sensitive Areaを優先できる
すべてのCodeを同じ深さでReviewするのは現実的ではありません。
Security Teamは、重要な部分を優先する必要があります。
Authentication。
Authorization。
Parsing。
Serialization。
Memory Management。
Network Handling。
File Operation。
Privilege Transition。
Cryptographic Logic。
External Integration。
AIはこうした領域をMapし、Expert Attentionを効率的に配分する手助けができます。
これはLegacy Softwareで特に有効です。
Documentationが不完全でも、CodeそのものからArchitectureを再構築できる可能性があるからです。
AIは未知のVulnerability Discoveryへ進み始めている
AI Cybersecurityが興味深い理由は、Known Vulnerability Detectionだけではありません。
元記事では、AnthropicがClaudeを利用した実Software上のVulnerability ResearchやMozillaとのFirefox研究、さらにProject Glasswingへ発展した流れを紹介しています。またDARPA AI Cyber Challengeでは、AI-driven systemがOpen-Source SoftwareのVulnerability DiscoveryとPatch Generationの両方を行う方向性が示されました。
これはAIが、
「Known CVEを検索するTool」
から、
未知のSecurity Assumptionを調査するResearch Assistant
へ近づいていることを意味します。
Known Signatureがなくても調査できる
Zero-Dayは、当然ながらSignature Databaseに存在しません。
既知VulnerabilityならIdentifierやAdvisory、Patchが存在します。
難しいのは、
まだ誰もDocumentしていないWeaknessを見つけることです。
Traditional Scannerは、
「Pattern Xに一致するCodeを探す」
ことに優れています。
AI-assisted researchでは、
「このComponentはどんなSecurity Assumptionをしていて、Attackerはそれをどう破れるか」
という問いへ進めます。
これはHuman Vulnerability Researchに近いApproachです。
Repetitive Research Workを自動化できる
Offensive Securityの多くは、派手なExploit Developmentではありません。
Documentationを読む。
Code Versionを比較する。
Function Call Siteを探す。
Configurationを理解する。
関連Functionを検索する。
Logを整理する。
Data Flowを追う。
Patchを比較する。
Reproduction Noteを書く。
こうしたMechanic Workがかなりの割合を占めています。
AIがこの部分を短縮できれば、Researcherはより重要な判断へ時間を使えます。
Reachableか。
Attacker Prerequisiteは何か。
Business Impactは何か。
Productionでどこまで安全にValidateできるか。
つまりProductivity Gainは、
人間をなくすことではなく、
Expert Timeをより価値の高い作業へ移すこと
から生まれます。
AIはPatch Analysisにも役立つ
Vulnerability DiscoveryはBugを見つけた時点で終わりません。
DeveloperがFixを作った後、
そのChangeがAttack Pathを本当に閉じたか
を確認する必要があります。
AIはVulnerable CodeとPatched Codeを比較し、
Security Changeの意図を説明し、
同じUnsafe Patternが近くに残っていないか調査する作業を支援できます。
元記事ではProject Glasswingについて、DiscoveryだけでなくPatch DevelopmentやPre-Release Security CheckにもAdvanced Modelが使われていると説明しています。
Vulnerability Familyの調査
一つのConfirmed Vulnerabilityは、しばしば別のQuestionを作ります。
同じBroken Assumptionは他の場所にも存在しないか。
複数Endpointが同じAuthorization Helperを使っていないか。
同じParser Logicが別Moduleにもないか。
一つのRoot Causeが多くのVariantを作っていないか。
AIはConfirmed Findingを起点に、Related CodeやCandidate Variantを探すのに向いています。
ただしVariant CandidateもValidationが必要です。
目的はTicket数を増やすことではありません。
Underlying Weaknessをより完全に理解することです。
人間のSecurity Researcherが依然として必要な理由
AI Capabilityが高まるほどHuman Validationは不要になる、とは限りません。
むしろ重要性が上がる部分があります。
AIはTechnical Explanationを非常に説得力のある形で生成できます。
それでもAssumptionが間違っている可能性があります。
Code Executionを誤解する。
Environment Restrictionを見落とす。
Protected ValueをAttacker-Controlledだと考える。
ProductionではReachできないPathをExploit可能と説明する。
そのためProfessional Vulnerability Reportには、Model Explanationより強いEvidenceが必要です。
Detection ≠ Vulnerability ≠ Exploitability ≠ Severity
この区別は非常に重要です。
Suspicious Functionがある。
それだけでVulnerabilityではありません。
Vulnerabilityがある。
それだけでExploit可能とは限りません。
Exploit可能である。
それだけでCriticalとは限りません。
たとえばAIがAuthorization BypassをCandidateとして見つけた場合でも、
どのIdentityがWorkflowへReachできるか。
どのObjectへAccessできるか。
Unauthorized UserがImpactを得られるか。
を確認する必要があります。
AIはInvestigationを高速化します。
Evidence Requirementをなくすわけではありません。
False Positiveは大きな課題
AIによって大量のSecurity Hypothesisが生成されると、Engineering Teamへ新しいNoiseを持ち込むRiskがあります。
すべてのAI SuspicionをTicketにすると逆効果です。
価値の高いWorkflowでは、
Candidate Finding。
Technical Reproduction。
Reachability Analysis。
Impact Validation。
Severity Assessment。
というFunnelを通します。
その後に初めてConfirmed VulnerabilityとしてEngineeringへ送ります。
目的はMaximum Findingsではありません。
Maximum Signalです。
Runtime Contextなしでは判断できない
Source Codeは非常に多くの情報を与えます。
しかしProduction Systemのすべてを示すわけではありません。
Configuration。
Infrastructure。
Runtime State。
Authentication。
Feature Flag。
Dependency Version。
Network Architecture。
Business Logic。
これらもSecurity Outcomeへ影響します。
Code上ではDangerousに見えるPathがProductionではUnreachableな場合があります。
逆に、Code単体では安全でも、Deployment ArchitectureによってUnexpected Trust Relationshipが生まれることもあります。
ここでTraditional Penetration Testingが重要になります。
AI-assisted Code AnalysisとRuntime Testingは競合ではありません。
互いを補完します。
Business LogicにはProduct理解が必要
最も深刻なVulnerabilityが、明らかなCoding Errorではないことがあります。
API Request自体はValid。
しかし一人のUserが別UserのObjectを操作できる。
Financial Workflowの各OperationはLegitimate。
しかし特定Sequenceで使うとBusiness RestrictionをBypassできる。
AI AgentのToolは個別にはAuthorized。
しかし組み合わせるとForbidden Outcomeになる。
こうしたIssueには、
「Productが本来何を許可するべきか」
という理解が必要です。
AIはWorkflowを分析できます。
Final JudgmentにはHuman Product Contextが必要です。
Vulnerability Discoveryは始まりにすぎない
Finding Speedだけが上がってもDefenseは改善しません。
Engineering TeamがFixできなければ、VulnerabilityはBacklogへ積み上がります。
そのためAI-assisted Remediationは、将来的にDiscoveryと同じくらい重要になる可能性があります。
理想的なFlowは、
AIがWeaknessを発見する。
ResearcherがValidateする。
AIがRemediation Analysisを支援する。
DeveloperがFixする。
Security TeamがPatchをReviewする。
Attack PathをRetestする。
というCircular Workflowです。
AIはOffensive Security Reconnaissanceも変える
Offensive SecurityはExploitationから始まりません。
まずTargetを理解します。
どのComponentがあるか。
どう接続されているか。
Trust Boundaryはどこか。
どのInterfaceがExposureしているか。
どのRoleが存在するか。
どのTechnologyが使われているか。
AIはDocumentation、API Description、Code、Configuration、Test Responseをまとめ、Architecture Mapを高速に作ることができます。
ただしこれはAutonomous AgentへPublic Infrastructureを自由に攻撃させてよいという意味ではありません。
Professional PentestにはExplicit AuthorizationとScopeが必要です。
Attack Surface Prioritization
Security Assessmentの時間は有限です。
すべてのEndpointへ同じ時間を使えません。
AIはTechnical ObservationをConnectしてPriorityを付ける支援ができます。
一つのEndpointはHigh-Value Dataを扱う。
別Endpointは同じAuthorization Logicを使う。
Related Source CodeにUnusual Validationがある。
このCombinationは、無関係なLow-Risk Endpointより優先して調査する価値があります。
Real AttackerはWeaknessをChainします。
Security Testingも同じ視点が必要です。
Vulnerability Chaining
Low-Severity Issueが別Findingと組み合わさると重大になることがあります。
Information DisclosureでInternal IDが分かる。
そのIDをAuthorization Weaknessへ使える。
得られたAccessでさらにSensitive Functionへ進める。
AIは大量のContextを保持し、こうしたCandidate Relationshipを提案することができます。
Human ResearcherはSequenceをValidateします。
Complex SaaS、API、Agentic Environmentでは特に有効です。
AIはExploitability Analysisも高速化する
Vulnerability DiscoveryとExploitationは同じではありません。
DiscoveryはSecurity-Relevant Conditionを見つけること。
Exploitationは、そのConditionからAttacker-Controlled Resultを作れることを示すことです。
Frontier Cybersecurity Modelは、この両方の領域で能力を高めています。
だからこそDual-Use Riskがあります。
DefenderがExploitabilityを検証するために使えるReasoningは、Attacker側のResearch Costも下げる可能性があります。
Faster Exploit ValidationはDefenseにも役立つ
Organizationには数千件のVulnerabilityが存在することがあります。
すべてを同じUrgencyでFixすることはできません。
AI-assisted Analysisによって、
実際にReachableなVulnerability、
Production InterfaceからReliableにExploit可能なWeakness、
現EnvironmentではUnreachableなTheoretical Issue
を区別する支援ができます。
これはTraditional Severity Scoreを置き換えるのではなく、Environment-Specific Contextを追加します。
Offensive AIはDefenderの時間を短くする
AIがSecurityへ与える最大の変化は、新しいVulnerability Classではないかもしれません。
時間の圧縮です。
Code Analysisが速くなる。
Researchが速くなる。
Exploitability Assessmentが速くなる。
Attack-Path Explorationが速くなる。
元記事ではNISTの2026年の見解も引用し、AIがVulnerability DiscoveryとExploitationの両方を加速させ得るため、基礎的なCybersecurity Practiceの重要性がさらに高まると説明しています。
Defenderは、
「ComplexだからAttackerが理解するまで時間がかかる」
というAssumptionへ依存しにくくなります。
Pre-Release Security Testingの価値が上がる
Release後のVulnerability Discoveryが速くなるなら、Release前にWeaknessを見つける価値はさらに高くなります。
Development中はAI-assisted Code Review。
High-Risk ReleaseではManual Penetration Testing。
Launch前にはReal Attack Pathを確認するSecurity Crash Test。
この組み合わせによって、Architectureを変更できる段階で問題を見つけられます。
Strategic Advantageはシンプルです。
AI-assisted Attackerより先にAI-assisted DefenderがAttack Pathを見つけることです。
AI支援SecurityにもRules of Engagementが必要
Automationが強力になっても、Penetration TestingのLegal / Operational Boundaryは変わりません。
Targetは明確に定義する。
Excluded Systemは除外したままにする。
Production Safetyを守る。
Third-Party InfrastructureはExplicit Authorizationがない限りTestしない。
TesterがAIを使うことで、Clientから与えられたPermissionが広がるわけではありません。
小さなSecurity Teamにも大きなメリットがある
AI-assisted Vulnerability Researchの大きなPotential Benefitの一つはEconomicsです。
Expert ResearcherはScarceで高価です。
すべてのDependencyやReleaseをManual Reviewすることはできません。
AIによって一人のResearcherがMeaningfulにReviewできるSoftware量が増えれば、
Small Security Teamがより多くのCodeを確認する。
Open-Source Maintainerがより深いSecurity Analysisを行う。
AppSec Teamがより多くのPre-Release Reviewを実施する。
ことが可能になります。
AIはResearcher ReplacementではなくForce Multiplierとして機能します。
Human ValidationがAI Security Noiseを防ぐ
Discovery Capacityが増えるほどTriageは重要になります。
AIが1,000件のCandidateを出して、そのうち10件だけがRealなら、
Engineering Teamに必要なのは1,000件のAlertではありません。
Realな10件を特定する仕組みです。
未来のWorkflowでは、
ModelがProposeする。
ResearcherがReproduceする。
Product ContextでImpactを判断する。
EngineeringがRemediateする。
RetestingでFixを確認する。
という役割分担が重要になります。
AIがCandidateを探す方法を変えても、
Vulnerabilityとして報告するEvidence Standardを下げてはいけません。
Security Researcherに必要なSkillも変わる
Technical Depthは今後も必要です。
ただしDaily Workは変化するでしょう。
すべてのFramework Detailを暗記することより、
Assumptionを調査するSkill。
AI-generated HypothesisをCriticalに評価するSkill。
ModelがConfidently Wrongなときを見抜くSkill。
Source AnalysisとRuntime ValidationをConnectするSkill。
AI Agent、RAG、MCP、API、Traditional AppSecを一つのAttack Surfaceとして考えるSkill。
が重要になります。
ResearcherはすべてのAnalytical StepをManualに行う人から、
強力なAnalytical Systemを方向付け、検証し、結び付ける人
へ変化します。
Future PentestingはHuman + AI
完全ManualなPentestingは、一部のResearch Taskでは非効率になっていくでしょう。
一方、完全Autonomous Pentestingは、
Product Context、
Authorization、
Production Safety、
Operational Judgment
が必要な場所では問題が残ります。
最も現実的なのはHybrid Workflowです。
AIがAttack SurfaceをMapする。
AIがCodeを読む。
AIがVulnerability Hypothesisを生成する。
AIがRelated Pathを調査する。
Researcherが何をTestするか決める。
ResearcherがValidationをControlする。
ResearcherがBusiness ImpactをInterpretする。
AIがRemediation Analysisを支援する。
ResearcherがSecurity BoundaryをRetestする。
この組み合わせが、今後のOffensive Securityの中心になる可能性があります。
Vulnerability Managementも変わる必要がある
Weakness Discoveryが速くなると、Downstream ProcessへPressureがかかります。
Faster Triage。
Faster Ownership Assignment。
Better Asset Visibility。
Faster Remediation。
Stronger Pre-Release Testing。
Reliable Retesting。
Vulnerabilityを早く見つけても、Patch Deploymentに数か月かかればSecurity Outcomeは改善しません。
AIはVulnerability Managementを不要にしません。
正しく機能することをさらに要求します。
AIはZero-Day ResearchのEconomicsを変える
Zero-Day ResearchはこれまでScarce Expertiseと大量のResearch Timeを必要としてきました。
AIがCode UnderstandingやWeak Hypothesis Eliminationを高速化すれば、一件あたりのResearch Costの一部は下がります。
すべてのZero-Dayが自動発見されるわけではありません。
Complex Exploitationには依然としてContext、Experiment、Technical Validationが必要です。
しかしPartial Automationだけでも戦略的な意味があります。
Large Difficult Codebaseが、
「理解できるHumanが少ないから比較的安全」
という状況は弱くなります。
ComplexityによるSecurity through Obscurityは信頼しにくくなります。
Secure Software Developmentはさらに重要になる
AI Security Toolが強くなれば、
「Developmentが多少弱くてもAIが後で見つける」
と考えるOrganizationも出るかもしれません。
それは逆です。
Faster Vulnerability Discoveryは、Insecure Engineering Practiceがより早く見つかることを意味します。
必要なのは、
Secure Design。
Strong Authorization。
Memory-Safe Engineering where appropriate。
Dependency Management。
Code Review。
Pre-Release Security Testing。
Rapid Remediation。
です。
AIはこれらをStrengthenします。
Replaceするものではありません。
Vulnerability DiscoveryはContinuousになる
Traditional PentestはPoint-in-Time Assessmentです。
しかしSoftwareはTest終了後も変わります。
New Commit。
Dependency Update。
API Change。
New Agent Tool。
Infrastructure Change。
AI-assisted Analysisは、新しいCodeやChangeへ繰り返しSecurity Reasoningを適用できるため、Continuous Securityをより現実的にします。
Development中にAI Analysis。
High-Risk ReleaseへHuman Review。
Deployed ProductへFull Pentest。
Fix後にRetesting。
このCycleによってDevelopmentとAdversarial TestingのGapを小さくできます。
AIはProfessional Offensive Securityをなくさない
Offensive SecurityはTechnical Anomaly探しだけではありません。
Scopeを理解する。
どこで止まるべきか判断する。
Productionを守る。
Business Logicを理解する。
User Roleを評価する。
Real Impactを判断する。
Findingを明確に伝える。
Engineering TeamとFixを進める。
Retestingする。
これらにはJudgmentが必要です。
AIがTechnical Explorationで非常に強くなっても、
何をTestすべきか、どこまでValidationすべきか
というEngagement Contextは依然として重要です。
そのためOffensive SecurityはよりAutomatedになりますが、完全Autonomousになるとは限りません。
AIはSecurity Researchを強力にし、同時に責任を重くする
AI-assisted vulnerability discoveryは、単なる次世代Scannerではありません。
ModelがCodeをReasonし、
Hypothesisを作り、
Attack Pathを調査し、
Remediationを支援する方向へ進んでいます。
DARPAやAnthropicの公開Researchは、この移行がすでに始まっていることを示す例として元記事で扱われています。
次のChallengeは、
AIがCybersecurityに参加できるかどうか
ではありません。
増えたCapabilityをBetter Defenseへ変換できるWorkflowをどう作るか
です。
Human Validation。
Responsible Disclosure。
Strong Authorization。
Controlled Testing。
Rapid Remediation。
これらが不可欠です。
AIはVulnerability Discoveryを加速します。
Security Expertiseが、そのSpeedをDefense Advantageへ変えます。
AIと脆弱性発見に関するよくある質問
AIはSoftware Vulnerabilityを発見できますか？
はい。AIはSource Code Analysis、Security Hypothesis Generation、Attack-Path Explorationを支援でき、未知のVulnerability Candidateを発見する研究にも利用されています。ただしCandidateはTechnical Validationが必要です。
AIはZero-Day Vulnerabilityを見つけられますか？
Frontier ModelはPreviously Unknown VulnerabilityのDiscoveryを支援するCapabilityを示し始めています。ただしZero-Day CandidateもReachability、Exploitability、ImpactのHuman Validationが必要です。
AIはPenetration Testerを置き換えますか？
完全な置き換えよりHybrid Workflowが現実的です。AIはCode AnalysisやHypothesis Generationを高速化し、人間はAuthorization、Runtime Testing、Business Logic、Exploitability Validation、Impact Assessmentを担当します。
AIはVulnerability Researcherをどう支援しますか？
未知のCodeを理解し、Function間のRelationを追跡し、Candidate Weaknessを生成し、Attack SurfaceをPrioritizeし、Related Code Pathを調査する作業を高速化できます。
なぜAI FindingにHuman Validationが必要なのですか？
ModelはCode ExecutionやRuntime Constraintを誤解し、False Positiveを生成する可能性があります。ResearcherはReachability、Attacker Control、Prerequisite、Practical ImpactをEvidenceで確認します。
AIはPatch作成にも使えますか？
はい。AIはPatch Analysis、Related Code Discovery、Remediationの理解を支援できます。元記事ではDARPA AI Cyber ChallengeやProject GlasswingをDiscoveryとPatchingの両方へAIを活用する例として紹介しています。
AIはCyberattackを容易にしますか？
AIはDefensive CapabilityとOffensive Capabilityの両方を高める可能性があります。そのためDefender側はPre-Release Security、Strong Authorization、Rapid Remediationなどの基礎Security Practiceを強化する必要があります。
企業はいつAI-assisted Security Testingを使うべきですか？
Secure Development、Pre-Release Review、Penetration Testing、Vulnerability Research、Remediation、Retestingの各段階で利用できます。High-Risk ProductではAI Analysisだけに依存せず、Controlled Manual Validationと組み合わせるべきです。
