All questions

No. Every finding is written in five plain answers - what is wrong, why it matters, how it would be abused, how to fix it and how the fix gets verified - before any jargon appears. Technical detail is one click away when you want it.

No. A scan performs reads an anonymous visitor could perform. It never exploits anything, never writes, and never logs in. A pen test is a person actively trying to break in, which is a different exercise with a different scope.

No, and it does not try to. It does the part that is mechanical and endless - watching every push, every dependency and every header - so that a person’s time goes on the judgement calls.

No. A URL and an email address is the whole requirement. An account is only needed to keep a history, connect a repository, or invite anyone else.

To deliver the report. Scans finish in minutes rather than seconds, so the result has to reach you somewhere. Marketing consent is a separate tick box and nothing is sent if you leave it unticked.

Usually a few minutes. It depends on how quickly the site answers and how heavy the page is; every stage has its own time budget so a slow target cannot stall indefinitely.

Only scan things you are responsible for. The scan is read-only and stays within what a visitor could do, but permission is yours to have, not ours to assume.

Once an hour for the same site. Paid plans drop that wait to five minutes and add scheduled, continuous scanning.

One or more steps failed or were skipped, so the scan did not see everything it normally would. The report lists exactly which steps and why. A partial scan is never presented as a clean result.

Ranking is not severity alone. Confidence, the domain and what we know about the application all count - a high-confidence high in a route that holds personal data can outrank a low-confidence critical somewhere harmless.

Yes. Free reports live at a private link, and reports inside the app export to PDF, CSV or JSON.

Yes. You are invited into each one separately and switch between them in the app; your role can differ in each.

Only people in the organization that owns the site, according to their role. Nothing is shared between organizations, and every read is scoped by the organization on the way in.

Its sites, scans, findings, reports and facts go with it. Ask support if you want a copy exported first.

One on Free and Pro, three on Studio, ten on Agency and twenty-five on Team.

Yes, if you want it watched. It counts against your site limit, so on a one-site plan most people point AppScan at production and use a manual scan when they want to check staging.

The runtime half needs to reach the address. Anything behind a VPN or an allowlist will report its steps as skipped. The source, dependency and infrastructure rules still work, because those come from the repository.

No. Source is fetched for analysis and discarded afterwards. What is kept is findings, facts, file paths and short masked snippets around a finding.

Not today. GitHub is the only code host with an integration. The runtime half of the product works regardless of where your code lives.

Three per site on Pro, Studio and Agency; five per site on Team. Free plans cannot connect a repository at all.

Never. The only write is a new branch opened as a draft pull request, and only when a person clicks Fix with AI.

No. Which stages run depends on the kind of scan and on what is connected. A free runtime scan runs the live-site, browser and performance stages; a push runs the source stages; the report and scoring stages always run.

No. Detection is entirely deterministic. AI tasks happen afterwards and only when a person asks for one.

Scan now is a manual live-site scan you trigger. It is free and unlimited on paid plans (one at a time per site, with a short cooldown); the Free plan includes five a month at one credit each. Continuous monitoring is the automatic work that follows pushes, pull requests and advisories, and is included in the plan.

Advisory re-evaluation runs daily for affected applications. Everything else is event-driven: you push, you open a pull request, or you press scan.

Open the coverage list. If a step failed because the site was slow or briefly down, run it again. If it was skipped because something is not connected or not on your plan, the report says which.

A failed scan releases its reservation. A partial one settles at half. You are never charged in full for work that did not happen.

It walks a limited number of routes, rate-limited, with a scanner user agent, and backs off when a site is struggling. It behaves like one careful visitor, not like load.

No. Everything it does is available to an anonymous visitor. Authenticated crawling is not something the scanner does today.

No. Nothing is submitted, nothing is written, and no state-changing request is made.

Two concurrent scans of one application would race on the same facts and baselines, and would look like load to your server. Team plans allow two per site; everyone else runs one at a time.

Credits can be topped up, but concurrency and site limits come with the plan. If you need something between two plans, talk to us.

Not necessarily - a dropped connection stops the stream, not the scan. Reload the page; the current state is fetched fresh and the stream reconnects.

The rule does, deterministically. AI can add an explanation in your application’s terms afterwards, but only when you ask - and the original five answers never change.

No. It is masked at detection. Enough is kept to identify which key it is and where it lives; the value itself never reaches our database and never reaches a model.

Severity here is about impact on your application given what we know about it, not a fixed number per rule. The same missing header can be medium on a marketing page and high on an app that holds personal data.

Because hiding them would be a silent decision made on your behalf. They are ranked down and the text says exactly what we could not establish.

