GitHub Repo Scanning: Why URL Scans Aren't Enough

Quick answer: URL scans inspect reachable deployed resources and behavior. Repository scans can inspect supported source files, configuration, dependency manifests, and reachable history. Both have coverage limits: review skipped files and incomplete history, investigate findings, and test the running application separately.

By Gabriel CA · Kraftwire Software

Why URL Scans Are Only the Tip of the Iceberg

A URL scan inspects reachable deployed resources and supported behavior, including headers and public scripts. It can identify selected exposure and browser-security signals, but it does not normally receive private backend source or repository history. Test XSS defenses and authenticated behavior beyond the scan’s coverage.

A repository scan can inspect supported backend files, .env templates, migrations, and reachable commits. Coverage depends on the scanner’s parsers, rules, permissions, and resource limits. Use it to investigate source-level risks alongside deployed-site tests; neither method proves that the entire application is secure.

What a URL Scan Misses (and Why It Matters)

Check the scope of the website scan you use. A deployment built with Lovable, Bolt.new, or Cursor may include private server code that needs separate review.

1. Backend Source Code and Functions

Private backend code is not normally visible to a URL scan. A compatible source scanner can flag supported patterns, such as untrusted input reaching eval(), but coverage varies by language and rule. Review code-injection paths and test the actual behavior; an endpoint flaw can also be found through authorized dynamic testing.

2. Configuration and Infrastructure Files

Review files such as docker-compose.yml, config.toml, and .github/workflows for the deployment settings they control. Assess whether a process needs to run as root and how CI credentials are handled. These files should not be publicly served, but accidental exposure is possible. Check a scanner’s supported configuration rules rather than assuming universal coverage.

3. Database Schemas and Migrations

Inspect migrations and seed data for credentials, personal data, and intended access controls. Repository content can differ from the deployed database; compare the effective configuration and test permissions directly. Removing a file from the current revision does not remove older copies.

4. Secrets in Reachable Git History

A secret deleted from the current tree can remain in earlier commits under .git and in other copies. Repository scanners inspect history according to their supported scope and limits; they do not necessarily inspect every commit ever created. Revoke exposed credentials rather than relying on deletion or a clean scan.

Review Generated Repositories Like Other Code

Review code and configuration for the behavior they implement, regardless of whether they were generated or written manually. Working features do not establish that security boundaries hold.

Hardcoded Credentials

Inspect files such as docker-compose.yml and server.js for real credentials and unsafe fallback values. A placeholder resembling a key needs investigation; its format alone does not prove it is a secret. A secret scanner can help find supported patterns, alongside manual review.

Dependency Coverage

Manifests such as package.json or requirements.txt describe dependencies, and supported lockfiles can identify resolved versions, including transitive packages. Check the scanner’s supported ecosystems and advisory sources. A URL scan may recognize selected public frontend libraries, but it does not normally receive a complete private dependency inventory.

Authorization Logic

Review each protected server operation, including who may delete a user or change a role. Source rules can flag supported suspicious patterns, but they cannot prove authorization correctness for every application. Combine review with permitted and denied request tests; see broken access control.

How GitHub Repo Scanning Works

Repository scanning can combine several kinds of checks. Static application security testing is the code-analysis portion; dependency and history checks have separate coverage.

• Secret Detection: Supported credential patterns in inspected files or commits.
• Static Analysis: Supported input flows to sinks such as innerHTML or db.query, interpreted in context.
• Dependency Checks: Supported resolved versions and advisory sources; coverage for npm or pip depends on the tool.
• History Checks: Reachable commits and patches within the scanner’s limits, with incomplete coverage reported.

Inspect repository history as well as current files, and revoke exposed credentials through the provider.

Comparing URL Scanning and Repo Scanning

The two methods are complementary rather than redundant.

A SimplyScan URL scan can inspect supported deployed security headers. Test the intended CSP behavior separately in the browser; automated scanning is not the only way to inspect responses or verify a control.

It also inspects selected AEO discoverability and accessibility signals. Those findings do not establish indexing or WCAG conformance.

Repository review can examine environment-variable handling and Supabase policies represented in source. Compare them with deployed state and test actual access. A policy file existing in a repository does not establish that the database uses it correctly.

• URL Evidence: Reachable resources, response configuration, and supported runtime observations.
• Repository Evidence: Supported source/configuration files, dependency inputs, and reachable history.

Read the coverage record for either mode before drawing conclusions.

When to Use Each Approach

