A finding in Pensar Apex represents a confirmed security vulnerability discovered during penetration testing. Findings include detailed evidence, proof-of-concept exploits, impact analysis, and remediation guidance.Pensar Apex uses a sophisticated deduplication system to prevent reporting the same vulnerability multiple times, even when multiple agents test the same target concurrently.
{ "title": "SQL Injection in User Search Endpoint", "severity": "CRITICAL", "description": "The /api/users/search endpoint accepts a 'query' parameter that is directly interpolated into a SQL query without sanitization or parameterization. An attacker can inject arbitrary SQL to read, modify, or delete database contents.", "impact": "An unauthenticated attacker can extract the entire user database, including password hashes, email addresses, and personal information. They can also modify or delete data, potentially taking over administrator accounts or causing data loss.", "evidence": "Injecting ' OR '1'='1 into the query parameter returned all users in the database (1,247 records). Injecting '; DROP TABLE users; -- caused a 500 error indicating SQL execution.", "endpoint": "https://example.com/api/users/search?query=test", "pocPath": "pocs/sql-injection-user-search-1234567890.py", "remediation": "1. Use parameterized queries or an ORM to prevent SQL injection\n2. Implement input validation and sanitization\n3. Apply principle of least privilege to database user\n4. Enable WAF rules to detect SQL injection attempts\n5. Conduct security code review of all database query construction", "references": "OWASP Top 10 2021 - A03 Injection\nCWE-89: SQL Injection\nhttps://portswigger.net/web-security/sql-injection", "toolCallDescription": "document_vulnerability"}
Severity is automatically normalized by the FindingsRegistry using a preprocessing step that maps various severity formats to the canonical CRITICAL/HIGH/MEDIUM/LOW scale.
Every finding must include a working proof-of-concept script that reliably demonstrates the vulnerability. POCs are stored in the session’s pocs/ directory.
Finding 1: “SQL Injection vulnerability in user search”
Finding 2: “Database query injection in user lookup endpoint”
Result: Deduplicated by LLM (different wording, same vulnerability)
Semantic deduplication is conservative: when in doubt, it allows the finding through. It’s better to have a borderline duplicate than to suppress a genuinely new vulnerability.
The FindingsRegistry is the central component for managing findings:
export class FindingsRegistry { /** How many findings are tracked */ get size(): number /** Return a snapshot of all tracked findings */ getFindings(): readonly Finding[] /** Check if a finding is a duplicate (synchronous, Tier 1+2) */ isDuplicate(finding: Finding): DuplicateCheckResult /** Register a new finding (async, includes Tier 3) */ async register(finding: Finding): Promise<DuplicateCheckResult> /** Remove a finding (e.g., if persistence failed) */ async unregister(finding: Finding): Promise<void>}
The FindingsRegistry is thread-safe and supports concurrent agent testing:
// Multiple agents can safely register findings concurrentlyconst registry = new FindingsRegistry({ model: "claude-sonnet-4-20250514" });// Spawn multiple pentest agentsconst results = await Promise.all( targets.map(async (target) => { const agent = new TargetedPentestAgent({ target: target.url, objectives: [target.objective], model: "claude-sonnet-4-20250514", session, findingsRegistry: registry, // Shared registry }); return agent.consume(); }),);// No duplicate findings, even though agents ran concurrentlyconsole.log(`Total unique findings: ${registry.size}`);
The registry uses a promise-based mutex internally to serialize concurrent register() calls while keeping the LLM semantic check outside the critical section for performance.