Not as the primary scale. CVSS describes a vulnerability in the abstract; ranking here uses severity, confidence, domain and what the Application Brain knows about the affected code. Advisory findings still carry the upstream identifiers.

The rule no longer fires. That can mean the code changed, or that the thing it examined is no longer reachable. Open the history: it records which scan resolved it and what changed.

They stay with the site, so you keep the history of what was found and when. Filters default to open work.

Yes. Reopen the finding and it returns to the fix-first list; both the dismissal and the reopening stay in the audit log.

No. A dismissal is scoped to the finding it was made on, in that site. The same weakness elsewhere is a separate decision.

Please tell us which rule id and why. False positive is the signal we use to decide what to tighten.

Both are kept and the disagreement is visible. Most often it means the running deployment is not the commit we analyzed, which is itself worth knowing.

No. Without source there is nothing to correlate to, so runtime findings stand alone.

Not globally today. Dismiss the findings you do not want with a reason; that is recorded and keeps the decision visible instead of hiding a whole class of problem silently.

Not yet. The closest thing available today is invariants, which are derived from your own code rather than written by hand.

TypeScript and JavaScript, including the routing conventions of the frameworks around them. Everything that does not depend on parsing your language - live site, browser, lockfile advisories, Docker, Compose, nginx, Kubernetes, Terraform and Actions - works whatever you wrote the app in.

Long enough for a burst of pushes to settle, and no longer. If you push once and stop, the change set starts almost immediately.

The default branch is monitored continuously. Other branches are scanned when they appear in a pull request.

Only if you make it required in GitHub’s branch protection. By default it reports and lets you decide.

They run with the permissions GitHub grants a fork pull request, which are deliberately narrow. Anything that cannot be read is reported as skipped rather than passed.

No. Continuous monitoring, including pull request checks, is included in the plan. Credits are for AI tasks and manual full scans.

Not today. They are derived from patterns your code already follows, which is what keeps them honest and specific to you.

Usually because the logic moved behind something the analyzer cannot follow - dynamic dispatch, a wrapper built at runtime, or code in a language it does not parse. The invariant is not silently dropped; it is shown in that state.

The JavaScript ecosystem ones - npm, pnpm and yarn. If your repository has no lockfile, the dependency step reports itself as skipped.

Advisory re-evaluation runs daily for affected applications, so within a day of the advisory being published.

Not automatically. Fix with AI can prepare the change and open it as a draft when you ask for it on a specific finding.

No. It is masked at detection. Enough is kept to identify which key it is and where it lives; the value never reaches our database and never reaches a model.

A bounded slice, taken once after the first inventory, and recorded as scanned-through so it is never re-read from scratch. It is deliberately not the whole history of a ten-year repository.

Give it an obviously inert value and it stops being reported. If it must look real, dismiss the finding as a false positive with a reason - that is recorded and it will not come back.

No. These findings come from the files in your repository, not from an API against your provider.

Connect that repository to the same site and it is read with the rest.

No. Detection is deterministic and repeatable, with a rule id on every finding. AI explains, judges authorization, and writes fixes - always after the fact, always on request.

A cheap tier, a default tier and a premium tier, chosen per task by what the task actually needs. The provider sits behind an adapter, so the choice can change without changing what you see.

No. Nothing you connect is used to train anything, and nothing is retained for another customer’s benefit.

It groups findings that share a root cause into one pull request. Unrelated findings get their own, so each change can be reviewed on its own terms.

Close the draft. Nothing was merged, the branch is yours to delete, and the finding stays open. Tell us which rule produced a bad patch - that is the feedback that improves it.

It needs permission to create a branch and open a pull request. It never writes to your default branch.

No. Credits are the binding limit; the money ceilings sit above them as a second guard for runaway behaviour.

Long output is trimmed rather than thrown away, and an answer that cannot be used at all releases its reservation. A rejected answer does not close the door - you can ask again.

It is off unless you press something. There is no setting to disable a feature that never runs on its own.

After a significant architectural change, or before something that matters - a launch, a security questionnaire, an investor’s technical review. Not weekly.

No. It needs credits, and Free plans have none.

For as long as the site exists in your organization. They are the history of the application, so they are not rotated away.

Each report carries what changed since the previous one for the same site, which is the comparison people actually want. Arbitrary report-to-report diffs are not available today.

That is what it is for. It says what was checked, what was found and what the coverage was, without needing an edit first.

Exports are per report or per filtered issue list. For a portfolio-wide pull, use the JSON API.

Yes. Preferences let each person narrow what reaches them, including by site.

No. Dismissed findings leave the alerting path entirely.

Free delivers the report for a scan you asked for. Continuous alerting comes with a paid plan, because there is no continuous monitoring to alert about otherwise.

