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.

Understanding code results

Code matches are grouped by rule. The table shows each issue's title; open the issue details to see its locations and evidence level:

• Proven: the scanner has enough evidence for at least one location.
• Needs your review: the scanner found a possible issue but could not complete the proof. The result explains the gap.
• Candidate rule: a pattern matched; it is not a data-flow proof.

Each location keeps its own evidence level. Proven groups appear first, followed by review groups ordered by severity, then candidate rules. All use the same triage controls. Matches in test or generated code and proven unreachable paths stay hidden; the summary reports their counts.

The severity summary and assessment cards count grouped open issues. The code evidence summary counts locations by evidence level, so several locations can belong to one issue. A bounded count says when more may exist.

Two ways to start one

Without a project. Choose the free scan when starting new work — it opens the same setup wizard every other assessment type uses. The wizard starts on Create a project; choose No project if you want a standalone scan. Pick the repository, upload an archive, narrow the scope if you want to, and submit: the scan runs, and you need no project to do it. 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 wizard's project selector covers this too, and a scan bound to a project follows that project's rescan window.

The Start a free scan button on your dashboard opens the same wizard in one click. On a brand-new organization the Create project & scan card stays: it makes the project and runs the scan without leaving the page.

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.

A scan that fails does not use the window up. Retry it from the failed scan's page — the retry opens the scan as a draft you can fix (an unreachable repository, for example) and start again.

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:

What	When it is deleted
The snapshot one scan analysed	30 days after the scan attached it. This clock never resets — a snapshot is one moment in time.
Your project's source	30 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. The analysis snapshot contains typed facts, file paths, locations, dependency metadata, and redacted secret fingerprints. It contains no raw source or secret values. Findings and reports can retain the source excerpts included as evidence when they were created. Those excerpts, severity counts, and the SBOM stay readable; the Code Explorer and any source snippet that still needs to be fetched require retained source.

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:

Plan	Rescan window
Basic (free)	one scan per project every 3 days
Pro	on demand, with a 10-minute anti-thrash gap
Enterprise	on 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

API clients read these results below /api/v1/assessments/{assessment_id}/sast. Response fields and error codes use the same sast name.

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.

Code findings need evidence. For a data-flow rule, the scan must identify untrusted input, a connected path, and the dangerous use of that value. Open an occurrence to follow its source, intermediate operations, and sink in the scanned revision. Long flows load in pages. If a snippet cannot be read, the finding keeps its location and shows that the evidence section is unavailable. Uncertain candidates do not enter the findings list. Scan coverage still states which analysis could not complete; an empty list does not prove the code safe. A function parameter alone does not establish untrusted input. Supported flows start at a modeled external input, such as an HTTP request, and follow that value through helper calls to its dangerous use. An unsupported call remains a coverage gap. A finding on an independent execution path can still qualify when its input and dangerous use are fully traced. Where the trace provides an exact expression range, the finding names the input and receiving API. Nearby inputs on the same line do not supply that label.

Supported flows include Python payload decoding and Rails controllers that inherit from a controller in another file. Calls must have valid argument bindings. A helper parameter, a shadowed library name, or a custom method with a familiar API name does not by itself establish a vulnerability. Framework customization can change where a value comes from. Unsupported request handlers and parsers still limit coverage; support for a language does not mean every framework configuration is covered.

For supported Python string formatting, the scan follows arguments used by the format string and preserves calls inside unused arguments. This requires a known string value. Custom formatting methods, mutable module templates and unsupported format specifications remain unresolved. For requests and redirects, the scan distinguishes control of the destination from data in a fixed URL's path or query. Coverage varies for later transformations and container mutations; these cases still need review.

For supported assignments in helpers, the scan tracks whether a value was replaced before its dangerous use. A copy made earlier can still carry the input. If an exception could bypass an assignment and that path is unresolved, the assignment does not establish that the input was removed.

SAST focuses on modeled data flows and precise code rules. An object ID reaching a database lookup alone does not establish IDOR. Use the AI audit to assess ownership, authorization, and application-specific business rules.

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.

