Skip to content
Audixa
Audixa

How it works

What happens between telling us where the code is and reading a finding

Written out in full, because the honest answer to “what will you do with my code?” is a sequence of steps, not a reassurance.

Setup

Where is your code? Once per project

  1. Create a project

    A project is one application. After you name it we ask where the code is — not a price question, an origin question.

  2. Where is your code?

    GitHub, GitLab or Bitbucket; a ZIP if the tree is not on a host yet; or skip source and verify a domain for live checks only. Scan clones stay read-only. A pull request is opened only when you ask, and it is never merged automatically. GitLab and Bitbucket stay honest when this deployment has not configured them.

  3. Verify the domain, if you want live checks

    Verification is a DNS TXT record or a file at /.well-known. Until one of those succeeds, we do not send a request to your domain. A scanner that will check any address anybody types is a tool for attacking other people.

During a scan

The stages you see, and what each one does

These are the real stage names the product shows. If a stage cannot report accurate progress we show the stage rather than inventing a percentage that creeps to 90 and stops.
  1. Queued

    The scan is recorded and waiting for a worker. You see a queue position, not a fake percentage.

  2. Preparing

    A worker clones the selected branch at depth one with hooks and submodules disabled, or unpacks an uploaded ZIP with the same size and path limits, into a fresh container with no network access. Limits abort rather than silently truncating.

  3. Static analysis

    Secret scanning and rule-based pattern matching run over the tree. Nothing is installed, built or executed. Output is JSON, validated against a schema before we trust a single field of it.

  4. Dependency analysis

    Your lockfile becomes an inventory inside the sandbox. Only that inventory leaves — a list of package names and versions — and the advisory lookup happens outside, so your source never touches a third party.

  5. Web configuration checks

    For a verified domain: one polite pass over certificates, headers, cookies, CORS and redirects. Standard requests only, rate-limited, with a user agent that says who we are and where to complain.

  6. Normalising

    Results from every engine become findings in one shape, deduplicated and fingerprinted so the same issue keeps its identity between scans and you can see whether it survived your fix.

  7. Explaining

    Optional, and per-organization. If AI assistance is on, already-redacted application snippets go to the model. .env, PEM and secret lockfiles stay on this server and are still scanned locally. If assistance is off, or the provider is unavailable, the scan still completes with the deterministic content.

  8. Completed

    Findings, a score with its inputs, and a record of which checks ran and which did not. The container and everything in it are destroyed.

What we promise

Five commitments about your code

These are properties of how the system is built rather than policies we intend to follow, which is why they are on this page and not only in the terms.
  • We never execute code from your repository — not a build, not a test, not a package install script.
  • The workspace is destroyed when the job ends, whether it succeeded, failed or timed out.
  • Your source code is not retained. Findings keep up to three lines of context, with anything secret-shaped redacted first. .env, PEM and secret lockfiles are scanned locally and are never sent to the model.
  • Scan clones stay read-only. We open a pull request only when you ask — an AI Fix or a verify-badge snippet — and we never merge it.
  • Active checks reach only a domain you have verified, over HTTP and HTTPS on the standard ports, with no exploitation attempted.

Why domain verification is mandatory

Anyone could type somebody else’s domain into a scanner. If we ran checks on request we would be a free tool for probing other people’s systems, and the traffic would come from our address. Proving control of the domain first is what keeps that from being our problem — and yours.

What happens when a scan fails

It ends as failed, with a message that tells you what to change: a repository too large, a branch that no longer exists, a revoked token. It never ends as “completed with no findings”, because a failure that looks like a clean result is the most dangerous output this product could produce.

Disconnecting

Remove the GitHub App and our access ends immediately. There is no stored long-lived token to revoke separately, because each scan uses one that expires. Deleting a project deletes its findings and its scan history with it.

Connect a project and run the first scan

It takes a GitHub App install and a branch name. You can add the domain later, or never.

Analyze my projectOr read the security page first

Start free. No automatic changes to your code.