Repeat Relevant URL Checks After Deployment

A free SimplyScan URL scan typically takes about 30 seconds and checks selected signals, including:

• Security headers.
• Supported exposed-key patterns.
• Performance and AEO signals.

It does not establish that the application is safe.

Review Repository Changes and Coverage

Useful review points include:

• Before widening repository access: inspect current files and relevant history for secrets.
• When merging changes: review security-sensitive code and configuration.
• Before launch: compare deployed Supabase policies or Firebase Rules with intended access and test them.
• When advisories or dependencies change: investigate affected versions and update with appropriate testing.

How SimplyScan Bridges the Gap

SimplyScan offers URL and repository checks with different inputs and coverage. For projects built in editors or platforms such as Windsurf and Replit, choose the mode that can inspect the evidence you need.

Pro Monitoring includes Pro scan credits for full reports. See pricing for the allowance associated with your chosen option.

• URL Categories: The URL scan grades 8 dimensions, including speed, SEO, AEO, and accessibility signals.
• Repository Checks: Supported source/configuration rules, lockfile dependency checks, and batched reachable-history inspection report their coverage.
• AI-Service Risks: Supported exposed-key and code-pattern checks do not prove resistance to prompt injection.
• Pro Monitoring: Scheduled rescans, HTTP uptime monitoring, and Slack/GitHub/Linear integrations are separate features.

Step-by-Step: Securing Your GitHub Repo

Scan the URL first

Run a URL scan to investigate supported public-facing signals. If a finding identifies a real exposed secret, revoke it and investigate misuse.

Choose Repository Access

In SimplyScan, provide the GitHub repository URL. Private-repository access requires signing in and supplying a GitHub access token with suitable read permissions. Review the token’s repository scope and lifetime; do not assume every scanner uses an OAuth installation.

Review History Coverage

Inspect the scanned snapshot, checked commits, skipped data, and any continuation offered. Revoke exposed secrets first, then coordinate history cleanup with tools such as BFG Repo Cleaner or git-filter-repo.

Check Dependencies

Investigate dependency findings against the resolved versions in supported lockfiles, such as package-lock.json. Assess affected functionality and test an appropriate update or mitigation.

Verify Database Controls

Compare deployed database access with the intended RLS policies and migrations. PostgreSQL permissive policies are a policy-combination mode, not automatically insecure; inspect their expressions, grants, roles, and operations.

Use URL findings, repository findings, and direct tests together to plan fixes and record remaining gaps. A clean result in either mode is not proof of full-stack protection.

FAQ

Are secrets in a private GitHub repo still a risk?

Private access limits who can read a repository, but authorized collaborators, integrations, or compromised accounts can still expose its contents. Review permissions and history before widening access. Investigate committed secrets and revoke credentials that were exposed; private status alone does not keep every copy confidential.

How do I remove a secret from git history?

Revoke exposed credentials first, then coordinate history rewriting with collaborators using tools such as git-filter-repo or BFG Repo Cleaner. Review branches, tags, artifacts, and remote copies. Deleting the current file is insufficient, and a rewrite cannot erase every clone or cached copy.

How many secrets get leaked on GitHub?

The figures depend on the source, time period, definition, and coverage. This article does not provide a verified global count. For your repository, inspect the specific findings and history coverage rather than using an industry total to infer exposure.

Can a repo scan find vulnerable npm packages?

A scanner can check supported manifests and lockfiles, such as package-lock.json or yarn.lock, against supported advisory data. Check unresolved or skipped packages and ecosystem coverage. A dependency finding does not prove exploitability, and no findings do not establish that every dependency was checked.

Do I need repo scanning if my URL scan came back clean?

A clean URL scan means no reportable findings were produced within the checks and evidence covered. It does not establish frontend safety or inspect every private source path. Use repository review and application-specific tests for risks outside that coverage.

Is it safe to give a scanner access to my GitHub repository?

Review the scanner’s permissions, processing, retention, and repository scope before granting access. SimplyScan’s private-repository flow uses a GitHub access token supplied with an authenticated request. Restrict and revoke that token through GitHub as appropriate; revocation does not erase data already processed. Do not assume every scanner stores or handles code identically.

Related Guides

• Vibe Coding Security Checklist
• How to Fix Exposed API Keys
• Supabase Security Checklist
• Is My AI-Built App Safe?
• Understanding Security Headers
• The SimplyScan Security Engine Explained

Pro Monitoring costs $24/month.