Questions
Every answer has its own address, so one of them can be linked to or quoted without sending somebody to a page and telling them to look for it.
A passive scan only makes requests an ordinary visitor's browser would make: fetching pages, reading response headers, resolving DNS and inspecting published JavaScript. It sends nothing designed to change the target's behaviour, so it can be run against a site without prior arrangement. Active checks — which send requests a visitor would not — require proven ownership of the domain.
SAST reads source code and finds patterns that are dangerous regardless of whether they are reachable at runtime. DAST tests a running application from outside and finds what is actually exploitable, but only where it can reach. They disagree usefully: SAST reports things DAST cannot see, and DAST confirms things SAST can only suspect.
Server-Side Request Forgery is blind when the server fetches an attacker-supplied URL but never returns the response, so nothing in the reply reveals that it happened. It is detected by supplying a URL pointing at a collector you control: if a request arrives there, the target fetched it. The interaction is the evidence, and it can arrive minutes after the scan finished.
Not for website scanning, which works entirely from what the site already serves publicly. Repository scanning does need read access, and is where secret detection, dependency vulnerabilities and static analysis happen — findings that are invisible from outside.
Because those are different statements. 'No findings' means a check ran and found nothing; 'not assessed' means it did not run — the data was unavailable, the plan did not include it, or ownership was not verified. Reporting the second as the first is how a scan report reassures somebody about a risk nobody looked for.
Yes — seven categories, documented publicly. Credential stuffing locks real users out of their own accounts; conclusive SQL and command injection execute on somebody's production system; cache-poisoning tests serve the payload to other people's visitors. In each case the safe part is implemented and the destructive part is not, and every scan says which is which.
Continuously, if the site changes continuously. A scan describes the day it ran: a header removed during a deploy, an expiring certificate, or a subdomain someone stood up last week will not appear until something looks again. Monitoring re-runs on a schedule and tags each finding new, persisting, fixed, or regressed against the previous run, so what reaches you is the change rather than the whole list again.
Every finding states a confidence level alongside its severity, and the two are independent. Confirmed means the condition was observed directly. Potential means a pattern matched that is often the issue and sometimes is not, and the finding says what would settle it. A scanner that reports everything at the same certainty moves the work of separating them onto you without telling you that is what it did.
No, and treating it as one is the more expensive mistake. Automated scanning covers breadth continuously — configuration, dependencies, exposure — which a point-in-time engagement cannot. A penetration test covers depth: chained logic flaws, business-rule abuse, and the creative reasoning no rule engine performs. Each leaves the other's ground uncovered.
Passive observation of what a site already serves publicly is what any visitor's browser does, and is what this platform will do without further ceremony. Anything beyond that — requests a visitor would not send — requires proven ownership of the domain, established with a DNS TXT record or a file served from it. That boundary is enforced in code, not stated in a policy and trusted.
The risk that untrusted text reaches a model as if it were an instruction, and that the model's output then reaches something with authority. In practice it looks like a prompt assembled from user input with no separation, or agent tooling handed shell, filesystem, or eval access it does not need for its job. Both are visible statically, before the feature ever runs.
A software bill of materials is the list of components a build actually contains, with versions. It is what turns a disclosure from an investigation into a lookup — which matters most on the day a widely-used package is the one disclosed. A repository scan generates one per scan.
Into this deployment's own database. No third-party backend receives findings, scan history, or audit entries, and there is no analytics or advertising tracking anywhere in the application. Every external service a scan can contact is named in the Privacy Policy, along with exactly what is sent to each, and both export and deletion are self-service.
Something not answered here? Ask us — and if it is a question other people have, it ends up on this page.
Keep reading
Contact
Questions about what the engine checks, whether it fits your estate, or what it deliberately refuses to do. A person reads every message.