Codebase scans

Codebase scans analyze your entire repository to find bugs hiding in existing code, and fix them in one click. 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 surface issues in that existing code: hardcoded secrets, dependency vulnerabilities, security flaws, data corruption risks, and business logic errors. Unlike PR reviews that check diffs in minutes, codebase scans run thousands of checks across your entire repository. They take hours (sometimes 24+ for large codebases) but run in the background.

​

Issues that codebase scans find

Codebase scans focus on high-impact issues:

• Secret scanning: hardcoded API keys, credentials, tokens, and other secrets that shouldn’t be in your codebase
• Vulnerability scanning: known CVEs in your dependencies, unsafe version ranges, and security advisories
• Infrastructure-as-Code scanning: security misconfigurations in Terraform, Kubernetes manifests, Dockerfiles, and CloudFormation templates, like public S3 buckets, open security groups, unencrypted databases, and privileged containers
• Security vulnerabilities: authentication bypasses, injection points, insecure configurations
• Data integrity risks: race conditions that corrupt state, missing validations, unsafe database operations
• Business logic flaws: billing edge cases that lose money, incorrect permission checks, broken invariants

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, that you can immediately act on.

​

Why findings are actionable

Traditional security scanners are notorious for false positives. Teams report that up to 90% of findings from rule-based tools 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 vulnerability is actually exploitable 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. You’ll be notified when results arrive

Remember: this is background analysis. Start a scan before leaving for the day, check results in the morning.

​

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: who’s responsible for the code (from CODEOWNERS file, or git blame if no CODEOWNERS)
• Fix effort: estimated difficulty to fix (1-10)
• Status: Open, Resolved, or Dismissed
• Severity: how critical the issue is (1-10)

Filter by status tab (Open/Resolved/Dismissed), 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—whether that’s @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 blame to show who last modified the code. 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. 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.

​

When to run scans

Scan frequency depends on your security requirements: Daily scans (recommended for teams with strict SLAs):

• Critical vulnerability SLAs under 48 hours require daily dependency scanning
• Ensures new CVEs are caught within your response window

Weekly scans (standard cadence):

• Good balance of coverage and cost for most teams
• Catches issues before they accumulate

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 → 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