A zero states how far the check got. The Dependencies tab states advisory coverage beside the vulnerability count: "0 known vulnerabilities · advisory check complete for 304 packages" when every package was checked, and "advisory check incomplete" with how many packages were fully checked, partially checked, or not checked when the lookups did not all finish. A filter on the same tab reaches the not-checked packages by name, because those are the ones to resolve by hand. A licence AISafe could not read is licence data on the Licenses tab, not a security issue.

Every issue is recorded as a finding when the scan completes and receives a code you can quote. It stays Not triaged until somebody reviews it. On the Issues tab you can mark it triaged, false positive or risk accepted — one click each, no reason to type, because a free scan carries no report to justify the decision in. The latter two remain in history but stay out of active posture, counts and the SLA clock. The decision survives the next scan of the same project.

The Issues table has a Status column and a Status filter. The filter opens on Open: everything not triaged yet plus everything triaged and still live. An issue you mark fixed, false positive or risk accepted leaves the default view — it has left the work — and the filter's other options, including All, bring it back.

Open any issue to use the same full finding page as the rest of AISafe, with its evidence, impact, fix guidance and review history.

Scanner-backed findings keep that proof boundary in their copy. Observed states the exact match and location. Impact says what may follow only when the rule or CWE supports a conditional claim. Unknown classes omit impact instead of filling the page with generic text. Secret matches remain credential-shaped values until provider validation proves that they work, and licence-policy findings state the configured policy decision rather than a legal conclusion.

Secret detection uses supported literal syntax to distinguish credential text from a variable reference. For example, $ can be part of a quoted Python or JSON password. Recognizing that literal does not establish that the credential is active.

Data-flow findings show the input source, the relevant calls and assignments, and the operation that uses the input. Each affected location keeps its own flow. Markdown exports label these steps Input, Flow and Operation and include their code locations. JSON exports also retain the variable and function names. Supported helper calls retain their intermediate reads and transformations. Fix advice explains how to address the detected weakness. Where a reviewed API model applies, the advice can include the relevant API's options. Different operations in one issue keep their own evidence. A helper argument alone does not establish external input. If the flow depends on an unresolved operation inside a helper, it does not qualify for publication. Missing trace or snippet data is shown as unavailable; it is never presented as evidence that the code is safe. Repeated sink excerpts are shown once, alongside the flow.

Weak-hash findings explain when the selected algorithm matters and give different fixes for password storage and content integrity. Password guidance uses a password-storage library; changing to another plain digest is not a fix.

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.

Known dependency vulnerabilities appear as one issue, with packages and advisories beneath it. Licence terms that need a policy decision also appear as one issue, with each package and detected expression beneath it. Dependencies past end of life form one more issue, with support dates and upgrade paths under it. This keeps the review queue about decisions rather than repeating every advisory or package.

Every number on the page counts findings, the rolled rows the Issues table draws: a rule that matched twenty times is one code finding with twenty locations, a hundred advisories are one "Known vulnerabilities" finding, and a credential that appears in three files is three secret findings. The headline total, the severity figures beside it and the Findings control on the results tabs all describe that one population. The tabs after Findings are inventories of what the scan read — packages, raw secret matches, endpoints — and their counts name their own units.

The scan's card on the assessments list (and the project page) counts what is LEFT, not what the scan saw: only open and not-yet-triaged findings. An issue you mark fixed, false positive or risk accepted leaves the card the moment you decide, on every assessment type.

What changed since last time

When two complete scans use the same engine and analysis profile, the results page shows new findings and findings no longer reported. Position changes alone do not count as new issues. A disappearance is not verification that the code was fixed; fix verification remains a separate action.

When the engine, policy, or coverage differs, the page says No comparable baseline. Your earlier findings and review decisions stay in history.

Export the results

Call GET /api/v1/assessments/{id}/sast/findings/export?format=sarif|csv|json with the findings:export scope to download the scan's findings. Each row in the results table stays one result in every format. Dependency, licence, and end-of-life rollups keep their package-level evidence inside that result rather than expanding it into hundreds of peer results. Repeat the fingerprints query parameter to export selected findings.

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.