Skip to main content

Free Scan

A free static-analysis scan needs no credits and no card. Point AISafe at a repository and you get static-analysis issues, dependency and licence data, exposed secrets, infrastructure misconfigurations, an SBOM and a call graph.

A scan usually takes a couple of minutes.

Two ways to start one

Without a project. Choose the free scan when starting new work, paste a public repository URL, and the scan runs. Nothing else to set up. Your plan includes a number of these each month; the free plan includes 15, and the count returns to zero at the start of each calendar month. A scan that fails before AISafe reads any code does not count against it.

From a Project. Attach a source once — a repository from a connected integration, a public repository URL, or an uploaded archive — and scan it whenever you like, subject to the per-project rescan window below.

The fastest way in is the Create project & scan button on your dashboard. It opens a card in place: pick the repository or upload an archive, narrow the scope if you want to, and the project is created and the scan started without leaving the page. Results appear in the same card as they arrive.

A project is what you want for code you keep working on. It carries scheduled scans, monitoring, and the comparison that tells you what is new and what you have resolved since the last run. A scan without one is a single look.

The rescan window on a project

A project can be rescanned every three days on the free plan, and every ten minutes on Pro. The window is per project, so scanning one does not hold up another.

How long AISafe keeps your code

AISafe keeps the code it analyses for 30 days, then deletes it. Two clocks, because a scan and a project are different things:

WhatWhen it is deleted
The snapshot one scan analysed30 days after the scan attached it. This clock never resets — a snapshot is one moment in time.
Your project's source30 days after the last activity on the project. This clock resets every time you use it.

A project with a scan schedule or monitoring turned on is never affected: you have told AISafe you want the work to keep happening, so the source stays.

You can also delete an assessment's source yourself at any time, from the assessment's tool panel.

Results survive the deletion. They do not contain your code. AISafe's static analysis produces a source-free snapshot: typed facts, file paths, line locations, dependency metadata and redacted secret fingerprints. It never keeps raw source or raw secret values. Findings, severity counts and the SBOM stay readable indefinitely. What stops working is the Code Explorer, which reads the code itself.

Rescanning after the source is gone depends on where it came from. A connected or public repository is fetched again, so a rescan just works. A project whose source you uploaded has no upstream, so AISafe asks you to upload the archive again — and tells you before you get there.

See Data handling for how the rest of your data is stored.

How often you can scan

Rescans are limited per project so a scan cannot be started in a loop:

PlanRescan window
Basic (free)one scan per project every 3 days
Proon demand, with a 10-minute anti-thrash gap
Enterpriseon demand

If you ask for a scan inside the window, AISafe tells you exactly when the next one is available rather than failing silently. Upgrading takes effect at once: if you go Pro during a free-tier window, you can scan immediately.

One scan runs at a time per organization.

Reading the results

Issues first. Everything the scan can rank sits on one table: rules matched in your source, advisories against your dependencies, packages past end of life or under a licence your policy refuses, credentials found in a file, and infrastructure checks that failed. One list, worst first, whatever found it.

One row is one problem, not one place. A rule that matches in twenty files is one issue with twenty locations. The row carries the count and the panel behind it lists every place, so the length of the list is the number of things to decide about rather than the number of times we saw them.

Dependency vulnerabilities are one row. A repository with old libraries can carry a hundred advisories across a handful of packages, and reading them one by one tells you less than the packages do: upgrading one library often closes twenty of them at once. So the table carries a single "Known vulnerabilities" row, and opening it lists the packages worst first with their advisories under each. Licences needing review and packages past end of life work the same way. Everything else — a rule matched in your code, a credential in a file, an infrastructure check that failed — keeps its own row, because those are the ones you act on individually.

An issue is not a finding. A scan matched a pattern; a finding is something your team has decided to carry. On the Issues tab you can promote an issue into an ordinary finding, which puts it in your findings list with everything else and gives it a code you can quote. You can also mark one a false positive or an accepted risk, which closes it without creating a finding — it stays out of your findings list, your counts and your SLA clock, and the decision survives the next scan of the same project.

The tabs after Issues are inventories: dependencies, secrets, infrastructure, licences and endpoints. They show what the scan found and offer no buttons. Deciding what to do about something happens in one place.

Every number on the page says which population it counts. The severity figures on the overview count places in your source that matched a rule; the Issues tab counts issues. Where one rule matched twenty times, that is 20 on one and 1 on the other, and both surfaces say so.

What changed since last time

From the second scan of a project onward, the results page reports what is new and what is resolved compared with the previous scan.

The comparison ignores line and byte positions, so reformatting a file or adding a comment at the top does not flood the report with false movement. Only genuine appearances and disappearances count.

The first scan of a project has nothing to compare against and is shown as a baseline.

Export the results

Call GET /api/v1/assessments/{id}/sast-findings/export?format=sarif|csv with the findings:export scope to download the scan's immutable static-analysis results. SARIF works with code-scanning tools; CSV contains rule, severity, message, location, classification, confidence, reachability, and remediation columns. Repeat the fingerprints query parameter to export selected result groups.

What the free scan does not include

The free scan is deterministic static analysis. It does not run the AI audit that reasons about your architecture or proves exploitability. Those are Source Code Audit and the pentest services, which any organization — free or Pro — can run by buying credits. Plans never gate them.