AI Validation & Intent Analysis
Relevant source files
The following files were used as context for generating this wiki page:
AI Validation and Intent Analysis represent the core intelligent layer of the Enhanced Security Scanner v2.0. This system moves beyond traditional Static Application Security Testing (SAST) by utilizing Large Language Models (LLMs) to verify potential vulnerabilities and analyze developer intent versus actual implementation. This multi-phase approach aims to reduce the industry-standard high false positive rates to less than 5%.
Sources: README.md:4-10, README.md:21-25
3-Phase Scanning Strategy
The scanner employs a tiered architecture where AI analysis acts as a secondary and tertiary filter for high-noise data produced by traditional tools.
- Phase 1: Traditional SAST: Utilizes Semgrep and CodeQL with permissive/high-noise queries to ensure maximum coverage and catch potential entry points.
- Phase 2: AI-Enhanced Analysis: Executes multi-scan iterations to address the non-deterministic nature of AI, validating findings from Phase 1.
- Phase 3: Targeted Deep Dives: Performs complex multi-file analysis, intent analysis, and business logic detection for critical findings.
Sources: README.md:16-25, README.md:65-79
Scanning Data Flow
The following diagram illustrates how a finding progresses from initial detection to AI-validated result.
The flow ensures that non-deterministic AI outputs are mitigated through three iterations (Phase 2) before deep context-aware analysis (Phase 3).
Sources: README.md:21-25, README.md:195-200
AI Validation Mechanics
Multi-Scan Strategy
To handle LLM non-determinism, the system runs three iterations by default. This ensures that a finding is not a fluke of a specific model prompt execution. The aiEnhanced configuration allows for custom iteration counts and provider selection (OpenAI, Anthropic, or AWS Q Developer).
Sources: README.md:22-24, README.md:120-125
Validation Logic & Prompts
The AI is provided with structured data regarding the finding, including the category, severity, file location, and the specific code snippet. It is tasked with answering four critical questions:
- Is the finding a True Positive (TP) or False Positive (FP)?
- What is the exploitability (on a 0-1 scale)?
- What is the potential impact?
- What are the specific remediation steps?
Sources: README.md:195-212
const validationPrompt = `
Analyze this security finding:
FINDING:
- Type: ${finding.category}
- Severity: ${finding.severity}
- File: ${finding.file}:${finding.line}
- Code: ${finding.snippet}
...
`;
Sources: README.md:197-205
Intent Analysis
Intent Analysis is a specialized capability within Phase 3 that detects discrepancies between what a developer documents (via comments) and what the code actually performs. This is particularly effective for catching backdoors or logic errors.
Business Logic Detection
The system analyzes multi-file vulnerability flows and compares developer comments against implementation. For example, if a function header states it validates a password but the implementation returns true unconditionally, the Intent Analysis engine flags this as a High-severity finding.
Sources: README.md:25-27, README.md:215-220
Example: Intent Mismatch
// Detects mismatches between comments and implementation
function authenticateUser(password) {
// TODO: Add password validation
return true; // 🟠 HIGH: Always returns true, ignoring password
}
Sources: README.md:215-220
Configuration Options
The AI Validation and Intent Analysis components are highly configurable via the aiAnalysis and phases sections of the configuration file.
| Configuration Key | Type | Description | Default |
|---|---|---|---|
aiEnhanced.enabled | Boolean | Enables Phase 2 AI-enhanced validation | true |
aiEnhanced.iterations | Number | Number of AI scans to run (mitigates non-determinism) | 3 |
deepDive.intentAnalysis | Boolean | Enables analysis of comments vs implementation | true |
aiAnalysis.provider | String | AI Model provider (openai, anthropic, aws) | openai |
aiAnalysis.model | String | Specific model used for analysis | gpt-4 |
Sources: README.md:118-135, configs/default.json:20-40
Integration with Core Components
The AI analysis is orchestrated by the MultiScanOrchestrator and processed into the standard SARIF format via the SARIFProcessor.
- MultiScanOrchestrator: Manages the three-phase execution and AI iterations.
- SARIFProcessor: Merges results from traditional SAST and AI validation into a unified, machine-readable format for CI/CD consumption.
Sources: src/index.ts:7-10, README.md:237-245
This class relationship shows the MultiScanOrchestrator as the central hub for the multi-phase strategy.
Sources: src/index.ts:7-10, CONTRIBUTING.md:15-25
Detection Capabilities
AI Validation is applied to critical CWE classes to ensure high accuracy in high-stakes environments.
- CWE-78 (OS Command Injection): Validates if user input actually reaches a sink like
os.system. - CWE-89 (SQL Injection): Analyzes string concatenation context to differentiate between safe constants and unsafe user input.
- React Context Exposure: Specifically looks for secrets (API keys, tokens) hardcoded in React Context or Hooks.
Sources: README.md:158-165, rules/react/hooks.yml:1-15
Conclusion
By combining multi-iteration AI validation with intent-based analysis, the scanner significantly reduces developer fatigue caused by false positives. The system's ability to cross-reference code implementation with developer documentation (Intent Analysis) provides a layer of security that traditional SAST tools cannot achieve, specifically targeting complex business logic vulnerabilities and malicious code detection.
Sources: README.md:21-30, CHANGELOG.md:13-15