Source code scans

Source scans inspect uploaded source files, archives, or 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.

The first wizard step chooses exactly one source path: connected GitHub, manual Git URLs, or a browser upload.

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?
• Which pinned dependency versions have a known advisory, and is the vulnerable code actually called?

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

Choose one input path for each scan:

• Connected GitHub repo for repositories granted to the ZeroQuarry GitHub App
• Add Git URLs for public repositories on any supported forge, or private repositories using a saved account credential
• Upload source code for individual files or archives such as .zip, .tar, and .tar.gz

A public repository needs no credential on any supported forge: GitHub, GitLab, Bitbucket, or a Gitea or Forgejo instance. ZeroQuarry confirms each one with the hosting forge's own unauthenticated API rather than inferring it from the URL.

If the project already has a repo asset, the form pre-fills from it — URL, ref, and saved credential — and the scan is linked back to that asset so its coverage history stays in one place.

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

The paths are alternatives; a browser upload and Git repositories are not combined in the same scan. For repeatable work, prefer Git over one-off uploads. Git-backed scans support lineages, rescans, and CI delta scans more naturally.

Three deterministic stages, then agent investigation

Before the coordinator starts, ZeroQuarry runs bounded deterministic analysis over the target. All three stages do the same thing: they produce leads, never findings. The coordinator and specialist agents then test each lead against control flow, reachability, product context, and the rest of the repository before anything is recorded.

Stage	Looks at	Artifact
Static analysis	Recognizable unsafe code patterns	sast-candidates.json
Dependency analysis	Pinned versions with known advisories	sca-results.json
Infrastructure code	Terraform, Kubernetes, Helm, Dockerfiles, Compose, Serverless	infra-inventory.json

The static-analysis worker uses a frozen local Opengrep rule pack; it does not fetch registry rules during the scan. Treat sast-candidates.json as analysis provenance rather than an alert list.

That "leads, never findings" rule is the contract for all three. It is what lets ZeroQuarry cover a lot of recognizable shapes quickly without turning pattern matches into a list of things to argue with.

Dependency scanning

The dependency stage reads manifests and lockfiles, resolves the pinned versions, and asks osv.dev whether any carry a known advisory. It is enabled by default and can be turned off per scan.

A version match is a lead. The agent decides whether the project actually imports the package — a used, reachable dependency becomes a finding typed Vulnerable Components with the usage evidence attached, and an unused one becomes a non-issue rather than a finding. If the advisory service is unreachable the stage fails open, and records the skip in both the scan log and the artifact so a report never silently lacks dependency coverage.

The inventory exports as an SBOM in CycloneDX 1.5 or SPDX 2.3. The CycloneDX variant also carries the agent's dispositions, which is what turns a list of vulnerable packages into a statement about which ones you are exposed to.

Read Dependency scanning for the disposition rules, the SBOM and VEX behaviour, and how dependency fixes regenerate lockfiles.

Infrastructure-as-code detection

The infrastructure stage classifies Terraform, Helm charts, Kubernetes manifests, Dockerfiles, Compose files and Serverless configs, and writes the same kind of durable inventory as the other two stages.

When IaC is present the coordinator's task gains an infrastructure-shaped rubric — IAM wildcards, world-open ingress, privileged containers, secrets in manifests — because code-review idioms do not apply to a security group. A finding cited at an IaC path is stamped infra, which is what surfaces the report's Infrastructure section.

A classified file is still a lead, never a finding. Read Infrastructure-as-code detection.

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
• infrastructure misconfiguration, when the target contains IaC

Dependency findings are not on this list because agents do not go looking for them. The dependency stage hands over the candidates, and the agent's job is to decide reachability and record the result.

In white-box and grey-box projects, source workers also record the runtime surface they can infer from the code — hosts, ports, and endpoints — into the project's asset library as discovery candidates, alongside any URLs seeded as assets.

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.
Dependency stage	Turns the dependency scan on or off for this scan. On by default; the same toggle is available to API-triggered scans.
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.
Independent adversarial review	Runs a skeptical challenge and researcher rebuttal pass to improve confidence scoring.

Some guided workflows apply entitled review defaults without showing every advanced control. Review the queued scan configuration or report audit log when you need to confirm the resolved settings.

Execution environment and other advanced choices are reviewed immediately before the scan is queued.

Retesting prior findings

When the target already has unresolved findings in the same project, the wizard shows how many and offers to retest them in this scan. The box starts unchecked: a new scan runs fresh unless you opt in, because the changed-code focus and the available context differ from a rescan and a silent retest can imply more than it should.

When you do opt in, each prior finding gets an explicit outcome, including a partial-fix verdict with the residual severity that survived. Read Finding lifecycle for the full vocabulary.

Private repositories

For GitHub, prefer the connected GitHub App and select a repository directly from the first wizard step. For other hosts or deployments, add a saved credential under Account > Integrations > Git Private Repositories. See Connect private repositories.

Scans created through the API — CI triggers in particular — do not need to name a credential: when exactly one saved HTTPS credential covers every target host, ZeroQuarry attaches it automatically. Ambiguous setups still require an explicit git_credential_id.

Enterprise accounts can instead clone Git source and run the assessment from a customer-controlled Docker host. Private-runner source scans accept Git targets only; browser uploads would first transit the ZeroQuarry control plane. See Private runners.

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.

Scheduled rescans and remediation

For a recurring baseline, attach a daily, weekly, or monthly schedule to the scan lineage. Scheduled runs check whether Git HEAD changed and can either scan the updated repository broadly or focus on the diff. Read Scheduled rescans.

For findings in connected GitHub repositories, ZeroQuarry can generate a patch proposal and open a reviewable pull request through ZeroQuarryBot. A dependency bump rewrites the manifest that owns the lockfile and then regenerates the lockfile with the project's own toolchain, so the diff shows the real resolved tree rather than a version string in isolation. Read Auto-fix pull requests.

Common next steps

• For release reviews, pair source evidence with Compiled artifact scans.
• For deployed authorization or SSRF behavior, add a Remote target scan.
• For recurring scans, choose Continuous CI scanning or Scheduled rescans.
• After a finding lands, use Triage to remediation.
• To prove a fix landed, use Verification tests.