Codebase scans

Codebase scans are how you ship fast with confidence. They catch deep, serious issues across your codebase before they slip into production. cubic deploys 1,000s of specialized AI agents across your codebase to detect and fix bugs and security vulnerabilities. Scans run separately from synchronous PR reviews. Even with AI reviews on every PR, most of your codebase was written before you had review coverage, or was reviewed years ago under different standards. Scans find issues in that existing code: business logic errors, data corruption risks, race conditions, edge cases that break functionality, plus security issues like hardcoded secrets and dependency vulnerabilities. Auto-fix can automatically create fix PRs for eligible issues. Unlike PR reviews that check diffs in minutes, codebase scans run thousands of checks across your repository in the background. They take hours (sometimes 24+ for large codebases), and you can keep working while they run.

​

The overnight workflow

1. You push code at the end of the day
2. cubic agents spend the night scanning (often 6 to 12 hours)
3. You wake up to high confidence findings and (optionally) auto created fix PRs (with reviewers assigned based on your settings)
4. Review and merge the PRs in the morning

​

What you get

• High impact, high confidence findings: agents focus on serious issues and investigate each potential finding before it shows up in your results.
• Issue ownership + routing: each finding is attributed to an issue owner so it lands with the right person or team.
• Learns from your team: scans apply learnings from PR reviews, and you can steer scans with custom instructions and triage feedback.
• Auto-fix and routing: Auto-fix can create PRs for eligible, easier to fix issues. For everything else, notify the owner in Slack or email, or create Jira or Linear tickets.

​

Issues that codebase scans find

Codebase scans focus on high impact issues:

• Business logic flaws: billing edge cases that lose money, incorrect permission checks, broken invariants, off by one errors
• Data integrity risks: race conditions that corrupt state, missing validations, unsafe database operations
• Edge cases: null pointer exceptions, unhandled error paths, boundary conditions that break functionality
• Secret scanning: hardcoded API keys, credentials, tokens, and other secrets that should not be in your codebase
• Vulnerability scanning: known CVEs in your dependencies, unsafe version ranges, and security advisories
• Infrastructure as Code scanning: misconfigurations in Terraform, Kubernetes manifests, Dockerfiles, and CloudFormation templates
• Security vulnerabilities: authentication bypasses, injection points, insecure configurations

Unlike traditional scanners that flood you with noise, every finding is investigated by AI agents before being reported. This means you see only actionable issues, not a backlog of false positives to triage.

​

How it works

cubic clones your repository into an isolated sandbox and deploys thousands of agents that explore your codebase in parallel. These agents:

• Navigate across files to trace data flows
• Follow call chains to verify issues
• Check external documentation (framework docs, security advisories)
• Access up to date documentation for the libraries and frameworks in your stack
• Apply learnings from PR reviews (feedback from your team, senior reviewers, and prior corrections) so scans reflect your codebase’s standards
• Test multiple hypotheses before confirming findings
• Use your repository’s AI Wiki to understand product context and prioritize investigations

The scan process:

1. Maps your repository structure
2. Checks for an up to date AI Wiki. If one doesn’t exist, cubic generates it automatically
3. Deploys thousands of parallel agents informed by the wiki’s understanding of your product
4. Investigates suspicious patterns
5. Deduplicates findings
6. Scores by severity and confidence

This takes hours because agents verify each finding across files and external sources. The result is high confidence issues you can immediately act on.

​

Continuous scans (diff based)

Scheduled scans are designed to be continuous: after your first scan, subsequent scheduled runs focus on what changed since the last successful scan. If there are no changes to scan, the scheduled run can be skipped automatically.

​

Why findings are actionable

Traditional static analysis tools are notorious for false positives. That includes security scanners, dependency scanners, secret scanners, and rule based linters. Teams report that up to 90% of findings can turn out to be non issues when investigated in context. cubic takes a different approach. Instead of pattern matching and dumping results, AI agents investigate each potential issue:

• Contextual analysis: Agents assess whether a finding is real and impactful in your specific codebase
• Cross reference verification: Findings are validated against actual code paths, not just syntactic patterns
• Severity scoring: Only issues that pass investigation are reported, with confidence scores based on evidence

The result: high signal findings you can act on immediately, not another backlog to triage.

​

Starting a scan

Codebase scans are available by request. Once enabled:

1. Navigate to your repository’s Codebase scan page
2. Click Start scan
3. Continue working. Scans run in the background

​

Working with results

Every finding appears in a sortable, filterable table:

