How Sayver's scanner actually works under the hood

Sayver runs three distinct scanners against three different layers of your application. Each one checks something the others cannot see. The site scanner inspects your live, deployed app from the outside — the same view an attacker or a search engine has. The code scanner reads your source code directly, looking for vulnerabilities that have not yet been deployed and for patterns that are invisible at the HTTP layer. The runtime monitor watches real traffic flowing through your app after it goes live, classifying each request and flagging the ones that look like reconnaissance, injection attempts, or credential abuse. Running all three together gives you a layered picture of your security posture that no single approach can provide on its own.

The site scanner starts with a standard HTTP request to your root URL and reads the response headers. It checks for the presence and correct configuration of Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options, and Referrer-Policy. It then probes your DNS records — MX, SPF, DKIM, DMARC — to assess your email security posture, because a misconfigured email domain is an open invitation to phishing attacks that impersonate your brand. It attempts to discover authentication endpoints by following navigation links, then tests whether those endpoints have detectable rate limiting. It checks whether common sensitive paths (/.env, /.git/config, /api/admin) return data they should not. Every active probe is redirect-aware: if your apex domain redirects to www, the scanner resets its context to the canonical host so it is testing your actual production configuration rather than an intermediate redirect.

The code scanner connects to your GitHub repository and reads your source files directly. It runs a set of SAST (Static Application Security Testing) rules across your codebase, looking for patterns that correlate with known vulnerability classes: unparameterized SQL queries built from string concatenation, calls to eval() with real arguments, server-side request forgery vectors where user-controlled input reaches the host portion of a URL, missing authentication checks on API route handlers, and hardcoded secrets matching common key formats. The scanner skips directories that contain tooling and dependencies (node_modules, .next, .claude, vendor folders) to focus analysis on code you wrote. When it finds a match, it records the file path, line number, matched content, and a severity score so you can navigate directly to the issue.

The runtime monitor is a lightweight JavaScript tag you add to your HTML. It captures metadata about incoming requests — path, method, user agent, referrer, response status — and sends it to Sayver's ingest endpoint, which classifies each event using a deterministic rule set. Classifications include path traversal attempts (requests for ../../etc/passwd or similar), SQL injection probes (requests with UNION SELECT or OR 1=1 in query parameters), XSS probes (requests with script tags in inputs), credential stuffing patterns (high volumes of failed authentication from rotating sources), and reconnaissance scans (systematic enumeration of common paths). When multiple events from the same source match an escalating severity pattern, they are grouped into an incident and surfaced in your dashboard with a severity rating and recommended action.

Findings from all three scanners are scored on a 0–100 scale using a deduction model. The app starts at 100 and loses points based on the severity of findings: critical findings (such as an exposed service role key or completely disabled RLS) deduct 40 points each; high findings deduct 25; medium findings deduct 10; low findings deduct 5. The score is calculated per scanner kind, so your site score and code score are independent — a clean site with a vulnerable codebase scores well on site and poorly on code, which accurately reflects the actual risk profile. Findings are fingerprinted so that the same issue does not appear multiple times across scans. When you fix an issue and re-scan, the finding is automatically closed and your score updates to reflect the improvement.

The design philosophy behind all three scanners is the same: deterministic classification with plain-English output. Every finding includes a description of what was detected, an explanation of why it matters, and a specific fix you can apply — typically a code snippet or a configuration change short enough to paste directly into your AI coding tool. There are no vague warnings, no CVSS jargon, and no findings that require a security background to interpret. The goal is not to produce a compliance report but to give a non-security founder an accurate picture of their risk surface and a clear path to reducing it.