Skip to main content

Code Audit

Code Audit is AISafe's whitebox security assessment type. AI agents with static analysis examine your source code for vulnerabilities, taint flows, misconfigurations, and insecure patterns across Python, JavaScript/TypeScript, Go, Rust, Java, Kotlin, C++, C#, Ruby, PHP, and more.

How it works​

Starting a code audit triggers a multi-agent workflow that moves through several stages. Specialized agents carry out each stage, collaborating on the code graph. Each stage builds on the previous one. The agents share context, so the audit stage benefits from the analysis stage's understanding of your codebase.

  1. Understanding: the agents acquire your source and build a structural model of the codebase: entry points, frameworks, data flows, and trust boundaries. This model enables taint analysis, call graph traversal, and cross-file data flow tracking.
  2. Analysis: the agents follow data flows from source to sink, noting where user input enters the system, where the system sanitizes it (or fails to), and where it reaches a sensitive operation. They map authentication checks, authorization boundaries, and configuration to understand where the application enforces security, and form hypotheses about where vulnerabilities might live.
  3. Audit: for each candidate vulnerability, an agent traces the full path from source to sink, checks for sanitization or validation that would block exploitation, and produces evidence: the vulnerable code locations, the taint flow, and a proof-of-concept description. The agent iterates on hypotheses, discarding dead ends and confirming real issues. The audit stage produces most findings.
  4. Triage: a separate triage agent re-examines each finding's evidence, confirms or rejects it, deduplicates findings that share a root cause, and assigns a confidence score. This pass is what keeps the false-positive rate low and the backlog clean.
  5. Report: the final stage compiles confirmed findings, evidence, and remediation guidance into a shareable PDF.

The entire workflow runs without human intervention. You start the audit, the agents do the work, and you review the results when they are ready.

The duration of a code audit depends on the size and complexity of your codebase. Larger repositories with more files and deeper call graphs take longer because the agents have more ground to cover. You can monitor progress from the assessment detail page while the audit runs.

The agents reason about your code's behavior, follow data flows across files and functions, and test whether a hypothetical vulnerability is reachable. They find issues that traditional static analysis tools miss, including logic bugs and vulnerabilities that require understanding how multiple components interact.

Source input​

You can provide source via:

  • Connected repository: select a private repo from your GitHub/GitLab integration. AISafe mints a short-lived, repo-scoped installation token to clone the code at the revision you specify. AISafe discards the token after the audit completes and retains no persistent access.
  • Public repository URL: enter a public https://github.com/{owner}/{repo} URL. AISafe accesses it through the public API and clones the default branch (or a specific commit or branch if you provide one). This is the quickest way to audit an open-source project.
  • Uploaded archive: upload a tar.gz of your codebase. This is useful when your code is not in a supported git host, or when you want to audit a specific snapshot you have not pushed to a remote. The archive should contain the full project tree so the agents can resolve cross-file dependencies.

Whichever option you choose, AISafe extracts the source into an isolated environment and builds the code graph from it. The agents retain no access to your repository after the audit finishes. The code graph resolves dependencies, so you do not need to install packages or run a build before uploading.

When dependency metadata includes exact versions, AISafe checks those packages against OSV. Vulnerable dependencies are promoted to first-class SCA findings, mapped to OWASP A06:2021 Vulnerable and Outdated Components and CWE-1395 by default. They are presence-based advisory findings: they are triageable, reportable, exportable, and included in compliance mapping, but they do not claim that the vulnerable function is reachable unless a separate code finding proves reachability.

Findings and evidence​

Code audit excels at detecting:

  • Injection vulnerabilities: SQL injection, command injection, SSRF, LDAP injection, path traversal. The agents trace user-controlled input from where it enters the application to where it reaches a query, command, or request.
  • Authentication and authorization flaws: broken access control, privilege escalation, missing auth checks. The agents identify where the application should enforce security checks and where those checks are absent or bypassable.
  • Secrets and credentials: hardcoded API keys, tokens, and passwords. The agents scan for patterns that look like credentials and confirm whether they are real.
  • Cryptographic weaknesses: weak algorithms, insecure random number generation, improper key management. The agents flag uses of deprecated or insecure crypto primitives.
  • Deserialization and serialization issues: unsafe deserialization, XML external entity (XXE). The agents trace data flows into deserialization sinks and check whether the input is trusted.
  • Logic bugs: race conditions, business logic flaws, state manipulation. The agents reason about the application's intended behavior and look for ways to subvert it.
  • Vulnerable dependencies: exact-version OSV advisories for application dependencies. AISafe anchors them to the manifest or lockfile and suggests an upgrade path without fabricating an exploit proof.

For each confirmed finding, the agents provide:

  • Vulnerable locations: the exact file, function, and line range where the issue lives, so you can jump straight to the code.
  • Taint flow: the full path from source (where untrusted data enters) to sink (where it reaches a sensitive operation), including any sanitization or validation that is missing or insufficient. This shows you how the vulnerability is reachable.
  • Proof-of-concept: a description of how an attacker could exploit the vulnerability, grounded in the actual code. This helps you understand the real-world impact without needing to trace the flow yourself.
  • Suggested fix: a concrete remediation recommendation. It includes a code snippet showing the corrected pattern where useful. You can use this as a starting point for your patch.

The agents map each finding to a standard category (CWE or OWASP) where applicable, so you can cross-reference with your existing security tracking and compliance frameworks.

Steering​

Provide additional instructions to guide the agents toward what matters most to you (e.g. "focus on high-severity vulnerabilities that map to a CVE" or "prioritize logic bugs over input validation in this mature library"). Steering cannot override scope or safety rules.

Steering is optional. If you leave it blank, the agents apply their default coverage across all vulnerability categories. Use steering when you have a specific concern, a compliance requirement, or context about your application that the agents would not infer from the code alone.

For example, if you know that a particular module handles payment processing, you can steer the agents to spend extra effort there. If you are auditing a library, you can steer them to focus on the public API surface.

Steering is most effective when it provides context the agents cannot infer from the code: business rules, compliance requirements, or known threat models.