--- title: AI-Powered File Analysis description: How CodeDD analyzes individual source files category: Software Audit order: 4 --- # AI-Powered File Analysis CodeDD's file analysis stage reviews each scoped file for quality, security, and maintainability — surfacing issues that pattern-only scanners often miss. ## Beyond traditional SAST Traditional static analysis relies on pattern matching and syntax rules. CodeDD adds **semantic understanding**: business logic review, intent-based risk detection, and context from file type and role in the system. Security findings go through a **validation step** that checks for supporting evidence before they affect your score. Optional SonarQube integration adds language-specific static rules when enabled. ## What gets analyzed **Application code** — business logic, APIs, database access, auth, validation, error handling. **Infrastructure** — Dockerfiles, Kubernetes manifests, CI/CD configs, IaC templates. **Configuration** — app settings, environment files, third-party integrations. ## File selection Deep analysis runs on files marked in **audit scope**. Priority goes to security-critical paths, core business logic, recently modified files, and high-complexity code. Excluded: auto-generated code, minified files, binaries, and test fixtures. ## Per-file assessment Each analyzed file receives structured scores across dimensions you see in the dashboard: | Area | What it covers | |------|----------------| | Code quality | Readability, consistency, modularity, maintainability, technical debt | | Functionality | Completeness, edge cases, error handling | | Performance | Efficiency, scalability, resource use | | Security | Input validation, data handling, authentication | | Standards | Best practices, design patterns, complexity | Findings include severity (Green / Yellow / Orange / Red), confidence level, and specific remediation guidance. ## Security findings Common categories: injection flaws, XSS vectors, auth bypasses, insecure cryptography, exposed secrets, sensitive data handling. Each Red or Orange security flag is checked by the AI validator, which records a verdict with a confidence score. The Security / Flags tab shows one of four states: **Confirmed** (the validator or a reviewer confirmed the finding), **Refuted by AI** (shown with the validator's conclusion, confidence and, when it found one, the mitigating code), **Inconclusive** (the validator could not decide) and **Not validated** (no verdict; Yellow findings are informational and are not validated). Inconclusive and not-validated findings count as open until a reviewer decides; refuted findings are left out of the totals and reported as "Dismissed by AI validation" so they are never dropped silently. A reviewer can confirm or dismiss any finding. ## Dependency analysis CodeDD scans package manifests and imports across major ecosystems (npm, pip, Maven, Go modules, Cargo, Composer, .NET, and others). Each import is attributed to the declared package that ships it, and the files that import a package count as its usage. A PHP namespace goes through the autoload map of `composer.lock` (`Doctrine\ORM\…` counts for `doctrine/orm`, `GuzzleHttp\Psr7\…` for `guzzlehttp/psr7`). A Ruby require path, Go import path or Python module goes through the declared gems, modules and distributions. A Java package or .NET namespace goes through its declared artifact. In a Flutter app, the plugins that the iOS, macOS, Linux, Windows and Android host projects import count for their pub packages. PHP's own namespaces (such as `Random\`) and the Flutter engine count as the standard library. An import that matches no single declared package is listed on its own: **Namespace** when several declared packages share it (a vendor namespace such as `Symfony` in a project without a lock file), **Not declared** when the code uses it but no manifest declares it. Neither has a declared version, so neither is checked for vulnerabilities. For each dependency: - Version and known vulnerabilities (CVE and other advisory IDs) - Severity and patch availability - Exploit likelihood signals (CISA KEV, EPSS) - License type and compliance flags ### Vulnerability data sources - **OSV (primary):** [OSV.dev](https://osv.dev) aggregates the GitHub Advisory Database, PyPA, RustSec, the Go vulnerability database, and others. CodeDD queries it for each package at its exact resolved version, so results reflect what is installed, not every advisory ever filed against the package. - **GitHub Advisory Database (fallback):** used only when OSV does not answer for a package in a supported ecosystem. - **Exploit intelligence:** findings are enriched with the CISA Known Exploited Vulnerabilities (KEV) catalog and FIRST's Exploit Prediction Scoring System (EPSS). This adds context for prioritization and never changes the vulnerability count. A package is reported as scanned only when a source answered for an exact version. Packages with an unresolved version, an unsupported ecosystem, or a failed lookup are shown with that status, never as "0 vulnerabilities". The Dependencies tab's **Export CSV** lists the same packages as the table, including declared packages that no file imports. Extra columns show the import names a package is used under (`imported_as`) and, for a name that is only imported, what it is (`import_status`). Portfolio views include a **Supply Chain Vulnerabilities** panel and **License Compliance** section. ## Complexity metrics Cyclomatic complexity is calculated per function using Radon/Lizard. High-complexity functions (typically 20+) are flagged as refactoring candidates and contribute to technical debt signals. ## SonarQube (optional) When enabled, SonarScanner runs in an isolated container against a temporary workspace. Results are merged with AI findings. The workspace is deleted after analysis. ## Data privacy After analysis: - **Stored:** file paths, metrics, findings, dependency lists, complexity scores - **Never stored:** source code content, detected secrets (flagged but not persisted), PII from comments ## Next steps - [Cross-File Contextualization](/documentation/cross-file-contextualization) - [Audit Consolidation & Risk Scoring](/documentation/audit-consolidation-risk-scoring) - [Architecture Analysis & Mapping](/documentation/architecture-analysis-mapping)