GitHub AI Scan: check the app you already have

Start with the app you want to understand

If you already have an app, ask your builder how its existing code is checked for security weaknesses. These are mistakes that could let someone reach information or actions they should not. Choose one project and agree who will review any findings before starting another tool.

On October 28, GitHub introduced repository-wide AI Scan in public preview, an early release that may change. A repository is the project folder stored on GitHub. The scan looks for weaknesses in the main saved version of its code, extending checks beyond newly proposed changes.

GitHub says it can examine languages outside the coverage of CodeQL, its existing code-checking tool. Findings appear alongside other security alerts, so the person maintaining the app can follow them in the same place.

Read the announcement: GitHub: AI Scan for repositories in public preview.

Check eligibility and spending first

Access depends on who owns the project and whether its code is public. Public projects owned by an organization are eligible. That organization's private or internal projects need GitHub Code Security or Advanced Security. Personal accounts can scan public projects; private personal projects are not supported.

You do not need a Copilot licence, but scans consume Code Security AI credits, the units GitHub uses to charge for this work. Ask the account owner which allowance and budget will pay for the scan. Availability and included usage are different questions.

An organization or enterprise may also need to allow the feature before someone can run it. Review the current settings with the person responsible for the project rather than assuming access from the name of a subscription.

Use each finding as something to check

These scans start when a person requests one. They do not run automatically after every change or on a schedule. The AI chooses code to inspect within a time limit, rather than reading every file in full.

A scan can miss a weakness or report something inaccurately. A clear result with no findings therefore cannot prove the app is secure. Ask a qualified builder to assess a finding before deciding what to change, and keep the other checks your project needs.

1. Confirm that the project is eligible and name the person reviewing the results.
2. Check the billing account, available credits and spending limit.
3. Run a scan and ask the reviewer to explain one finding in everyday language.
4. Review the proposed fix, test the affected task and run another scan to check the outcome.

Make the explanation useful to you

You can learn from a finding without knowing every detail of the code. Ask what could happen, who could be affected and how the fix changes that situation. Then ask what evidence confirms the fix. Keep the answer with the project notes.

For someone learning to build with AI, that conversation turns a tool report into a practical lesson. If you hire a builder, it helps you understand what ongoing care involves and who will provide it.

Our perspective is that better scanning tools are most useful when a named person follows through. The aim is a clearer next action and a checked improvement, rather than collecting another report.