• Issue: summary of what’s wrong, plus file path and line number
• Category: Security, Business logic, Data integrity, or Stability
• Owner: the issue owner, the person or team that should own the fix
• Risk: a combined score (severity + reachability + likelihood)
• Fix effort: estimated difficulty to fix (1 to 10)
• Status: Open, In review, Resolved, False positive, Won’t fix, or Accepted risk

Filter by status, category, or owner. Sort by any column.

​

Owner attribution

cubic automatically identifies who’s responsible for each finding using your repository’s CODEOWNERS file. This lets you route issues to the right team, for example @frontend-team, @security, or a specific engineer. If your repository has a CODEOWNERS file (in the root, .github/, or docs/ directory), cubic uses it to determine ownership. If no CODEOWNERS match exists, cubic falls back to git history attribution. This is especially useful for large codebases where different teams own different parts of the code. Filter by owner to see only your team’s issues, or export filtered results to share with specific teams.

​

Notify issue owners

You can notify owners when scans find issues in their code, via:

• Email notifications
• Slack DM notifications (when Slack is connected)

​

Auto resolution

Scan violations don’t just sit there forever. When a PR is merged that fixes a scan finding, whether intentionally or as a side effect of other work, cubic automatically detects the resolution and marks the violation as resolved. Here’s what happens:

1. A PR merges into your default branch
2. cubic checks the merged diff against any open scan violations in the affected files
3. AI agents analyze whether the code change actually fixes each issue
4. Resolved violations are marked with an audit trail: which PR fixed it, which commit, and an AI generated explanation of how the fix addresses the original finding

This means your scan results stay current without manual triage. Issues that your team fixes through normal development work are automatically cleared, so your open violations list always reflects what’s actually still a problem. Click any issue for:

• Full explanation with code context
• AI sidebar to explore the finding interactively
• Copy prompt button for a ready to paste fix prompt
• Create Jira/Linear tickets to track remediation work
• Fix with Cursor to open a prefilled prompt in Cursor

​

One click fix

cubic makes it easy to fix issues directly. No need to context switch to your IDE or dig through files. Just select the issues you want fixed and let cubic handle it. The fastest way: use multi select to fix many issues at once.

1. Use the checkboxes to select issues in the results table
2. Click Fix with cubic in the bulk actions bar
3. cubic spins up background agents that investigate each issue, then create PRs with fixes

Each issue gets its own PR, so you can review and merge them independently. The fixes run in parallel in the background. You can close the tab and come back later. You can also fix issues one at a time from the issue details panel. Click any issue, then click Fix with cubic in the toolbar.

​

Create Jira or Linear tickets

If your repo is connected to Jira or Linear, you can create tickets directly from a finding.

​

Fix with Cursor

From the violation actions menu, choose Fix with Cursor to open Cursor with a prefilled prompt containing the issue summary, analysis, and relevant code context.

​

Auto remediation

Auto remediation takes the one click fix concept further: cubic automatically creates PRs for your highest risk violations without any manual intervention. When a scan completes, cubic evaluates each violation against your configured guardrails (risk, confidence, category, max fix difficulty) and triggers fixes for eligible issues. PRs are created in the background, with reviewers automatically assigned based on your settings.

​

Scheduling scans

Most teams run scans on a daily or monthly cadence:

• Daily scans: best for fast-moving repos that want continuous coverage
• Monthly scans: a lightweight option for steady repos (and a good default to start)
• On demand scans: before major releases, after architecture changes, post dependency updates

To schedule recurring scans, go to your repository’s Codebase scan page and configure the schedule dropdown.

​

Custom instructions

Guide what cubic focuses on during scans. Custom instructions let you define security invariants, baseline policies that should always hold true in your codebase. Security & compliance examples:

• “All traffic must be encrypted, flag any HTTP endpoints without TLS”
• “Storage in infrastructure as code must have encryption enabled”
• “All user input must pass through our sanitize() function before database queries”
• “Authentication tokens must never be logged or exposed in error messages”

Focus & context examples:

• “Focus on authentication flows and payment processing”
• “We use a custom ORM that wraps Prisma, account for this in SQL injection checks”
• “Our validatePermissions() helper is the authoritative access control check”

To configure:

1. Go to your repository’s Codebase scan page
2. Click the schedule dropdown, then Custom instructions
3. Enter your instructions (up to 10,000 characters)
4. Save

Your instructions apply to all scans, both manual and scheduled. This is especially valuable for compliance teams who need to enforce specific security requirements across the codebase without writing unit tests for each policy.

---

​

FAQ