Source code scans

Source scans inspect uploaded source files, archives, and Git repositories. They are designed for application code, infrastructure code, services, plugins, and libraries.

Use source scanning when the most important evidence is in control flow, data flow, authorization checks, framework configuration, dependency use, or code review context.

Source scans begin with repository, archive, and note selection so the worker plan starts from the code paths and review context you care about.

When source scans are the right tool

Source scans are strongest when you need to answer questions like:

• Can a user cross an account, tenant, project, or role boundary?
• Does user-controlled input reach a command, file path, URL fetch, parser, or template sink?
• Are secrets, tokens, or signing keys handled safely?
• Did a recent pull request change a security boundary?
• Does the code implement the policy that the product assumes?

They are weaker when the relevant behavior only appears after deployment, packaging, gateway configuration, or runtime authentication. Pair the scan with a binary or remote scan when those surfaces matter.

Inputs

You can provide:

• individual source files
• archives such as .zip, .tar, and .tar.gz
• public Git repositories over HTTPS
• private Git repositories using saved account credentials

Archives are expanded automatically. Git repositories are cloned into an isolated scan workspace for the duration of the assessment.

For repeatable work, prefer Git URLs over one-off uploads. Git-backed scans can support lineages, rescans, and CI delta scans more naturally.

What agents inspect

The coordinator maps the repository or prepared workspace, then dispatches source-focused workers. Workers look for issues such as:

• authentication and authorization bypasses
• injection paths and unsafe command execution
• SSRF and unsafe URL fetches
• deserialization and parser risks
• secret handling and token exposure
• tenant isolation failures
• unsafe file, path, and archive handling
• dependency or framework use with known CVEs

Findings should include concrete source locations when the evidence comes from code.

Good source-scan notes

Good notes identify the business boundary or recent change, not just a file name. Examples:

Focus on project membership and billing entitlement checks. Treat cross-account
data access as critical.

This scan supports a release gate for the SAML callback rewrite. Follow the
callback through user lookup, session creation, and role assignment.

CI delta scan. Prioritize changed files and nearby call paths into webhook
signature verification, retry handling, and replay protection.

When you have no specific focus, say what the product does and which assets are most sensitive.

Scan settings

Setting	Use it for
Model	Selects the LLM runtime for coordinator, worker, triage, and artifact steps.
Notes / focus	Adds operator guidance to the coordinator prompt.
Coordinator step budget	Raises or lowers the maximum coordinator turns. Higher budgets can improve coverage and increase cost.
Batch API	Uses batch artifact generation where available. It is cheaper but finalization can take longer.
HackerOne review	Labels findings against HackerOne core-ineligible categories when disclosure tracking is enabled.
Adversarial vendor review	Runs a skeptical vendor-style challenge and researcher rebuttal pass to improve confidence scoring.

Private repositories

Add credentials under Account > Git Access before starting the scan. See Private repositories for credential behavior and CI usage.

Delta scans from CI

The public API supports source scans for CI. With auto_delta enabled, the first scan is a full scan and later scans can focus on changed files for the same Git URL set.

See GitHub Actions for a working pattern.

Common next steps

• For release reviews, pair source evidence with Binary artifact scans.
• For deployed authorization or SSRF behavior, add a Remote target scan.
• For recurring scans, use Continuous CI scanning.
• After a finding lands, use Triage to remediation.