/**
 * Detector Tier System
 *
 * Provides a shared language for "how much we trust this detector" so we can:
 * - Filter findings in runScan by tier + depth
 * - Log tier breakdowns for tuning
 * - Route AI validation budget toward Tier B
 *
 * Security reasoning:
 * - Makes it explicit which detectors are safe to expose in cheap scans
 * - Avoids "accidental promotion" of an experimental heuristic to production output
 */
import type { VulnerabilityCategory } from './shared/types';
/**
 * Detector tiers control visibility and trust level:
 *
 * - core: High-precision SAST + core AI-safety detectors. Visible in all scan depths.
 * - ai_assisted: Context-heavy heuristics that need AI validation. Shown in validated/deep.
 * - experimental: High-noise signals used only for internal scoring/AI hints. Hidden from users.
 */
export type DetectorTier = 'core' | 'ai_assisted' | 'experimental';
/**
 * Tier statistics for logging and analysis
 */
export interface TierStats {
    core: number;
    ai_assisted: number;
    experimental: number;
}
/**
 * Layer 1 detector names (internal identifiers matching detector function names)
 */
export type Layer1DetectorName = 'known_secrets' | 'weak_crypto' | 'sensitive_urls' | 'entropy' | 'config_audit' | 'file_flags' | 'ai_comments';
/**
 * Layer 1 tier assignments
 *
 * Tier A (core):
 *   - known_secrets: Hardcoded secrets are objectively bad and high-impact
 *   - weak_crypto: Weak crypto is a classic SAST finding with clear remediation
 *   - sensitive_urls: Hardcoded webhook URLs + tokens are real data exfil vectors
 *
 * Tier B (ai_assisted):
 *   - entropy: Great at finding candidates, needs AI to separate real secrets from noise
 *   - config_audit: Depends on project norms; better reviewed with AI + project context
 *   - file_flags: Subjective items should be AI-triaged (except committed .env = Tier A)
 *
 * Tier C (experimental):
 *   - ai_comments: Not directly a vuln; belongs in separate "AI hygiene" report
 */
export declare const LAYER1_DETECTOR_TIERS: Record<Layer1DetectorName, DetectorTier>;
/**
 * Mapping from vulnerability category to Layer 1 detector name
 * Used for tier lookups when we only have the category
 */
export declare const LAYER1_CATEGORY_TO_DETECTOR: Partial<Record<VulnerabilityCategory, Layer1DetectorName>>;
/**
 * Layer 2 detector names (internal identifiers matching detector function names)
 */
export type Layer2DetectorName = 'dangerous_functions' | 'byok_patterns' | 'ai_execution_sinks' | 'ai_agent_tools' | 'auth_antipatterns' | 'data_exposure' | 'ai_fingerprinting' | 'ai_prompt_hygiene' | 'logic_gates' | 'variables' | 'risky_imports' | 'framework_checks' | 'ai_rag_safety' | 'ai_endpoint_protection' | 'ai_schema_validation' | 'ai_package_hallucination' | 'ai_mcp_security' | 'model_supply_chain' | 'security_headers' | 'ssrf_detection' | 'log_injection' | 'xxe_detection';
/**
 * Layer 2 tier assignments
 *
 * Tier A (core) - High-precision, high-risk, clear remediation:
 *   - dangerous_functions: Classic injection footholds (eval, exec, unsafe SQL)
 *   - byok_patterns: Storing/logging BYOK is critical AI-era customer trust risk
 *   - ai_execution_sinks: Core to Oculum's AI story; LLM output as code/commands
 *   - ai_agent_tools: Over-permissive tools are central AI alignment problem
 *
 * Tier B (ai_assisted) - Context-heavy, need AI validation:
 *   - auth_antipatterns: Very context-dependent; needs middleware awareness
 *   - data_exposure: Logging queries/user IDs is often acceptable but context-specific
 *   - ai_fingerprinting: TypeScript 'any' at trust boundaries is risk indicator, not vuln
 *   - ai_prompt_hygiene: Needs semantic understanding of prompt design
 *
 * Tier C (experimental) - High-noise, internal use only:
 *   - logic_gates: Many hits with limited actionable signal
 *   - variables: Generic token/password variable names - too generic
 *   - risky_imports: Most imports are fine; keep tiny whitelist if proved valuable
 *   - framework_checks: Many findings are style/low-risk; prone to noisy lint
 */
export declare const LAYER2_DETECTOR_TIERS: Record<Layer2DetectorName, DetectorTier>;
/**
 * Mapping from vulnerability category to Layer 2 detector name
 * Used for tier lookups when we only have the category
 *
 * NOTE: Some categories are used by multiple detectors:
 * - ai_pattern: used by ai-fingerprinting (Tier B), byok-patterns (Tier A), dangerous-functions (Tier A)
 * - insecure_config: used by config-audit (L1 Tier B), framework-checks (L2 Tier C)
 *
 * For ambiguous categories, we use the most conservative (highest trust) tier mapping.
 * When category alone isn't sufficient, the orchestrator can use detector-specific tracking.
 */
export declare const LAYER2_CATEGORY_TO_DETECTOR: Partial<Record<VulnerabilityCategory, Layer2DetectorName>>;
/**
 * Get the tier for a vulnerability based on its category and layer
 */
export declare function getTierForCategory(category: VulnerabilityCategory, layer: 1 | 2 | 3): DetectorTier;
/**
 * Get tier for a Layer 1 detector by name
 */
export declare function getLayer1DetectorTier(detector: Layer1DetectorName): DetectorTier;
/**
 * Get tier for a Layer 2 detector by name
 */
export declare function getLayer2DetectorTier(detector: Layer2DetectorName): DetectorTier;
/**
 * Check if a tier should be visible at a given scan depth
 */
export declare function isTierVisibleAtDepth(tier: DetectorTier, depth: 'local' | 'verified' | 'deep'): boolean;
/**
 * Check if a tier should go through AI validation at a given scan depth
 */
export declare function shouldValidateWithAI(tier: DetectorTier, depth: 'local' | 'verified' | 'deep'): boolean;
/**
 * Compute tier statistics from an array of vulnerabilities
 */
export declare function computeTierStats(vulnerabilities: Array<{
    category: VulnerabilityCategory;
    layer: 1 | 2 | 3;
}>): TierStats;
/**
 * Format tier stats for logging
 */
export declare function formatTierStats(stats: TierStats): string;
//# sourceMappingURL=tiers.d.ts.map