Run your first scan

This guide walks through a first source scan in the ZeroQuarry cloud console. The point is not just to click through the form. The point is to create a small, reviewable report and learn how ZeroQuarry moves from target, to findings, to follow-up.

Source scans are the safest starting point because they do not send traffic to a live target.

The console opens into your projects. Open a project to start from its scan history instead of a blank home screen.

Before you start

You need:

• access to console.zeroquarry.com
• a project or repository that you are authorized to assess
• an available LLM model in your workspace
• Git credentials if the repository is private

Some workspaces use ZeroQuarry-managed LLMs. Others require an account-level LLM API key before scans can run. If your plan requires bring-your-own keys, add one under Account before creating a scan.

On a brand-new account, the first sign-in also includes a workflow-mode choice. Read Choose your workflow mode to compare Guided scan, AppSec triage, and Security research.

Choose a good first target

Pick a repository or archive where you understand the business logic. The best first scan is not necessarily the largest codebase. It is a target where you can judge whether a finding is real.

Good first targets:

• a service with authentication or authorization logic
• a webhook receiver
• a file upload or import feature
• a repository with a recent security-sensitive change
• a small service that has known roles, tenants, or permissions

Avoid starting with a huge monorepo unless you can provide focused notes.

Create the project and scan

1. Open New project and pick the profile that matches the assessment — Source code for a repository review. Profiles are explained in Projects and scans.
2. Choose New scan, then Source code.
3. Under Source, choose one input path:
   • Connected GitHub repo
   • Add Git URLs
   • Upload source code
4. Under Details, name the scan, confirm its project, and add useful tags.
5. Under Review, queue the recommended defaults or open advanced options to add focus notes and review execution, model, notification, and artifact settings exposed by your workflow mode.
6. Queue the scan.

The picker only offers scan types the project's profile and your plan allow.

The source input paths are alternatives. A single scan does not combine a browser upload with Git repositories.

The final step keeps the recommended path short while preserving access to focus, execution, model, review, artifact, and notification settings.

The scan detail page shows live log output while workers claim and process the job, and discovered assets appear in the project's asset library as the scan works.

Understand what happens next

After you queue the scan:

1. ZeroQuarry prepares the target workspace.
2. The coordinator maps the target and creates a plan.
3. Worker agents investigate focused paths.
4. Triage merges weak or duplicate issues and records findings.
5. Optional artifact steps create exploit proofs, disclosure drafts, or other follow-up.
6. The report becomes the review surface.

For long-running scans, use email or Slack notifications so the scan does not require a browser tab to stay open.

Account defaults for notifications, model keys, and workspace preferences live under Account.

Write useful notes

Notes are included in the coordinator prompt. Good notes narrow attention without hiding the rest of the attack surface.

Good examples:

Focus on authz decisions in the billing and team-invite flows.

Review webhook signature verification and any retry or replay behavior.

The recent change touched the SAML callback. Follow data flow from the callback
handler into session creation and role assignment.

Avoid notes that ask the scanner to ignore broad classes of risk unless that is really what you want.

Review the report

When the scan completes, open the report. Work in this order:

1. Read the summary and severity counts.
2. Open high and critical findings.
3. Check confidence and vendor-review state if present.
4. Read evidence before acting on the conclusion.
5. Review exploit proof material and affected source locations.
6. Skim coverage notes to see what the scanner investigated without recording a vulnerability.
7. Use finding chat for clarification or a different explanation format.

Do not export or share the report until you have looked at the findings that would change a decision.

Follow up

Your next step depends on why you ran the scan:

If you need to...	Do this next
Fix a finding	Use Triage to remediation.
Prepare a release decision	Use Release security review.
Run the scan repeatedly	Use Continuous CI scanning.
Prove the fix landed later	Use Verification tests.
Report externally	Use External disclosure workflow.
Compare another asset shape	Run a binary or remote scan in the same project.

Next steps

• Use Projects and scans to keep scans organized.
• Use Project assets to record targets once and reuse them across scans.
• Use Private repositories for non-public Git inputs.
• Use GitHub Actions to trigger scans from CI.