How to scan a GitHub repository for security vulnerabilities

Before you scan

Use a repository you own or have permission to review. Identify the app you intend to check and make sure its current code, dependency manifests and relevant configuration are committed. A source scan can only assess the files and history it receives; it cannot see production settings stored elsewhere.

SetRepo does not build the project, install its packages or execute its code. You do not need to make a private repository public to scan it.

1. Choose how to provide repository access

Open the project form and sign in or create an account. Repository scans require an account with a verified email.

For a public GitHub repository, you can paste its repository URL without connecting the GitHub App. For a private repository, connect the SetRepo GitHub App and select which repositories it may access. An organization owner may need to approve the installation. Access to repository contents is read-only.

The GitHub Connect page explains that connection. If your organization cannot grant it, a ZIP upload is another way to provide code, but an archive does not include Git history unless you supply it.

2. Review the setup and choose a scan

Pick the repository, name the project and optionally add the app's deployed URL. Review the setup, credit estimate and maximum reservation before authorizing the scan:

• Quick: deterministic checks using credits for secrets, known vulnerable dependencies, risky code patterns and configuration, including supported route-level access-control checks.
• Deep: paid; includes Quick checks and AI review of selected code for object-level access and business-logic weaknesses. It also reviews uncertain critical and high pattern findings.

The Free plan includes monthly credits for Quick and URL scans; usage varies with the resources needed. A live URL adds public-site checks alongside the code. Extra exposed-file and public-data checks require domain verification. See pricing before choosing Deep and AI scanner coverage for how the review works.

3. Read findings as evidence to investigate

Start with findings that may expose credentials or private data. Look at the affected file and line, the reported condition and the surrounding code before deciding on a fix. Free reports provide full details for a limited set of top findings; report access depends on the selected scan and plan.

Useful questions include:

• For a secret finding, is the value a private credential or a public identifier? If a private credential leaked, revoke and rotate it; deleting the line does not invalidate the old key.
• For a dependency finding, which version is installed, and can the app reach the affected behavior? Check the advisory and test a patched version.
• For missing authorization, is a guard enforced on the server, and does it apply to this route? A button hidden in the browser is not a server permission check.

4. Fix, test and rescan

Make changes in your normal development workflow. Test the affected behavior, including requests from an unauthorized account where appropriate, then rescan the updated project. SetRepo reads the repository; it does not commit fixes for you.

Know the boundaries of a repository scan

SetRepo's Git history secret check uses a bounded history fetch, configured for up to 100 commits, rather than every branch or the full repository lifetime. ZIP scans do not recreate missing history. Unsupported patterns, omitted files and settings outside the repository can leave gaps.

A scan does not exercise logged-in workflows or demonstrate that every reported issue is exploitable. Review the full limitations, code handling, and the report's own unchecked areas before treating a scan as complete evidence.