Not today - the webhook is per organization. Studio and Agency customers who need this usually create a separate organization per client.

No, and deliberately: an incoming webhook needs no permissions in your workspace and can be revoked by you at any time.

Move everything except critical findings to the digest. Most people find that leaves instant alerts for genuine emergencies only.

You can turn off every optional message. Account-security emails - verification, password changes, two-factor - are always sent.

Not published yet. The tables in this section list every customer-facing endpoint with what it needs and what it returns; ask us for the current description of the ones you need.

Yes, per organization and per IP on the public routes, generous enough that normal use never notices. Bulk pulls should page rather than hammer.

One on Free, three on Pro, five on Studio, ten on Agency and fifty on Team.

Yes, and for anything that matters there should be. An organization with one owner has a single point of failure.

Their access ends immediately and their sessions stop working. What they did stays in the audit log.

Not today. TOTP with recovery codes is what is available; WebAuthn is on the list.

Not as an enforced policy yet. Today it is per account, so ask your team to turn it on - and check.

Check spam, then request it again from the banner in the app. If it still does not arrive, tell us the address and we will look at the delivery log.

Not today. If it is a requirement for you, say so when you talk to us - demand decides the order things get built in.

Not as a list yet. Changing your password ends other sessions, which is the blunt version of the same thing.

To the creation of the organization. It is not rotated.

No. Nobody can, including us. That is what append-only means.

Sites and people. Pro is one application and three seats; Studio is three applications and five seats, with more credits and one more concurrent scan.

Yes, from the billing screen. Upgrades take effect immediately; downgrades apply at the end of the period you already paid for.

Because at that size the sensible setup usually needs a conversation first. Email sales@appscan.sh and we will size it with you.

No. The included allowance is per usage window. Top-ups do not expire while the plan is active, which is what makes them the right answer for a busy month.

In the header inside the app, and in full on the billing screen with the ledger behind it.

No. The estimate is reserved before the task runs, so a task either has its budget or does not start.

They stay. Sites, scans, findings, facts and reports are all kept; what stops is continuous monitoring and anything that needs credits.

Not automatically - it is once per organization. If something genuinely went wrong during yours, email us.

In the billing screen. With a card, that opens the provider’s own portal for payment methods and receipts; with PayPal, your subscriptions live in your PayPal account.

Yes, any time before the period ends - resubscribe from the billing screen and nothing changes.

Cancelling stops the next charge rather than refunding the current period. If something went wrong on our side, talk to us and we will sort it out.

It is bounded, rate-limited and read-only, and it backs off rather than pushing through. It behaves like one careful visitor, not like load.

It might, because it fetches paths like /.env to see whether they are exposed. That is the check. If you allowlist the scanner, remember you are also hiding real exposure from yourself.

It records that a response was readable and classifies whether it looked like personal data. The contents are not kept.

On managed infrastructure in the EU, encrypted in transit and at rest. Ask us if you need the specifics for a questionnaire.

Yes. Deleting an organization takes its sites, scans, findings, reports and facts with it. Ask support if you want an export first.

The model provider sees what a task sends it - a finding, a summary of facts, or the file being fixed - and never a raw secret. Email, payments and hosting are the other subprocessors; we will send the list on request.

Not a formal programme yet. We do say thank you properly, and we credit you publicly if you want that.

It means discovery never got a usable response. Confirm the address is public, answers over HTTPS and does not require a login, then try again.

It sends a scanner user agent you can match on. Remember that allowlisting also hides genuine exposure from your own report.

Most scanners report every missing header and every advisory as its own item, including ones that cannot hurt you. Here, findings are admitted on evidence and confidence, and duplicates across runtime and source are merged into one.

No, but be clear about what you get: the whole runtime half, dependency advisories from lockfiles, and all the infrastructure and pipeline rules. The taint-analysis rules are TypeScript and JavaScript today.

Minutes for a normal repository. The history walk is bounded and recorded as scanned-through, so it only happens once.

You should not have - findings belong to the site, not to the installation. If something is genuinely missing, tell us the repository and roughly when.

A repository belongs to one site, so that findings have one home. Split the site if you genuinely have two applications in one repository.

A manual live-site scan is started by a person and is free on paid plans (the Free plan includes five a month at one credit each). Automatic scans that follow pushes and pull requests are included in the plan and cost nothing.

Severity-aware tasks route a critical finding to a better model. The cost per task type is fixed, but a critical finding can also trigger an escalation, which is its own task.

The scrape endpoints are part of the deployment rather than a customer feature. Audit streaming and scheduled exports are the customer-facing half.

The same input produces the same finding every time, with no model in the loop. It is what makes a result reproducible and arguable.